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