RBAC的权限设计.docVIP

基于RBAC的权限设计 基于RBAC的权限设计模型： 1RBAC 介绍 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 就可以按照他的意愿来建立他所希望的