权限

权限设计

前言：
权限每每是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断"Who对What(Which)进行How的操做"的逻辑表达式是否为真。针对 不一样的应用，须要根据项目的实际状况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。g

目标：
直观，由于系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是由于它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决全部的权限问题是不现实的。设计中将经常变化的"定制"特色比较强的部分判断为业务逻辑，而将经常相同的"通用"特色比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时
现状：
对于在企业环境中的访问控制方法，通常有三种：
1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。
2.强制型访问控制方法。用于多层次安全级别的军事应用。
3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减少受权管理的复杂性，下降管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
名词：
粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特
定实例。好比，用户管理中，建立、删除，对全部的用户都一视同仁，并不区分操做的具体对象实例。
细粒度：表示实例级，即须要考虑具体对象的实例(the instance of object)，固然，细
粒度是在考虑粗粒度的对象类别以后才再考虑特定实例。好比，合同管理中，列表、删除，须要区分该合同实例是否为当前用户所建立。
原则：
权限逻辑配合业务逻辑。即权限系统觉得业务逻辑提供服务为目标。至关多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是"业务逻辑"的一 部分。好比，要求："合同资源只能被它的建立者删除，与建立者同组的用户能够修改，全部的用户可以浏览"。这既能够认为是一个细粒度的权限问题，也能够认 为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。固然，权限系统的架构也必需要能支持这样的控制判断。或者 说，系统提供足够多但不是彻底的控制能力。即，设计原则归结为："系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责"。
须要再次强调的是，这里表述的权限系统仅是一个"不彻底"的权限系统，即，它不提供全部关于权限的问题的解决方法。它提供一个基础，并解决那些具备"共 性"的(或者说粗粒度的)部分。在这个基础之上，根据"业务逻辑"的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公 式，通用的设计仅解决了Who+What+How 的问题，其余的权限问题留给业务逻辑解决。
概念：
Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等）
What：权限针对的对象或资源（Resource、Class）。
How：具体的权限（Privilege, 正向受权与负向受权）。
Role：是角色，拥有必定数量的权限。
Operator：操做。代表对What的How 操做。
说明：
User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须经过Role去关联。解决 Who 的问题。
Resource：就是系统的资源，好比部门新闻，文档等各类能够被提供给用户访问的对象。资源能够反向包含自身，即树状结构，每个资源节点能够与若干指定权限类别相关可定义是否将其权限应用于子节点。
Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。好比说部门新闻的发布权限，叫作"部门新闻发布权限"。这就代表，该 Privilege是一个发布权限，并且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在作开发时就肯定的。权限，包括系 统定义权限和用户自定义权限用户自定义权限之间能够指定排斥和包含关系(如：读取，修改，管理三个权限，管理 权限 包含 前两种权限)。Privilege 如"删除" 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一块儿时是没有任何意义的。拿新闻发布来讲，发布是一种权限，可是只说发布它是毫无心义的。由于不知道发布能够操做的对象是什么。只有当发布与新闻结 合在一块儿时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不一样能够延伸生不少不一样的版本。
Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现能够直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。
Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组能够包括组(以实现权限的继承)。组能够包含用户，组内用户继承组的权限。 Group要实现继承。即在建立时必需要指定该Group的Parent是什么Group。在粗粒度控制上，能够认为，只要某用户直接或者间接的属于某个 Group那么它就具有这个Group的全部操做许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否"同 组" 。Group是可继承的，对于一个分级的权限实现，某个Group经过"继承"就已经直接得到了其父Group所拥有的全部"权限集合"，对这个 Group而言，须要与权限创建直接关联的，仅是它比起其父Group须要"扩展"的那部分权限。子组继承父组的全部权限，规则来得更简单，同时意味着管 理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入"父子关系"。
User与Group是多对多的关系。即一个User能够属于多个Group之中，一个Group能够包括多个User。子Group与父Group是多对一的关系。Operator某种意义上相似于Resource + Privilege概念，但这里的Resource仅包括Resource Type不表示Resource Instance。Group 能够直接映射组织结构，Role 能够直接映射组织结构中的业务角色，比较直观，并且也足够灵活。Role对系统的贡献实质上就是提供了一个比较粗颗粒的分配单位。
Group与Operator是多对多的关系。各概念的关系图示以下：
解释：
Operator的定义包括了Resource Type和Method概念。即，What和How的概念。之因此将What和How绑定在一块儿做为一个Operator概念而不是分开建模再创建关联，这是由于不少的How对于某What才有意义。好比，发布操做对新闻对象才有意义，对用户对象则没有意义。
How自己的意义也有所不一样，具体来讲，对于每个What能够定义N种操做。好比，对于合同这类对象，能够定义建立操做、提交操做、检查冲突操做等。可 以认为，How概念对应于每个商业方法。其中，与具体用户身份相关的操做既能够定义在操做的业务逻辑之中，也能够定义在操做级别。好比，建立者的浏览视 图与普通用户的浏览视图要求内容不一样。既能够在外部定义两个操做方法，也能够在一个操做方法的内部根据具体逻辑进行处理。具体应用哪种方式应依据实际情 况进行处理。
这样的架构，应能在易于理解和管理的状况下，知足绝大部分粗粒度权限控制的功能须要。可是除了粗粒度权限，系统中必然还会包括无数对具体Instance的细粒度权限。这些问题，被留给业务逻辑来解决，这样的考虑基于如下两点：
一方面，细粒度的权限判断必需要在资源上建模权限分配的支持信息才可能得以实现。好比，若是要求建立者和普通用户看到不一样的信息内容，那么，资源自己应该 有其建立者的信息。另外一方面，细粒度的权限经常具备至关大的业务逻辑相关性。对不一样的业务逻辑，经常意味着彻底不一样的权限断定原则和策略。相比之下，粗粒 度的权限更具通用性，将其实现为一个架构，更有重用价值；而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐，并且不是那么的有必要，用定制的代码 来实现就更简洁，更灵活。
因此细粒度控制应该在底层解决，Resource在实例化的时候，必需指定Owner和GroupPrivilege在对Resource进行操做时也必 然会肯定约束类型：到底是OwnerOK仍是GroupOK仍是AllOK。Group应和Role严格分离User和Group是多对多的关 系，Group只用于对用户分类，不包含任何Role的意义；Role只授予User，而不是Group。若是用户须要尚未的多种Privilege的 组合，必须新增Role。Privilege必须可以访问Resource，同时带User参数，这样权限控制就完备了。
思想：
权限系统的核心由如下三部分构成：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之间的纽带。
用一个功能模块来举例子。
一．创建角色功能并作分配：
1．若是如今要作一个员工管理的模块(即Resources)，这个模块有三个功能，分别是：增长，修改，删除。给这三个功能各自分配一个ID，这个ID叫作功能代号：
Emp_addEmp，Emp_deleteEmp，Emp_updateEmp。
2．创建一个角色(Role)，把上面的功能代码加到这个角色拥有的权限中，并保存到数据库中。角色包括系统管理员，测试人员等。
3．创建一个员工的帐号，并把一种或几种角色赋给这个员工。好比说这个员工既能够是公司管理人员，也能够是测试人员等。这样他登陆到系统中将会只看到他拥有权限的那些模块。
二．把身份信息加到Session中。
登陆时，先到数据库中查找是否存在这个员工，若是存在，再根据员工的sn查找员工的权限信息，把员工全部的权限信息都入到一个Hashmap中，好比就把 上面的Emp_addEmp等放到这个Hashmap中。而后把Hashmap保存在一个UserInfoBean中。最后把这个 UserInfoBean放到Session中，这样在整个程序的运行过程当中，系统随时均可以取得这个用户的身份信息。
三．根据用户的权限作出不一样的显示。
能够对比当前员工的权限和给这个菜单分配的"功能ID"判断当前用户是否有打开这个菜单的权限。例如：若是保存员工权限的Hashmap中没有这三个ID的任何一个，那这个菜单就不会显示，若是员工的Hashmap中有任何一个ID，那这个菜单都会显示。
对于一个新闻系统(Resouce)，假设它有这样的功能(Privilege)：查看，发布，删除，修改；假设对于删除，有"新闻系统管理者只能删除一月前发布的，而超级管理员可删除全部的这样的限制，这属于业务逻辑(Business logic)，而不属于用户权限范围。也就是说权限负责有没有删除的Permission，至于能删除哪些内容应该根据UserRole or UserGroup来决定(固然给UserRole or UserGroup分配权限时就应该包含上面两条业务逻辑)。
一个用户能够拥有多种角色，但同一时刻用户只能用一种角色进入系统。角色的划分方法能够根据实际状况划分，按部门或机构进行划分的，至于角色拥有多少权 限，这就看系统管理员赋给他多少的权限了。用户—角色—权限的关键是角色。用户登陆时是以用户和角色两种属性进行登陆的（由于一个用户能够拥有多种角色， 但同一时刻只能扮演一种角色），根据角色获得用户的权限，登陆后进行初始化。这其中的技巧是同一时刻某一用户只能用一种角色进行登陆。
针对不一样的"角色"动态的创建不一样的组，每一个项目创建一个单独的Group，对于新的项目，创建新的 Group 便可。在权限判断部分，应在商业方法上予以控制。好比：不一样用户的"操做能力"是不一样的(粗粒度的控制应能知足要求)，不一样用户的"可视区域"是不一样的(体如今对被操做的对象的权限数据，是否容许当前用户访问，这须要对业务数据建模的时候考虑权限控制须要)。
扩展性：
有了用户/权限管理的基本框架，Who(User/Group)的概念是不会常常须要扩展的。变化的多是系统中引入新的 What (新的Resource类型)或者新的How(新的操做方式)。那在三个基本概念中，仅在Permission上进行扩展是不够的。这样的设计中 Permission实质上解决了How 的问题，即表示了"怎样"的操做。那么这个"怎样"是在哪个层次上的定义呢？将Permission定义在"商业方法"级别比较合适。好比，发布、购 买、取消。每个商业方法能够意味着用户进行的一个"动做"。定义在商业逻辑的层次上，一方面保证了数据访问代码的"纯洁性"，另外一方面在功能上也是"足 够"的。也就是说，对更低层次，能自由的访问数据，对更高层次，也能比较精细的控制权限。
肯定了Permission定义的合适层次，更进一步，可以发现Permission实际上还隐含了What的概念。也就是说，对于What的How操做 才会是一个完整的Operator。好比，"发布"操做，隐含了"信息"的"发布"概念，而对于"商品"而言发布操做是没有意义的。一样的，"购买"操 做，隐含了"商品"的"购买"概念。这里的绑定还体如今大量通用的同名的操做上，好比，须要区分"商品的删除"与"信息的删除"这两个同名为"删除"的不 同操做。
提供权限系统的扩展能力是在Operator (Resource + Permission)的概念上进行扩展。Proxy 模式是一个很是合适的实现方式。实现大体以下：在业务逻辑层(EJB Session Facade [Stateful SessionBean]中)，取得该商业方法的Methodname，再根据Classname和 Methodname 检索Operator 数据，而后依据这个Operator信息和Stateful中保存的User信息判断当前用户是否具有该方法的操做权限。
应用在 EJB 模式下，能够定义一个很明确的 Business层次，而一个Business 可能意味着不一样的视图，当多个视图都对应于一个业务逻辑的时候，好比，Swing Client以及 Jsp Client 访问的是同一个 EJB 实现的 Business。在 Business 层上应用权限较能提供集中的控制能力。实际上，若是权限系统提供了查询能力，那么会发现，在视图层次已经能够不去理解权限，它只须要根据查询结果控制界面就能够了。
灵活性：
Group和Role，只是一种辅助实现的手段，不是必需的。若是系统的Role不少，逐个受权违背了"简单，方便"的目的，那就引入Group，将权限 相同的Role组成一个Group进行集中受权。Role也同样，是某一类Operator的集合，是为了简化针对多个Operator的操做。
Role把具体的用户和组从权限中解放出来。一个用户能够承担不一样的角色，从而实现受权的灵活性。固然，Group也能够实现相似的功能。但实际业务中，Group划分多以行政组织结构或业务功能划分；若是为了权限管理强行将一个用户加入不一样的组，会致使管理的复杂性。
Domain的应用。为了受权更灵活，能够将Where或者Scope抽象出来，称之为Domain，真正的受权是在Domain的范围内进行，具体的 Resource将分属于不一样的Domain。好比：一个新闻机构有国内与国外两大分支，两大分支内又都有不一样的资源（体育类、生活类、时事政治类）。假 如全部国内新闻的权限规则都是同样的，全部国外新闻的权限规则也相同。则能够创建两个域，分别受权，而后只要将各种新闻与不一样的域关联，受域上的权限控 制，从而使之简化。
权限系统还应该考虑将功能性的受权与资源性的受权分开。不少系统都只有对系统中的数据（资源）的维护有权限控制，但没有对系统功能的权限控制。
权限系统最好是能够分层管理而不是集中管理。大多客户但愿不一样的部门能且仅能管理其部门内部的事务，而不是什么都须要一个集中的 Administrator或Administrators组来管理。虽然你能够将不一样部门的人都加入Administrators组，但他们的权限过 大，能够管理整个系统资源而不是该部门资源。
正向受权与负向受权：正向受权在开始时假定主体没有任何权限，而后根据须要授予权限，适合于权限要求严格的系统。负向受权在开始时假定主体有全部权限，而后将某些特殊权限收回。
权限计算策略：系统中User，Group，Role均可以受权，权限能够有正负向之分，在计算用户的净权限时定义一套策略。
系统中应该有一个集中管理权限的AccessService，负责权限的维护（业务管理员、安全管理模块）与使用（最终用户、各功能模块），该 AccessService在实现时要同时考虑通常权限与特殊权限。虽然在具体实现上能够有不少，好比用Proxy模式，但应该使这些Proxy依赖于 AccessService。各模块功能中调用AccessService来检查是否有相应的权限。因此说，权限管理不是安全管理模块本身一我的的事情， 而是与系统各功能模块都有关系。每一个功能模块的开发人员都应该熟悉安全管理模块，固然，也要从业务上熟悉本模块的安全规则。
技术实现：
1．表单式认证，这是经常使用的，但用户到达一个不被受权访问的资源时，Web容器就发
出一个html页面，要求输入用户名和密码。
2．一个基于Servlet Sign in/Sign out来集中处理全部的Request，缺点是必须由应用程序本身来处理。
3．用Filter防止用户访问一些未被受权的资源，Filter会截取全部Request/Response，
而后放置一个验证经过的标识在用户的Session中，而后Filter每次依靠这个标识来决定是否放行Response。
这个模式分为：
Gatekeeper ：采起Filter或统一Servlet的方式。
Authenticator： 在Web中使用JAAS本身来实现。
用户资格存储LDAP或数据库：
1. Gatekeeper拦截检查每一个到达受保护的资源。首先检查这个用户是否有已经建立
好的Login Session，若是没有，Gatekeeper 检查是否有一个全局的和Authenticator相关的session？
2. 若是没有全局的session，这个用户被导向到Authenticator的Sign-on 页面，
要求提供用户名和密码。
3. Authenticator接受用户名和密码，经过用户的资格系统验证用户。
4. 若是验证成功，Authenticator将建立一个全局Login session，而且导向Gatekeeper
来为这个用户在他的web应用中建立一个Login Session。
5. Authenticator和Gatekeepers联合分享Cookie，或者使用Tokens在Query字符里。



