引言
自从1992年Ferraiolo和Juhn正式提出RBAC(role-based access control)模型以来,其直观、完善、经济的特性迅速获得了企业信息系统中常用的访问控制解决方案的青睐,由于RBAC模型在商业和政府领域的成功应用,ANSI和INCITS于2004年2月正式接受RBAC模型为国家标准.RBAC模型直接将企业管理特征映射到了权限管理,在解决企业和政府部门统一资源访问控制方面具有很大的优势.
核心RBAC模型的概念包含用户User、角色Role、操 作Operation、对 象Object、权 限Permis-sion、会话Session.用户与特定的一个或多个角色相联系,角色的概念源于实际工作中的职务岗位,一个职务具有处理工作中某些事务的权限,因此角色就与一个或多个访问权限相联系.逻辑分离的用户和权限由角色相关联,通过将角色指派给用户使之获得一定权限,而每个会话是一个用户到多个角色的一次映射.而大型企业通常部门用户众多、职务变动频繁、业务对象庞杂,核心RBAC模型仅依靠调整角色的定义来改变授权,虽有效减少了授权管理的复杂性,但仍难适应于企业复杂业务需求的变化.
为此,本文在核心RBAC模型的基础上,提出一种对用户和角色混合授权的RBAC改进模型.
1 RBAC改进模型
1.1 模型概念和特点
针对核心RBAC模型的问题,再结合国内企业通常有直接对用户授权的实际客户需求,笔者在核心RBAC模型的基础上引入了用户权限指派,采用了对用户和角色混合授权的折中方法,简化了用户操作,降低了角色数量,也避免了角色定义、用户职责与业务功能变更所带来的诸多问题.图1即是对用户和角色混合授权的RBAC改进模型.【图1】
相对于核心RBAC模型,增强后的RBAC改进模型具有如下结构特点:
1)可直接对用户进行授权.除了可以对角色进行授权外,也可针对用户直接进行授权,即将权限直接授予用户.角色授权仍然是权限管理的核心,直接用户授权则是在角色授权基础上的补充完善,其主要用于处理一些难以用角色授权实现的临时性、特殊性的权限需求.当用户因业务要求需暂时拥有某些权限时,可直接对用户赋予相应的权限,无需增加新的角色,以此改善了授权的灵活性.
2)针对用户权限加入继承约束.针对某业务对象的某一操作权限,继承约束用于实现在角色权限和用户权限间进行切换.“继承”指继承使用用户所拥有的角色的权限,而不使用直接对用户授予的权限;“不继承”指使用对用户直接授予的权限,而不继承用户所属的角色的权限.针对某业务对象的某一操作权限进行用户直接授权后,欲启用该权限,还需设置权限为“不继承”;当不再需要该权限时,无需撤销用户权限,只需设置权限为“继承”即可.也就是说模型的临时授权是依靠继承约束来开启和禁止的,继承约束避免了角色授权和用户授权同时有效时所带来的权限冲突问题,也降低了添加和删除临时授权过程的复杂度.
3)针对角色加入优先级约束.用户拥有多个角色时,角色间的权限可能发生冲突,如对某一资源的某一操作,一个角色为“允许”,另一个角色却为“禁止”.为了解决多角色间的权限冲突,在角色中引入优先级属性,即权限冲突时,以优先级高的角色为准.优先级是对某一用户所属的某一角色而言,可针对不同用户分别设定不同的优先级,即同一角色对于不同的用户会有不同的优先级.优先级约束使得无需额外引入冲突解决算法就解决了具有冲突关系的两个角色不能同时赋予同一用户的问题,降低了访问控制模型的复杂度,简化了权限管理模块的编程实现.
1.2 模型要素
RBAC改进模型的形式化描述如下: 定义1用户会话(US:Sessions→Users):映射每个会话到一个用户.
定义2角色会话(SR:Sessions→2Roles):映射每个会话到一组角色.
模型中的主要集合包括:
1)用户集Users={u1,u2,…,un},表示所有用户的集合.
2)角色集Roles={r1,r2,…,rn},表示所有角色的集合.
3)权限集Perms={p1,p2,…,pn},权限pi是一个二元组(obi,opi),obi表示业务对象,opi表示操作.
4)会话集Sessions={s1,s2,…,sn},表示所有会话的集合.
模型中的主要函数关系包括:
1)用户角色指派AssignedUsersRoles:Users→2Roles,为用户u∈Users分派一组角色集.
2)角色权限指派AssignedRolesPerms:Roles→2Perms,为角色r∈Roles分派一组权限集.
优先级约束设置SetPriority(ui,rj,priority),针对某一用户的某一角色可以设置优先级约束,以消除多角色间的权限冲突.
3)用户权限指派AssignedUsersPerms:Users→2Perms,直接为用户u∈Users分派一组权限集.继承约束设置SetExtend(ui,pj,true|false),在用户权限指派时,针对某一用户的某一权限还需设置继承约束,即对此用户是否启用该权限.
4)用户角色激活ActiveRoles:Sessions× Us-ers→2Roles,在一个会话期s∈Sessions内,激活用户u∈Users被指派的一组角色.
5)用户权限合成UsersPermsComposite:Ses-sions× Users→2Perms,其中{p∈Perms,Perms?AssignedRolesPerms(Perms)|AssignedUsersPer-ms(Perms)},即会话s∈Sessions中用户u∈Users的权限合成是用户角色权限或用户直接权限.
6)对象访问控制ObjectsAccessControl:Ses-sions× Users→2{(ob,op)},其中{(ob,op)∈Assigne-dRolesPerms(ob,op)|AssignedUsersPerms(ob,op)},即会话s∈Sessions中用户u∈Users的对象访问控制,针对同一业务对象ob,用户角色权限op或用户直接权限op只有其一有效.
以上主要函数关系基本上也阐述了RBAC改进模型的授权算法,因此以下只给出其认证算法:
算法HasPermission(u,ob,op) 输入:用户u,业务对象ob和操作权限op 输出:flag,即用户u对业务对象ob是否有操作权限op flag←false Ptmp←AssignedPerms(u)/*查找直接授予用户的权限集*/ if(ob,op)∈ Ptmp if GetExtend(ob,op)/*如果 “不继承”角色权限*/ flag←true return flag endif endif Ri←AssignedRoles(u)/*查找分 配 给 用 户 的 角 色*/ Rj←OrderByPriority(Ri) for all r∈Rjdo/*依照角色优先级依次查找授权*/ Pr←AssignedPerms(r) if(ob,op)∈Pr flag←true endif endfor returnflag 算法首先查找系统是否直接对用户进行过授权AssignedPerms(u),即是否设置了临时授权Ptmp;然后确认该权限是否为“不继承”GetExtend(ob,op),即临时授权是否启用.如果以上条件都不满足则不使用临时授权,而使用角色授权,此时为了解决多角色间的权限冲突,先将角色按优先级排序,再依序查找核对,以确认是否有对应权限.
2 RBAC改进模型的UML建模
由于RBAC模型的抽象性、形式性,它通常难以被软件开发者所理解,为了缩短理论安全模型和实际应用开发间的鸿沟,本文采用统一建模语言(UML)对RBAC改进模型进行了静态和动态建模,以面向对象的方法对模型做了分析和设计.以下先进行静态建模,即给出模型的实体类图,再分别对授权与认证功能进行动态建模,给出授权与认证功能的活动图.
2.1 模型的静态建模
根据RBAC改进模型构造的实体类图如图2所示,图中给出了模型的实体类、类间的关联关系以及关联的基数特征,领域对象具体有用户User、角色Role、用户角色关系UsersRoles、模块Module、权限Permission及访问控制列表ACL.用户指企业工作人员;模块即RBAC模型中的业务对象,其表示企业应用中的功能模块,模块可以有一个父模块或多个子模块;用户对每个模块的访问受到权限的约束,权限指对某一模块所拥有的“CRUD”操作;角色代表一组权限;用户角色关系表明用户所被赋予的角色,即间接指明了用户具有的权限;一个ACL对象表明一个角色或用户(只能是其一)对一个模块所能执行的CRUD操作,一个用户的全部ACL对象即表达了该用户在系统中所具有的权限集合.
用户对模块的操作包括CRUD四种,每一种操作都对应一个的“允许/禁止”标识.最直观的设计是ACL类针对每种操作都设置一个属性和一个“允许/禁止”标识.但这种设计灵活性较差,比如随着需求的变更,可能需添加其他的操作类型,这就必须在ACL类中增加新的属性才能满足需求.为了适应于未来的需求,设计操作及其“允许/禁止”标识为:在ACL对象中引入一个int类型的属性“授权状态”,用int类型的32位分别表示32种操作,如第0位表示“C”;第1位表示“R”;第2位表示“U”;第3位表示“D”,位的值(对于“位”来说,只能取值0或1)用来表示“允许/禁止”(0表示禁止,1表示允许).在该设计中,操作类型及其“允许/禁止”标识合二为一,能支持将来可能增加的多达32种的操作类型,因此显着提高了系统的可维护性和可扩展性.【图2】 2.2 授权功能的动态建模
授权指将权限授予角色或用户,通常情况下应先对角色分配模块的权限,再为用户分配相应的角色,如此实现了用户和权限的逻辑分离,简化了权限管理,而用户权限指派则用于临时性的或特殊情况下的授权管理.
图3的活动图描述了模型的授权算法,授权活动分为角色授权和用户直接授权,角色授权指根据AssignedRolesPerms和AssignedUsersRoles进行角色权限指派和用户角色指派,角色授权还需针对用户设置每个角色的优先级,若角色间的授权发生冲突时,则以优先级高的角色为准.
用户直接授权指根据AssignedUsersPerms进行用户权限指派,用户直接授权需设定权限的继承约束,继承约束表现为权限的一个属性,其决定是否启用直接指派的用户权限,若启用,则直接指派的用户权限屏蔽用户的角色权限;若不启用,则以用户的角色权限为准.【图3】
2.3 认证功能的动态建模
认证指当用户对某个模块执行某个操作时,系统根据用户的授权以确认用户能否操作.为了控制用户对模块的增删改查操作,需要决定是否显示相应的按钮或链接,即判断用户对某个模块的某个操作是否被允许,这就需要执行认证算法以确认.
图4的活动图描述了模型的认证算法,用户会话访问资源之前,需根据用户信息提取用户直接权限或用户角色权限,即使用UsersPermsComposite获取用户的有效权限.获取用户直接权限的前提是曾针对该资源指派过用户权限且启用了该用户权限(不继承角色权限).否则就提取用户角色权限,此时使用ActiveRoles获取用户的角色列表,并按优先级对角色降序排序,然后依序在角色中查找是否有对该资源的明确授权,若有授权则立即返回,否则继续在下一个角色中查找.找到对应资源授权后,根据ObjectsAccessControl对象访问控制显示按钮、链接等相关操作组件.【图4】
3 结论
对 角色和用户混合授权的RBAC改进模型无需引入额外的冲突检测算法,避免了角色、用户间的权限冲突;同时解决了临时授权管理繁琐的问题,有效弥补了核心RBAC模型仅依赖角色授权的不足和局限,提高了权限管理的严密性、灵活性和可维护性,也更符合国内企业的实际应用情况.
通过基于UML表述RBAC改进模型,使软件开发者更直观的理解RBAC模型和更易于建立基于角色的信息系统,该模型在基于Java EE的实际企业应用中取到了良好的效果,因其具有一定的通用性,也避免了企业应用中权限管理模块的重复开发.