用户 --->角色 ---->权限。角色概念提出是解耦用户和权限之间的直接联系。<o:p></o:p>
角色和组（groups）是有区别的，组是就是纯粹代表一群用户；角色一方面代表一系列用户，另外一方面可以代表一系列权限，因此可以说是用户和权限的结合体。<o:p></o:p>
用户（User）和角色（Role） <o:p></o:p>
用户指访问系统中的资源的主体，一般为人，也可为 Agent 等智能程序。角色指应用领域内一种权力和责任的语义综合体，可以是一个抽象概念，也可以是对应于实际系统中的特定语义体，比如组织内部的职务等。针对角色属性的不同，某些模型中将角色进一步细分为普通角色和管理员角色（可理解为全局角色）。<o:p></o:p>
许可（Permissions）和权限（Permission） <o:p></o:p>
许可描述了角色对计算机资源的访问和操作所具有的权限，其反映的是授权的结果。比如授予某个角色对计算机资源有读的权限，则代表了一个许可的存在，这个许可表示：角色获取了对计算机资源的读许可。针对操作来说，其描述的是许可和操作之间的一种关联关系，而这层关系则表示了某一角色对某一操作所具有的权限及权限状态。<o:p></o:p>
角色和指派（Assignment）<o:p></o:p>
指派包含两个方面，用户指派和许可指派。用户指派表示的是，将用户指派给特定的角色。许可指派表示的是为角色指派计算机资源的访问和操作许可。<o:p></o:p>
会话（session） <o:p></o:p>
会话表示的是用户和角色之间的关系。用户每次必须通过建立会话来激活角色，得到相应的访问权限。<o:p></o:p>
角色和角色等级（Role Hierarchies） <o:p></o:p>
角色本身仅仅只是一个名词，其本身并不能代表权限的大小。比如，我们可以定一个“Director”的角色，也可以定一个“Project Leader”的角色。对于现实中我们来说，看到这样两个角色，就清楚 DIR 的权限要比一个 PL 的权限级别高。但是对计算机来说，这两个角色仅仅是两个“词语”，是等同的。可以采用分等级角色，在角色上实现层次化来解决这些问题。也可以采用复合角色（其表示的就是一个角色组的概念），对角色实现一定的分组和复合，以便于权限指派。在一些 OA 产品中经常出现分等级角色。
限制（Constraints）
模型中的职责分离关系（Separation of Duty），用于控制冲突（Conflict）。静态职责分离（Static SD）指定角色的互斥关系，用于用户指派阶段。避免同一用户拥有互斥的角色。实现简单，角色互斥语义关系清楚，便于管理不够灵活，不能处理某些实际情况。动态职责分离（Dynamic SD）指定角色的互斥关系，用于角色激活阶段。允许同一用户拥有某些互斥的角色，但是不允许该用户同时激活互斥的角色。更灵活，直接与会话挂钩，适应实际管理需要，实现复杂，不易管理。<o:p></o:p>
<v:shapetype o:spt="75" coordsize="21600,21600" filled="f" stroked="f" id="_x0000_t75" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t"> <v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:extrusionok="f" o:connecttype="rect" gradientshapeok="t"></v:path><o:lock v:ext="edit" aspectratio="t"></o:lock></v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" alt="rbac.jpg" style="WIDTH: 666pt; HEIGHT: 390pt"><v:imagedata o:href="http://www.blogjava.net/images/blogjava_net/rosen/rbac.jpg" src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image001.jpg"></v:imagedata></v:shape><o:p></o:p>
<o:p> </o:p>
<script type="text/javascript"> </script> <script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> </script> <o:p> </o:p> |
[Title ] 关于用户角色权限管理一点想法
[Author] Pizer.Chen
[Email ] Iceant@21cn.com | iceant@vip.163.com
[Date ] <st1:chsdate isrocdate="False" month="11" day="3" islunardate="False" w:st="on" year="2002">2002-11-3</st1:chsdate>
----------------------------------------------------------------------------
我以前设计过一个权限系统的模型，但是我没有实现，
可以说出来，大家讨论一下。
我认为一个系统的权限部分应该由以下四个部分组成:
[*] Resource
[*] Privilege
[*] Role
[*] User
另外，一个系统中最少有这么几个角色:
[*] Creator， 也可以称做 Programmer.
[*] Administrator, 超级用户
[*] General User
----------------------
权限各部分之间的关系:
----------------------
1. Resource 就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象.
2. Privilege 是 Resource Related 的权限。
什么意思？就是指，这个权限是绑定在特定的资源实例上的。
比如说部门新闻的发布权限，叫做"部门新闻发布权限".
这就表明，该 Privilege 是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。
我认为，Privilege 是由 Creator 在做开发时就确定的。
3. Role, 是角色，拥有一定数量的权限。
4. User, 与 Role 相关。在我设计的系统里，User是不能与 Privilege 直接相关的，
User 要拥有对某种资源的权限，必须通过Role去关联.
----------------------
系统大串联:(^_^)
----------------------
下面简单介绍一下，一个权限从开发到使用的过程.
1. Creator 创造 Privilege, Creator 在设计和实现系统时会划分，一个子系统或称为模块，
应该有哪些权限. 拿新闻这一块来说，可能应该有：
[*] 发布权限(publish)
[*] 修改权限(modify)
[*] 审核权限(review)
[*] 浏览权限(visit)
.......
这里完成的是 Privilege 与 Resource 的对象申明，并没有真正将 Privilege 与具体
Resource 实例联系在一起.
2. Administrator 指定 Privilege 与 Resource Instance 的关联.
在这一步， 权限真正与资源实例联系到了一起, 产生了 Privilege Instance。
比如，Administrator 创建了一个叫做 "部门新闻" 的Resource Instance.
然后将发布权限与这个资源相关联，产生出 "部门新闻发布权限" 这个 Privilege Instance.
3. Administrator 创建一个角色，称做 "部门新闻发布者".
4. Administrator 将 "部门新闻发布权限" 赋予 "部门新闻发布者".
5. Administrator 从用户列表中选取一个或多个用户，
然后给这些用户赋予 "部门新闻发布者" 的角色
6. User 进到系统，在它的可访问资源列表上，会出现"部门新闻发布"的链接.
7. User 点击 "部门新闻发布"的链接, 根据 Creator 的实现，系统会检查
[1] 当前用户是否拥有发布权限
[2] 当前用户的发布权限是否与能操作正在访问的资源.