－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

权限系统(1)--基本模式

在系统中发生的事情，抽象的说都是某个主体(subject)在某个资源(resource)上执行了某个操做(operation)。
subject --[operation]--> resource
所谓权限管理，就是在这条信息传递路径中加上一些限制性控制。
主体试图去作的 limited by 系统容许主体去作的 = 主体实际作的。
能够看到，权限控制基本对应于filter模式。subject试图去作的事情应该由业务逻辑决定，于是应该编码在业务系统中。

先考虑最粗粒度的控制策略，控制点加在subject处，即不管从事何种操做，针对何种资源，咱们首先须要确认subject是受控的。只有经过认证的用户才能使用系统功能，这就是authentication。boolean isAllowed subject)
稍微复杂一些，控制能够施加在subject和operation的边界处（此时并不知道具体进行何种操做），称为模块访问控制，即只有某些用户才能访问特定模块。isAllowed(subject, operation set)
第三级控制直接施加在operation上，即操做访问控制。operation知道resource和subject（但它尚没有关于resource的细节知识)，咱们可以采起的权限机制是bool isAllowed(subject, operation, resource), 返回true容许操做，返回false则不容许操做。

最简单的状况下，subject与resource之间的访问控制关系是静态的，能够直接写成一个权限控制矩阵

for operationA:
resourceA resourceB
subjectA 1 0
subjectB 0 1


