身份验证系统简述1

身份验证系统
所谓的系统在庞大的企业信息化平台上也就是一个模块，而这个系统（模块）也可以认为是由2个单独的子系统（模块）组成的：权限系统和组织结构系统。权限负责管理整个企业资源的使用，组织结构则描述了整个企业的职能架构。两相结合将企业的商业活动合理高效的调动起来。

权限系统的设计原则一般是：不提供全方位的权限解决方案，仅提供一个实现对通用的、粗粒度的权限逻辑的处理，对于一些定制性比较强的、细粒度的权限逻辑部分则归为业务逻辑，由业务模块编码处理。所以这也被称为不完全的权限系统。
比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。还有比如，有"新闻系统管理者只能删除一月前发布的，而超级管理员可删除所有的这样的限制，这属于业务逻辑(Business logic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRole or UserGroup来决定(当然给UserRole or UserGroup分配权限时就应该包含上面两条业务逻辑)。

同时权限系统还应该考虑将功能性的授权与资源性的授权分开。比如系统管理人员就有系统的功能性权限而不应该有企业资源的操作权限，比如系统维护人员不应具有费用减免的权限。

• Resource 企业资源，可以反向包含自身，即树状结构。
• Privilege 一个抽象的动词如“发布”，一定要和一个Resource Instance关联才会有真正的意义生成一个Privilege Instance，比如发布公告、发布商品。还可以指定排斥和包含关系，比如完全控制就包含更改和读取权限。
• Role   是一个抽象概念，是一类Privilege Instance的集合。用来和组织结构系统关联。在某些模型里支持继承关系和责任分离关系，所谓责任分离关系就是避免同一用户拥有互斥的角色，这种责任分离关系处理起来比较复杂，简化办法是同一时刻用户只能用一种角色进入系统。

组织结构系统的组成如下：

• User  纯粹的用户，如企业内部的所有员工和外部的代理商。
• Group  和User是多对多的关系，一个组可以包含多个用户，同时一个用户可以同时属于多个组。
   组本身可以嵌套，这样好处是子组自动从父组继承权限。 方便管理授权，将权限相同的Role组成一个Group进行集中授权。实际业务中，Group划分多以行政组织结构或业务功能划分。

两个子系统的结合：
Role和User是多对多的关系，Role和Group也是多对多的关系。

 

 

参考文章:
anwenhao 《权限的设计分析》