基于实例团队和任务的RBAC模型

许俊峰,许珊珊,刘 鑫

(杭州电子科技大学理图形图像研究所,浙江杭州310018)

0 引 言

近年来,信息管理系统随着计算机应用技术的快速发展变的越来越复杂,系统的安全问题越来越重要,而访问控制是整个系统安全的重要组成部分。人们提出了各种各样的满足系统安全管理需求的访问控制模型。传统的访问控制模型主要包括自主访问控制模型(Discretionary Access Control,DAC)和强制访问控制模型(Mandatory Access Control,MAC)等。由Sandhu R提出的RBAC96(Role-Based Access Control,RBAC)模型[1]和ARBAC97模型[2]引进了“角色”的概念。在RBAC模型中,先将访问权限先分配给角色,然后再将用户分配给适当的角色,从而获得相应角色的权限。但RBAC模型属于静态的分配权限,它没有将任务从角色中分离出来[3],而且没有考虑到工作流[4]。所谓任务,就是在系统中所要进行的操作的统称。工作流是为完成某一目标而由多个相关任务(活动)构成的业务流程。基于任务的访问控制(Task-Based Access Control,TBAC)模型[5,6]从应用出发,基于工作流建模。TBAC模型依据任务和任务状态的不同,对权限进行动态管理,是一种基于实例的访问控制模型。在RBAC的基础上Sejong Oh等提出了基于任务和角色的访问控制模型(Task-role-based Access Control,T-RBAC)已成为目前工作流访问控制的主要方式。T-RBAC模型不是将访问权限分配给角色,而是将访问权限分配给任务,然后任务分配给角色[7],用户通过动态指派的角色获取执行的任务,进而获取权限。

1 基于实例团队和任务的RBAC访问控制模型

在实际的工作流中,一个工作流实例包含一个或多个任务,对每个任务而言,可能需要多个角色来协作完成,而且每个角色集中可能包含多个用户。因为拥有相同角色的用户间执行的任务实例不一定相同,所以任务实例仅通过判断用户的角色来动态分配权限会导致拥有相同角色的不同用户间的“越权”访问。

为解决上述问题,该文根据RBAC模型和工作流管理系统的特征,提出了基于实例团队和任务的RBAC访问控制模型(IGT_RBAC)。

1.1 模型描述

基于实例团队和任务的RBAC访问控制(IGT-RBAC)模型在RBAC模型的基础上引入了实例团队(Instance Group)和任务(Task)的概念。如图1所示。

图1 IGT-RBAC模型图

该文给出如下形式化定义:

(1)用户和角色。用户是指访问计算机系统资源的主体,通常指人;用USERS表示系统中所有用户的集合。角色指在企业组织或者一个任务中某一个用户拥有或期望拥有的一种职责或地位,用ROLES表示系统中所有角色组成的集合;

(2)权限。权限是对计算机系统被保护的数据或资源进行访问和操作的许可,被定义为信息对象和其访问模式的组合[3];用PERMS表示系统中所有权限的集合;

(3)任务和会话。任务是一项工作的最小组合,它可以表示为一种权限的集合;用TASKS表示系统中所有任务的集合。任务在运行中的每一次执行(即任务实例),系统就会创建一次会话,用户通过会话来动态的激活角色;

(4)权限和任务分派关系。任务在执行时所需要的最小权限集。用一个二元组表示PTA(permission-id,task-id),其中PTA⊆PERMS×TASKS;

(5)任务和角色的分派关系。一个角色可以执行多项任务;一项任务可以分派给多个角色。用一个二元组表示TRA(task-id,role),其中TRA⊆TASKS×ROLES;

(6)用户和角色的分派关系。一个用户可以拥有多个角色;一个角色可以分派给多个用户。用一个二元组表示URA(user-id,role),其中URA⊆USERS×RLOES;

(7)实例团队分派关系。用一个三元组表示IGA(task-id,instance-id,users),其中users⊆USERS。任务每执行一次实例,就确定了执行本次实例的所有用户的集合,称之为本次执行的实例团队;

(8)角色继承。它定义了企业内部角色间的继承关系;

(9)任务继承。它定义了任务间的继承关系,用一个二元组表示TH(task-id,task-id),其中TH⊆TASKS×TASKS。如果任务T2继承自任务T1,则的T2的所有团队成员也必须是T1的成员。

1.2 模型约束条件

IGT-RBAC模型还遵循以下几个约束条件:

(1)任务状态。对工作流任务来说,包括未启动状态,激活状态,挂起状态,完成状态等。任务只有处于激活状态才能激活角色分派权限,任务处于其它状态时即使用户不能激活自己的角色,也就不能获取操作权限;

(2)最小权限。赋予用户的权限不能超过他执行任务时所需的权限。任务在执行时,需要先确定执行这项任务的最小权限集,然后将用户获取的权限限制在最小权限集范围之内;

(3)职责分离。任意用户不能同时拥有两个互斥的角色,如一个用户在同一个任务中不能既是申请者,又是该申请的批复者。同一个角色也不可承担两个要求权限分离的任务[8];

(4)任务约束。如果任务Ti和Tj在实例级是互斥的,并且实例Ti和Tj是两个不同的工作流实例,职责分离原则不允许用户既执行Ti又执行Tj。

1.3 权限分派策略

IGT-RBAC模型的主要思想是将权限分配给任务,任务执行开始时指派实例团队,再将任务分配给角色,角色通过任务与权限相关联,用户通过角色和实例团队获取权限。