isAllowed(subjectA, resourceA)恒等于true

若是多个operation的权限控制均可以经过这种方式来表示，则多个权限控制矩阵能够叠加在一块儿

for operationA, operationB:
resourceA resourceB
subjectA 10 01
subjectB 01 11

当subject和resource的种类不少时，权限控制矩阵急剧膨胀，它的条目数是N*M。很显然，咱们须要进行矩阵分解。这也是最基本的控制手段之一: 在系统中增长一个瓶颈，或者说寻找到隐含的结构。
subject_resource = subject_role * role_resource
这样系统权限配置条目的数量为 N*R + R*M, 若是R的数目远小于subject和resource，则实现简化。这称为RBAC(role based access control)，它的一个额外好处是权限系统的部分描述能够独立于subject存在，即在系统中没有任何用户的时候，经过角色仍然能够表达部分权限信息。能够说角色是subject在权限系统中的代理(分解)。

有时候引入一个瓶颈还不过瘾，有人引入组的概念，与role串联，
subject_resource = subject_group_role * role_resource
或着group与role并联,
subject_resource = subject_group * group_resource

与role稍有不一样，通常状况下group的业务含义更加明显，可能对应于组织结构等。将组织机构明确引入权限体系，有的时候比较方便，但对于权限系统自 身的稳定性而言，未见得有什么太大的好处。并联模式有些多余，串联模式又过于复杂，细节调整困难，特别是多条控制路径形成的冲突状况。通常状况下，我不提 倡将group引入权限控制中。

