系统的安全控制模型主要包括部门、员工及其个性设置、角色、权限、业务数据五大元素,通过五大元素的相互关联实现系统严格的授权控制机制。
部门模型按照树形层级结构建立。一个部门可以有多个下级部门,一个部门只能有一个父级部门。
人员隶属于部门。一个部门可以有多个下属员工,一个员工只能属于一个部门。
人员聚集后可以形成用户组/工作组,工作组是临时性的组织,其下属人员可以属于多个行政组织,区别于行政部门或组织机构。工作组也可以隶属于某个部门。
角色是对一组相同授权设置的抽象,方便对一组用户进行权限分配。一个角色可以分给多个员工,一个员工也可拥有多个角色。
权限是对系统内所有可控制元素的抽象,通过树形层级结构来体现权限的粒度划分和权限之间的约束关系。一般按照功能类型->操作类型 的顺序进行控制粒度划分,例如:“信用等级管理”是一个较粗粒度的权限控制点,在其内部可以细分为“增、删、改、查”多个更细的控制点;另外也可以通过层级关系体现出“信用等级管理”这个抽象的控制点必须依赖于“增、删、改、查”这些具体的控制点。由于菜单的特殊性,在权限的层级结构中我们通过特殊的标识来定义系统的菜单结构和展现方式。
另外对于细粒度的权限控制点我们支持三个层次的控制方式,分别是界面元素控制、URL调用控制、业务方法调用控制,这三个层次是按照控制安全级别逐渐加强的,在实际的使用中“界面元素控制”是必须设置的安全级别,另外两个层次要根据系统的安全要求、系统性能之间的权衡来选择。
一个角色可以分配多个权限,权限可以通过角色间接分配给员工,也可以直接分配给员工。
“数据范围控制”是安全控制的另一个侧面,与“权限”相辅相成;如果说“权限”体现的是可以做什么操作,而“数据范围控制”则体现(操作主体)用这个操作可以操作那些对象。传统的数据控制方式往往是分散配置、分散控制,没有统一的处理模型。
系统包含各种业务数据(资源),每种资源有不同的权限特征,包括“资源集合”、“分配规则”、“校验规则”三个层面,如:需要按“属地”进行权限控制的客户数据,按照“级别”进行控制的号码资源,等等,我们将这样的数据按照其权限控制特征抽象为“资源”。
资源完整抽象之后就可以对部门、员工、员工组进行业务数据授权,从而实现员工可以查看、处理的数据范围的控制。
为了简化权限控制模型,对于数据范围的设置我们只在“部门”“用户”“用户组”层次进行设置,而没有侵入到“角色”,这样角色的概念可以保持的很单纯。
需要注意的是系统中的“资源”的权限特征有可能是固化的,这种情况下“资源权限”往往被退化为一种简单的“业务规则”,在业务逻辑中做固化逻辑处理,这种资源没有必要进行统一的资源抽象;除非在可预见的未来,其权限特征会发生变化。所以在这类资源抽象时需要平衡“配置量”和“扩展性”的关系。