根据企业的层次结构和职权抽象出角色,确定用户和角色的分派关系(URA)。对工作流任务来说,任务都具有相应的操作权限,任务将执行任务的权限分派给角色(TRA)。在实际应用中,任务只有被实例化后才能执行,但角色的分派只与任务有关而与任务实例无关。任务在实例化的时候确定完成本次任务的用户集合,即实例团队(IG⊆USERS)。

用户在任务实例化后才能激活自己的角色,进而获取执行该任务的权限,因而权限的分配是动态的。用户获取权限的过程如图2所示。

图2 IGT-RBAC中用户获取权限过程

2 应用实例

在建筑协同设计流程中,可以将一个小区的建筑规划设计看作是一个项目,而小区里每幢楼的规划设计称为该项目的一个单体。在实际实现时,整个项目有一个总的设计流程,每个单体也都有自己独立的单体流程,通过单体流程来分析IGT-RBAC模型的权限分派过程:

单体流程有个主流程:启动节点、阶段一的节点5、阶段二的节点9,结束节点。每个专业的每个阶段都有一个子流程:其中阶段一包括节点1到节点4;阶段二包括节点6到节点8。主流程启动后,各专业流程随主流程启动而开始执行,且各自独立运行互不影响。当所有专业的节点4都执行完后交回主流程的节点5;所有专业的节点8都执行完后交回主流程的节点9。主流程的节点9执行完后整个流程结束。由于采用的是状态机工作流,可以根据流程逻辑设置流程中的任一节点的跳转状态,使其执行完后跳转到该流程中的任一其它节点。

单体的流程如表1所示:其中0表示未执行,箭头表示正在执行,1表示已执行,每一个小方格定义为一个节点。

表1 单体流程示意图

IGT-RBAC模型对工作流系统的访问控制是从用户登录系统后对某一个想要进行操作的任务实例的节点的访问申请开始,首先通过用户的登录信息获取系统中用户的当前激活的角色集以判断是否有执行该任务的权限,再检查该任务实例的状态并根据不同的状态得到可对该任务实例节点的操作集合及执行该任务的角色集合,比如任务处于完成状态则仅可能有查看权限等,然后比较用户的激活角色集和执行节点任务所需的角色集,如果该节点所需角色集为用户当前激活角色集的子集则说明该用户已经拥有了执行该任务所需的角色要求,最后再比较该用户是否属于执行该任务的实例团队,若属于则根据得到的该任务节点的操作集合赋予用户执行该任务应有的最小权限集。

建筑协同设计工作流系统中当前用户对某任务节点提出访问申请后系统验证用户能否获取权限的具体实现步骤如下:

(1)执行BoolAssignPerm ission(user-id,task-id,instance-id,node-id)函数检查用户能否成功获取权限,该函数返回一个布尔值,若为true获取成功,false则获取失败,具体步骤如下。

1)根据URA策略,系统调用GetUserActiveRoleSet(user-id)检查并记录该用户可以激活的角色集userRoles;

2)系统调用GetTaskInstanceStatus(task-id,instance-id,node-id)获取任务节点的当前状态,如果为终止状态则直接返回false,否则根据不同的状态得到相应状态调用GetTaskRolesInfo(task-id,node-id)获取任务角色信息taskRoles;

3)判断taskRoles是否为userRoles的一个子集,是则转到(4);否则返回false;

4)根据IGA策略,通过调用GetInstanceGroup(task-id,instance-id)得到该任务实例的实例团队ins-Group;如果user-id属于insGroup,转(5);否则返回false;

5)调用CheckUserCurConstraints(user-id,instance-id,node-id)检查用户当前的约束,若满足当前约束条件,则返回true;否则返回false;

(2)若步骤1返回true,说明该用户可以拥有与该任务节点相关的权限,然后需要执行GetMessageAllowed(instance-id)以遍历工作流当前正在执行的状态中已经启用的活动,如果当前活动节点已经启用并且是一个事件驱动活动,则执行FindMessageAllowed(compositeActivity,messages)方法找到该活动允许的所有事件名,即用户在该任务节点上可以执行的事件列表,最后根据TPA策略,调用GetTaskPermissions(task-id,node-id,event-id)分派给该用户执行任务时的最小操作权限集permissions;至此用户可以根据得到的权限集(permissions)执行相关的操作。若步骤1返回false,则用户获取权限失败,结束。

3 结束语

该文提出了一种基于实例团队和任务的RBAC访问控制模型,并成功应用在某建筑设计院工作流管理系统中。IGT-RBAC模型对权限的分派不仅仅是根据用户动态激活的角色,而是通过增加实例团队的概念来分派权限,有效地防止了激活不同任务实例的拥有相同角色的不同用户非法访问不属于自己实例的资源,提高了系统的安全性。

[1] Sandhu R,Coyne E J.Role—based access controlmodels[J].IEEECom puter,1996,29(2):38-47.

[2] Sandhu R S,Bhamidipati V,Munawer Q.The ARBAC97model for role-based adm inistration of roles[J].ACM Trans,1999,2(1):105-135.

[3] Sejong Oh,Seog Park.Task-role-based access controlmodel[J].In formation Systems,2003,28(5):533–562.

[4] 范玉顺.工作流管理技术基础[M].北京:清华大学出版社,2001:7-13.

[5] 邓集波,洪帆.基于任务的访问控制模型[J].软件学报,2003,14(1):76-81.

[6] Thomas R.K.,Sandhu R S.Task-based authorization controls(TBAC):a fam ily ofmodels for active and enterprise-oriented authorizationmanagement[C].London:Chapman＆Hall:International Federation for Information Processing,1997,166-181.

[7] Workflow Management Coalition.The workflow reference model[R].W inchester:WfMC,1995,1-55.

[8] 宋善德,刘伟.基于任务-角色的访问控制模型[J].计算机工程与科学,2005,27(6):4-9.