比操做控制更加深刻的控制就是数据控制了，此时须要对于resource的比较全面的知识。虽然表面上，仍然是
boolean isAllowed(subject, operation, resource)，但控制函数须要知道resource的细节。例如行级控制(row-level)或者列级控制(column-level)的实现。 由于咱们通常状况下不可能将每个条目都建模为独立的resource，而只能是存在一个总体描述，例如全部密级为绝密的文档。在witrix平台中，数 据控制主要经过数据源的filter来实现，由于查询条件（数据的定位条件)已经被对象化为Query类，因此咱们能够在合适的地方自由的追加权限控制条 件。

以上的讨论中，权限控制都是根据某些静态描述信息来进行的，但现实世界是多变的。最简单的，当subject从事不一样业务时，对应于同一组资源，也可能对应的权限控制并不一样(在witrix平台中,对应于IDataSource的模式切换)。更复杂一些, 在不一样的时刻, 咱们须要根据其余附加信息来做出是否容许操做的判断, 即此时咱们权限设置的不只仅是一些静态的描述信息, 而是一个完整的控制函数, 这就是所谓的工做流权限控制,一种动态权限控制.

权限系统(2)--operation

权限控制能够看做一个filter模式的应用, 这也符合AOP思想的应用条件。在一个简化的图象中，咱们只须要将一个判别函数 isAllowed(subject, operation, resource)插入到全部安全敏感的函数调用以前就能够了。虽然概念上很完美，具体实现的时候仍然有一些细节上的问题。基本的困难在于很难在最细的粒 度上指定权限控制规则（连续的？动态的？可扩展的？），于是咱们只能在一些关键处指定权限规则，或者设置一些总体性的权限策略，而后经过特定的推理来推导 出细粒度的权限规则，这就引出结构的问题。咱们须要可以对权限控制策略进行有效的描述（控制策略的结构），而且决定如何与程序结构相结合。 subject, operation和resource为了支持推理，均可能须要分化出复杂的结构，而再也不是简单的原子性的概念。而在与程序结构结合这一方面，虽然AOP 使得咱们能够扩展任何函数，但这种扩展须要依赖于cutpoint处所能获得的信息，于是权限控制的有效实施也很是依赖于功能函数自己良好的设计。有的时 候由于须要对结构有过于明确的假定，权限控制的实现不得不牺牲必定的通用性。

