身份验证系统简述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 《权限的设计分析》

# Privilege 一个抽象的动词如“发布”，一定要和一个Resource Instance关联才会有真正的意义生成一个Privilege Instance，比如发

没贴全？

身份验证是Authentication，授权与权限验证是Authorization，两者不可混淆。

另外，原创还是转贴请说明。

说的好抽象，要是有个例子说明就好了

呵呵，感谢cryolite
to:BirdGu ，小弟刚学，可能理解得不够深刻，谢谢指正。不敢说原创，看了别人的东东自己总结一下，呵呵。
to:wdiy 马上举例 ！:arrow:

我的系统一年前已经更进了一步,可惜一直没空整理出来,主要观点如下:
1.组织结构只是一个装饰品,核心是RBAC,ACL
2.权限系统提供全面解决方案(元权限系统),系统权限和业务权限只是相对概念,当然具体实现还是要各模块自己去做
3.整系统高度可配置,动态可配置,例如给某业务增加了新的操作,那么将导致该业务产生新的权限.
4.不区分系统维护人员和普通操作者,都一样, 只要有足够权限.

  一个超级管理员还是必须的,要不最开始谁来授权呢

实际上，一开始什么用户也没有，那么就可以直接访问用户管理创建用户，这时已先到先得为原则，然后开始添加系统模块的配置，当然，前提是系统有这些模块的代码和URL才能真的运行，权限系统也是作为一个普通模块来添加的。在权限产生的时候，属于创建者，然后再由创建者分发或者转移，这个要视乎权限系统的定义来看了。

1.我想只要把握了其中的精髓，你会发现这实际很简单，提示一下，在这个的系统里，每个组织都有对应的一个角色，当然，它也能有属于自己所管辖的角色，但在RBAC的世界里，所有的角色都是一样的,明白了吗。
3.例如说权限管理，在有了分配功能后，领导突发奇想，需要增加一个转移功能，那么在给权限系统加了该功能的配置后，系统可以自动产生所有权限的转移权限，这时权限的所有者就自动获得他所有的权限的转移权限。