通用权限管理模块系列——参考资料——RBAC即角色访问控制[转载]

RBAC模型是目前我看到网络上比较多人在转载的一个有关权限的模型

把今天搜集到的一些文章转贴过来，作为一个资料给园友交流。

今后计划以.NET 2.0的MemberShip和Role以及Profile为基础，扩展并支持RBAC的各个级别，至少是RBAC1

默认的MemberShip不包含对权限的部分，只是基本的用户管理模块

http://blog.csdn.net/huanghanzzz2006/archive/2006/12/04/1429678.aspx RBAC即角色访问控制(Role Based  Access Control)

 

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。
Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege,正向授权与负向授权）。

基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

http://www.blogjava.net/anwenhao/archive/2006/11/21/82535.html 

 

基于RBAC的权限设计模型：

 

1        RBAC 介绍

RBAC 模型作为目前最为广泛接受的权限模型。

NIST （The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）^[1]。RBAC0模型如图1所示。

图表 1 RBAC 0 模型

l          RBAC0 定义了能构成一个RBAC控制系统的最小的元素集合

在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

l          RBAC1 引入角色间的继承关系

角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。

l          RBAC2 模型中添加了责任分离关系

RBAC2 的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

l          RBAC3 包含了RBAC1和RBAC2

既提供了角色间的继承关系，又提供了责任分离关系。

建立角色定义表。定出当前系统中角色。

因为有继承的问题，所以角色体现出的是一个树形结构。

2        权限设计：

 

配置资源以及资源的操作 ： 这里资源可以定义为一个通用的资源模型。提供通用的资源统一接口。

 

 

 

 

 

数据库 ER 图：

 

关系图：

 

 

 

3        分析：

 

    根据以上的类关系图和ER图可以看出。整个权限可以抽象为五个对象组成。

OrgBean : 用于描述org模型。

Role ： 用于描述角色。

Permission ： 用于描述权限。

Resource ： 用于描述资源。

Operation ： 用于描述操作。

 

其中Permission中有Resource , Operation 的聚合，资源和操作组成权限。

Role 和 Permission 都有自包含。因为设计到权限的继承。

资源Resource 也可能出现一颗树形结构，那资源也要有自包含。

 

思想 :

权限系统的核心由以下三部分构成： 1. 创造权限， 2. 分配权限， 3. 使用权限，然后，系统各部分的主要参与者对照如下： 1. 创造权限 - Creator 创造， 2. 分配权限 - Administrator 分配， 3. 使用权限 - User ：

1. Creator 创造 Privilege ， Creator 在设计和实现系统时会划分，一个子系统或称为模块，应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明，并没有真正将 Privilege 与具体 Resource 实例联系在一起，形成 Operator 。

2. Administrator 指定 Privilege 与 Resource Instance 的关联 。在这一步， 权限真正与资源实例联系到了一起， 产生了 Operator （ Privilege Instance ）。 Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等 ... 这些操作都是由 Administrator 来完成的。

3. User 使用 Administrator 分配给的权限去使用各个子系统。 Administrator 是用户，在他的心目中有一个比较适合他管理和维护的权限模型。于是，程序员只要回答一个问题，就是什么权限可以访问什么资源，也就是前面说的 Operator 。程序员提供 Operator 就意味着给系统穿上了盔甲。 Administrator 就可以按照他的意愿来建立他所希望的权限框架 可以自行增加，删除，管理 Resource 和 Privilege 之间关系。可以自行设定用户 User 和角色 Role 的对应关系。 ( 如果将 Creator 看作是 Basic 的发明者， Administrator 就是 Basic 的使用者，他可以做一些脚本式的编程 ) Operator 是这个系统中最关键的部分，它是一个纽带，一个系在 Programmer ， Administrator ， User 之间的纽带。

 

4        权限API

   getPermissionByOrgGuid(String orgGuid )

      通过传入一个org的Guid ， 拿到当前这个org对象都具有那些访问权限。

 getSourcePermissionByOrgGuid(String orgGuid , String resouceGuid)

    通过传入一个org的Guid 和 一个资源的Guid ， 返回改Org对当前这个资源的访问权限。

 

getPermissionByResourceGuid(String resource)

    通过传入一个资源的Guid ， 得到当前资源下都有那些权限定义。

 

havingHeritPermission(String orgGuid , String resouceGuid) : Boolean

    传入一个orgGuid， 资源GUID ，查看改OrgGuid下对资源是否有向下继承的权限。这里继承是资源的继承。即对父栏目有权限，可以继承下去对父栏目下的子栏目同样有权限。

 

havingPermission(String orgGuid , String resourceGuid) : Boolean

    判断某Org对某一资源是否用权限。

 

以上是粗粒度的权限API 。 以下为细粒度的权限：

 

getOperationByPermission(String permissionGuid)

    通过permission 的Guid 得到该permission 的所有有效操作。

 

getOperationByGuid(String permissionGuid , String resourceGuid)

    通过permision的Guid ， 资源的Guid 得到该资源下所有的有效操作。

 

screeningOpreationByGuid (String permissionGuid , String resourceGuid , String orgGuid)

    通过permission ， resource ， org的Guid 得到改Org对这一资源的有效操作。

 

hasOperation(String operationGuid) : boolean

    通过传入的operationGuid 返回是否具有操作权限。

 

5        权限的实现：

1 ．表单式认证，这是常用的，但用户到达一个不被授权访问的资源时， Web 容器就发

出一个 html 页面，要求输入用户名和密码。

2 ．用 Filter 防止用户访问一些未被授权的资源， Filter 会截取所有 Request/Response ，

然后放置一个验证通过的标识在用户的 Session 中，然后 Filter 每次依靠这个标识来决定是否放行 Response 。

这个模式分为：

Gatekeeper ：采取 Filter 或统一 Servlet 的方式。

Authenticator ： 在 Web 中使用 JAAS 自己来实现。

 

Filter 拦截只是拦截该用户是否有访问这个页面，或这一资源的权限。真正做到显示后拦截是在应用程序内部去做。

 

做显示拦截提供API ， 标签这两种方式。

 

 另外，还有一篇介绍java里的开源实现

http://hi.baidu.com/deboywang/blog/item/6793c313a2643fd8f7039ea8.html 

 东西太多，摘录一些不同的来看

 

在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代 User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念 就具象到一个人。

这里的Group和GBAC（Group-Based Access Control）中的Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。

Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。

Party模式中的Person和User的关系，是每个Person可以对应到一个 User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到 Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。

引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。

Role 作为一个用户(User)与权限(Privilege)的代理层，解耦了权限和用户的关系，所有的授权应该给予Role而不是直接给User或 Group。Privilege是权限颗粒，由Operation和Resource组成，表示对Resource的一个Operation。例如，对于 新闻的删除操作。Role-Privilege是many-to-many的关系，这就是权限的核心。

 

===================================

文章抄完了

如果博客园的兄弟要实现一个通用权限管理系统模块，貌似至少要做到 RBAC1.