下面咱们将分别讨论一下operation, subject和resource的结构分解的问题。首先是operation。
说到推理结构，让人最早想起的就是决策树，树形结构，在面向对象语言中能够对应于继承。金字塔式的树形结构也正是在现实世界中咱们应用最多的控制结构。经过层层分解，operation的结构能够组织为一棵树,
应用程序 ==> 各个子系统 ==> 每一个子系统的功能模块 ==> 子功能模块
==> 每一个模块的功能点(具备明确的业务含义) ==> 每一个功能点对应的访问函数(程序实现中的结构)
一个常见的需求是根据权限配置决定系统菜单树的显示，通常控制用户只能看到本身有权操做的功能模块和功能按钮。这种需求的解决方法是很是直接的。首先，在 后台创建子系统到功能模块，功能模块到功能点以及功能点到实现函数之间的映射表（若是程序组织具备严格规范，这甚至能够经过自动搜集获得）。而后，在权限 配置时创建用户与功能点之间的关联。此时，经过一个视图，咱们就能够搜集到用户对哪些功能模块具备访问权限的信息。

为了控制菜单树的显示，witrix平台中的SiteMap采用以下策略：
1. 若是用户对某个子功能具备操做权限，则全部父菜单项都缺省可用
2. 若是用户对某个功能具备操做权限，而且标记为cascade，则全部子菜单项都自动缺省可用
3. 若是明确指定功能不可用，则该菜单及子菜单都强制不可用
4. 若是明确指定功能对全部人可用，则不验证权限，全部子菜单自动缺省可用
4. 强制设定覆盖缺省值
5. 不可用的菜单缺省不可见
6. 明确标记为可见的菜单即便不可用也可见
7. 父菜单可见子菜单才可见
咱们经过预计算来综合考虑这些相互影响的控制策略。尽可能将推导运算预先完成也是解决性能问题的不二法门。

在witrix平台中，每一次网络访问的url都符合jsplet框架所要求的对象调用格式，须要指定objectName和objectEvent参 数，这就对应于功能点的访问函数。访问控制点集中在objectManager而且访问格式是标准的。使用spring等AOP方式实现细粒度访问控制， 困难彷佛在于不容易引入外部配置信息（例如功能点信息等），并且控制点所对应的对象函数格式也不统一，于是多数须要在细粒度上一一指定。

权限系统(3)-- subject

