基于RBAC的权限设计模型

基于RBAC的权限设计模型 

权限分析文档 

基于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 模型 

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

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

          RBAC1 引入角色间的继承关系 

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

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

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

          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 ， 标签这两种方式。