权限控制中，subject可能不会简单的对应于userId, 而是包含一系列的security token或certificate, 例如用户登录地址，登录时间等。通常状况下，这些信息在权限系统中的使用都是很直接的，不会形成什么问题。
subject域中最重要的结构是user和role的分离，能够在不存在user的状况下，为role指定权限。有人进一步定义了userGroup的 概念，能够为userGroup指定role，而user从其所属的group继承role的设置。通常状况下，我不提倡在权限系统中引入 userGroup的概念。这其中最重要的缘由就是它会形成多条权限信息传递途径，从而产生一种路径依赖, 并可能出现信息冲突的状况。通常user与group的关联具备明确的业务含义，于是不能随意取消。若是咱们但愿对user拥有的权限进行细调，除去 user从group继承的某个不该该拥有的权限，解决的方法颇有多是所谓的负权限，即某个权限条目描述的是不能作某某事。负权限会形成各个权限设置之 间的互相影响，形成必须尝试全部权限规则才能做出判断的困境，引出对额外的消歧策略的需求，这些都极大的限制了系统的可扩展性。在容许负权限的环境中，管 理员将没法直接判定某个权限设置的最终影响，他必须在头脑中完成全部的权限运算以后才能理解某用户最终拥有的实际权限，若是发现权限设置冲突，管理员可能 须要屡次尝试才能找到合适方案。这种配置时的推理需求可能会增长配置管理的难度，形成微妙的安全漏洞，并且负权限致使的全局关联也下降了权限系统的稳定 性。我更倾向于将group做为权限设置时的一种辅助标记手段，系统中只记录用户最终拥有的角色，即至关于记录用户经过group拥有权限的推导完成的结 果, 若是须要权限细调，咱们直接在用户拥有的角色列表上直接进行。固然，若是实现的复杂一些，权限系统对外暴露的接口仍然能够模拟为可以指定 userGroup的权限。
推理在面向对象语言中最明显的表现是继承，因此有些人将subject域中的推理直接等价于role之间的继承问题，这未必是最好的选择。继承能够造成非 常复杂的推理关系，可是可能过于复杂了（特别是直接使用sql语句没法实现树形推理查询）。按照级列理论，从不相关发展到下一阶段是出现简单的序关系，即 咱们能够说subject出现级别上的差别，高级别subject将自动具备低级别的权限。一种选择是定义roleRank,规定高级别role自动具备 低级别role的权限，但考虑到user与role的两分结构，咱们也能够同时定义userRank和roleRank,规定高级别user自动具备低级 别的role，而role之间不具备推理关系。在面向对象领域中，咱们已经证明了彻底采用继承来组织对象关系会致使系统的不稳定，因此我倾向于第二种选 择，即将role看做某种相似于interface的东西，一种权限的切片。为了进一步限制这种推导关系，咱们能够定义所谓的安全域的概念. security domain, 规定推导只能在必定的域中才能进行。
select user.userId, role.roleId
from user, role
where user.userRank > role.roleRank
and user.domain = role.domain

将权限控制通常须要施加在最细的粒度上，这在复杂的系统中可能过于理想化了。复杂的状况下咱们须要进行局部化设计，即进行某些敏感操做以前进行一系列复杂的权限校验工做。当完成这些工做以后，进入某个security zone, 在其中进行操做就再也不须要校验了。
总的来讲，权限系统采用很是复杂的结构效果未必理想。不少时候只是个管理模式的问题，应该尽可能经过从新设计权限空间的结构来加以规避。不过在一些很是复杂 的权限控制环境下，也许简单的描述信息确实很难有效的表达权限策略（虽然我从未遇到过），此时尝试一下规则引擎可能比在权限系统中强行塞入愈来愈多的约束 要好的多

权限系统(4)--resource

权限管理中进行数据访问控制，其基本模式以下
operation target = selector(resource)
selector = user selector + auth filter
这里须要对resource的结构，以及选择算子的显式建模。selector必须容许权限系统追加filter，例如
IDataSource包中所使用的Query对象。
sql语言的表达能力有限, 做为选择算子来使用有时须要resource做一些结构上的调整，增长一些冗余的字段。例如表达一段时间内的利率，咱们须要使用from_date和to_date两个字段来进行描述，其中to_date的值与下一条记录的from_date相同。
value from_date to_date
0.01 2003-01-01 2003-05-01
0.012 2003-05-01 2004-01-01

若是表达一条航线中的多个阶段，咱们可能会在每条记录中增长起始站和终点站两个字段。
更重要的一个常见需求是树形结构在关系数据库中的表达。为了可以直接操纵一个分支下的全部记录，在层次固定的状况下，咱们可能会增长多个分类字段，例如数 据仓库中的层次维度。在层次数目不肯定的状况下，咱们将不得不使用层次码或者相似于url的其余方案，经过layer_code like '01.01.%' 之类的语句实现分支选择。为了限制选择的深度，咱们可能还须要layer_level字段。基于层次码和层次数，咱们能够创建多种选择算子，例如包含全部 直接子节点，包含自身及全部父节点等等。
http://www.dbazine.com/oracle/or-articles/tropashko4

权限系统(5)--动态性

动态权限最简单的一个表现是时限性，subject只在某个时间段内具备某种权限。这只须要在user和role的映射中，或者role自身的属性中增长startTime和expireTime便可。

更复杂的动态性通常与流程控制相关，此时权限控制应该由工做流系统完成，而不是在数据上增长愈来愈多的权限标记。在witrix平台中，使用tpl模板技术来定制权限设置。
http://canonical.blogdriver.com/canonical/658364.html

 

基于 RBAC 模型的权限管理系统的设计和实现

裴辉东 梁云风

（1. 山东省烟台海颐软件股份有限公司；2山东省烟台东方电子信息产业股份有限公司）

 

摘要：提出了基于RBAC模型的权限管理系统的设计和实现方案。介绍了采用的J2EE架构的多层体系结构设计，阐述了基于角色的访问控制RBAC模型的设计思想，并讨论了权限管理系统的核心面向对象设计模型，以及权限访问、权限控制和权限存储机制等关键技术。

关键词：权限管理系统；角色；访问控制；RBAC模型；J2EE；LDAP

 

0 引言

管 理信息系统是一个复杂的人机交互系统，其中每一个具体环节均可能受到安全威胁。构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的。权限管理系 统是管理信息系统中可代码重用性最高的模块之一。任何多用户的系统都不可避免的涉及到相同的权限需求，都须要解决实体鉴别、数据保密性、数据完整性、防抵 赖和访问控制等安全服务(据ISO7498-2)。例如，访问控制服务要求系统根据操做者已经设定的操做权限，控制操做者能够访问哪些资源，以及肯定对资源如何进行操做。

目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不一样的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只知足自身系统的权限管理须要，不管在数据存储、权限访问和权限控制机制等方面均可能不同，这种不一致性存在以下弊端：

a.系统管理员须要维护多套权限管理系统，重复劳动。

b.用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证。

c.因为权限管理系统的设计不一样，概念解释不一样，采用的技术有差别，权限管理系统之间的集成存在问题，实现单点登陆难度十分大，也给企业构建企业门户带来困难。

采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的做用，是十分必要的。

本文介绍一种基于角色的访问控制RBAC（Role-Based policies Access Control）模型的权限管理系统的设计和实现，系统采用基于J2EE架构技术实现。并以讨论了应用系统如何进行权限的访问和控制。

 

1 采用 J2EE 架构设计

采用J2EE企业平台架构构建权限管理系统。J2EE架构集成了先进的软件体系架构思想，具备采用多层分布式应用模型、基于组件并能重用组件、统一彻底模型和灵活的事务处理控制等特色。

系统逻辑上分为四层：客户层、Web层、业务层和资源层。

a. 客户层主要负责人机交互。可使系统管理员经过Web浏览器访问，也能够提供不一样业务系统的API、Web Service调用。

b. Web层封装了用来提供经过Web访问本系统的客户端的表示层逻辑的服务。

c. 业务层提供业务服务，包括业务数据和业务逻辑，集中了系统业务处理。主要的业务管理模块包括组织机构管理、用户管理、资源管理、权限管理和访问控制几个部分。

d. 资源层主要负责数据的存储、组织和管理等。资源层提供了两种实现方式：大型关系型数据库（如ORACLE）和LDAP（Light Directory Access Protocol，轻量级目录访问协议）目录服务器（如微软的活动目录）。

2 RBAC 模型

访问控制是针对越权使用资源的防护措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能作什么，也决定表明必定用户利益的程序能作什么 ^[1]。

企业环境中的访问控制策略通常有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，两者工做量大，不便于管理 ^[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减少受权管理的复杂性，下降管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

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 RBAC0模型

 

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

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

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

d. RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

3 核心对象模型设计

根据RBAC模型的权限设计思想，创建权限管理系统的核心对象模型。如图2所示。

对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操做（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述以下：

                                              

图2 权限管理系统核心类图

 

a .控制对象：是系统所要保护的资源（Resource），能够被访问的对象。资源的定义须要注意如下两个问题：

1.资源具备层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如能够访问按钮，则必须可以访问页面。

2.这里说起的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于肯定权限管理系统和应用系统之间的管理边界，权限管理系统须要对于资源的类别进行权限管理，而应用系统须要对特定资源的实例进行权限管理。二者的区分主要是基于如下两点考虑：

一方面，资源实例的权限常具备资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。

例如，在管理信息系统中，须要按照营业区域划分不一样部门的客户，A区和B区都具备修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。若是规定A区只能修改A区管理的客户资料，就必需要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）自己应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操做，能够修改属于本身管辖的信息内容。

另外一方面，资源的实例权限常具备至关大的业务逻辑相关性。对不一样的业务逻辑，经常意味着彻底不一样的权限断定原则和策略。

b.权限：对受保护的资源操做的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不一样的资源类别可能采用不一样的访问模式（Access Mode）。例如，页面具备能打开、不能打开的访问模式，按钮具备可用、不可用的访问模式，文本编辑框具备可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。

c.用户：是权限的拥有者或主体。用户和权限实现分离，经过受权管理进行绑定。

d.用户组：一组用户的集合。在业务逻辑的判断中，能够实现基于我的身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（我的的身份）的方式。

e.角色：权限分配的单位与载体。角色经过继承关系支持分级的权限实现。例如，科长角色同时具备科长角色、科内不一样业务人员角色。

f.操做：完成资源的类别和访问策略之间的绑定。

g.分配角色权限PA：实现操做和角色之间的关联关系映射。

h.分配用户角色UA：实现用户和角色之间的关联关系映射。

该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操做，每一个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。

4 权限访问机制

权限管理系统端：提供集中管理权限的服务，负责提供用户的鉴别、用户信息、组织结构信息,以及权限关系表的计算。如图3所示。

图3 权限的访问示意图

Fig.3 Privilege invoke

系统根据用户，角色、操做、访问策略和控制对象之间的关联关系，同时考虑权限的正负向授予，计算出用户的最小权限。在业务逻辑层采用Session Bean实现此服务，也能够发布成Web Service。采用代理Proxy模式，集中控制来自应用系统的所要访问的权限计算服务，并返回权限关系表，即二元组{ObjectId，OperatorId}。

应用系统端：能够经过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。以基于J2EE框架的应用系统为例，说明访问过程：

a.首先采用基于表单的验证，利用Servlet方式集中处理登陆请求 ^[2]。 考虑到须要鉴别的实体是用户，采用基于ACL访问方式。用户登陆时调用权限管理系统的用户鉴别服务，若是验证成功，调用权限计算服务，并返回权限关系表， 以HashMap的方式存放到登陆用户的全局Session中；若是没有全局的Session或者过时，则被导向到登陆页面，从新获取权限。

b.直接URL资源采用基于CL访问方式进行的访问控制。若是用户直接输入URL地址访问页面，有两种方法控制访问：1.经过权限标签读取CL进行控制；2.采起Filter模式，进行权限控制，若是没有权限，则重定向到登陆页面。

5 权限控制机制

权 限所要控制的资源类别是根据应用系统的须要而定义的，具备的语义和控制规则也是应用系统提供的，对于权限管理系统来讲是透明的，权限将不一样应用系统的资源 和操做统一对待。应用系统调用权限管理系统所得到的权限关系表，也是须要应用系统来解释的。按此设计，权限管理系统的通用性较强，权限的控制机制则由应用 系统负责处理。

因为应用系统的权限控制与特定的技术环境有关，以基于J2EE架构的应用系统为例来讲明，系统主要的展现组件是JSP页面，采用标记库和权限控制组件共同来实现。

a. 权限标识：利用标签来标识不一样级别资源，页面权限标签将标识页面对象。

b. 权限注册：遍历JSP页面上的权限控制标签，读取JSP的控制权限。经过权限注册组件将JSP页面上的权限控制对象以及规则注册到权限管理信息系统中。

c. 权限控制：应用系统用户登陆系统时，从权限管理系统得到权限关系表以后，一方面，权限标签控制页面展现；另外一方面，利用权限控制组件在业务逻辑中进行相应的权限控制，尤为是和业务逻辑紧密联系的控制对象实例的权限控制。

6 权限存储机制

权限管理系统采用了两种可选的存储机制：LDAP（Lightweight Directory Access Protocol）目录服务数据库和关系型数据库。存储用户信息、组织结构、角色、操做、访问模式等信息。

其中，目录服务系统基于LDAP标准，具备普遍的数据整合和共享能力。元目录（Meta-Directory）功能容许快速、简洁的与企业现存基础结构进行集成，解决基于传统RDBMS等用户数据库与LDAP用户数据库的同步问题。

7 结语

本文论述了一种基于RBAC模型的权限管理系统的实现技术方案。该权限管理系统已成功应用于系统的设计和开发实践，与应用系统具备很好的集成。实践代表，采用基于RBAC模型的权限具备如下优点：权限分配直观、容易理解，便于使用；扩展性好，支持岗位、权限多变的需求；分级权限适合分层的组织结构形式；重用性强。

 

参考文献

1. 段云所（著）（Duan Yunsuo）。信息安全概论。北京:高等教育出版社（Beijing：Publishing House of Higher Education），2003

2. Kevin Duffey Vikram Goyal Ted Husted著。JSP站点设计编程指南（Professional JSP Site Design）。北京：电子工业出版社（Beijing：Publishing House of Electronics Industry），2002