摘要：针对传统的访问控制模型不能直接应用到工作流和团队协作环境中的现象，本文提出了一种支持工作流和团队协作的增强RBAC模型，通过添加工作流任务、工作流上下文、团队和协同约束等组件，扩展RBAC核心模型，以解决在工作流和团队协作环境中对信息访问控制的特殊要求，提高工作流管理系统的安全性和灵活性。
关键词：角色 任务 访问控制 工作流 团队协作
中图分类号：TN401 文献标识码：A 文章编号：1007-9416（2013）11-0200-02
自20世纪60年代以来，学术界提出了各种信息访问控制模型来满足信息管理系统的安全需求。传统的访问控制模型分为两类：自主访问控制DAC和强制访问控制MAC[1]。DAC是在确认主体身份以及它们所属组的基础上对访问进行限制的一种方法，MAC通过预先定义用户的可信任级别及信息的敏感程度来完成信息的访问控制。美国国家标准与技术研究院提出的RBAC（基于角色的访问控制）模型[2][3]引入了角色的概念，先将访问权限分配给角色，然后再将用户分配给适当的角色，从而获得相应角色的权限。但RBAC模型是被动的安全模型，授权是静态的，没有考虑到工作流[4]。Sandhu提出的TBAC（基于任务的访问控制）模型[5]，依据任务和任务状态的不同，对权限进行管理。虽然TBAC模型支持工作流，但应用于复杂的企业环境时，仍有很多缺陷。例如在企业环境中，角色是一个重要的概念，但TBAC模型没有将角色与任务分开，也不支持角色的层次等级。
上述访问控制模型，虽然得到了很好的应用和发展，但不能直接应用到工作流和团队协作环境中。本文通过对RBAC模型进行扩展，提出了一种支持工作流和团队协作的增强RBAC模型。模型通过引入任务集、任务实例集、工作流上下文、实例团队和协同约束等组件，来支持工作流和团队协作的特殊需求。
1 RBAC访问控制模型
RBAC模型引入了角色的概念，通过角色控制用户访问计算机的资源，参考模型如图1所示。在RBAC中，权限被定义为操作和对象的集合，这些权限不是直接分配给特定的用户，而是通过用户角色分配（URA）和角色权限分配（RPA）来完成用户到权限之间的映射。角色继承（RH）定义了角色之间的继承与包含关系。约束被定义为规范URA、RPA和RH之间的关系，如职责分离是一种典型的约束，要求循环不相容的职责相互分离，实现合理的组织分工，以防止潜在的安全漏洞。RBAC模型通过动态地分配和取消用户的角色来完成用户权限的授予和取消。实现了用户与访问权限的逻辑分离，简化了权限的管理。
RBAC模型的授权是静态的，在执行任务之前，主体就拥有某种权限，在任务执行后，会继续拥有这种权限。在工作流和团队协作环境中，当数据在工作流中流动时，执行任务的用户在变，用户的操作权也在变，此时用户的权限与工作流上下文环境有关，传统的访问控制技术对此无能为力。若使用RBAC，则需要频繁更换角色，给系统管理带来不便。
2 支持工作流和团队协作的访问控制模型
2.1 模型描述
支持工作流和团队协作的访问控制（TG-RBAC）模型如图2所示。TG-RBAC模型的思想是在传统RBAC模型的基础上分别引入工作流任务、工作流上下文、团队和协同约束等组件来支持工作流和团队协作对信息访问控制的特殊需求。
模型的形式化定义如下：
用户：指独立访问计算机系统资源的主体，用USERS表示系统中所有用户的集合。
角色：角色是在企业组织结构或者一个任务中用户拥有的一种职责或地位，用ROLES表示系统中所有角色的集合。
团队和实例团队：团队是拥有不同角色的用户集合和完成特定任务所需要的角色集合，用TEAMS表示系统中所有团队的集合。实例团队是执行一次任务实例所需要的所有用户的集合。
会话：是用户与角色和团队之间的映射。当用户激活了部分或者全部被授予的角色和团队时，就建立了一个会话，用户是通过在会话期间激活角色和团队来获取操作权限和任务的。
权限：是用户对计算机系统资源进行某种操作的许可权，用PERMS表示系统中权限的集合。
任务和任务实例：任务是要进行操作的统称，包括工作流管理系统中的流程任务和用户对计算机系统资源的各种操作权限，用TASKS表示系统中所有任务的集合。任务实例是任务运行中的实例。
角色继承：为了避免相同权限的重复设置，角色除了自身的属性和权限之外，还可以继承其它角色，从而自动拥有被继承角色的属性和权限。
URA：URA USERS×ROLES，表示多对多的用户角色分配关系，即一个用户可以被授予多个角色，一个角色可以分配给多个用户。TRA：TRA TASKS×ROLES，表示多对多的任务角色分配关系。PTA：PTA PERMS×TASKS，表示多对多的权限任务分配关系。UTEA：UTEA USERS×TEAMS，表示多对多的用户团队分配关系。RTEA：RTEA ROLES×TEAMS，表示多对多的角色团队分配关系。TTEA：TTEA ROLES×TEAMS，表示多对多的任务实例团队分配关系。
2.2 模型约束条件
TG-RBAC模型遵守以下约束条件：
（1）普通约束。传统RBAC模型中所定义的一些约束，如职责分离，最小权限等，这些约束同样作用与整个TG-RBAC模型。
（2）工作流上下文约束。在工作流执行过程中作用于任务实例。工作流任务有启动、激活、挂起、完成等状态。任务只有处于激活状态时才能激活角色任务分派权限。工作流上下文还用于约束任务之间的关系。如任务Ti和Tj是实例级互斥的，根据职责分离原则，不允许用户同时拥有执行Ti和Tj的权限。
（3）协同约束。用于团队的协作，约束团队成员任务执行之间的关系。协同用户之间的交互性和分布性使工作流任务在时间上有严格的序列依赖关系。如一项任务的执行结果决定了下一项任务，一项任务必须在其所有的前序任务执行完毕之后才可以启动等。
2.3 模型权限分配策略
TG-RBAC模型是基于角色和任务的动态授权安全模型，任务是角色和权限交互信息的桥梁，权限分配策略是先将操作权限分配给任务（PTA），任务开始执行时指派实例团队（TTEA），再将任务实例动态分配给角色（TRA），角色通过任务与权限相关联，用户通过角色和团队获取权限。任务只有被实例化后才能执行，在任务实例化的过程中确定完成本次任务的用户和角色集合，即实例团队，用户在任务实例化后通过任务角色分配（TRA）动态地获取相应的权限。用户获取权限的过程如图3所示。
3 TG-RBAC模型在建筑协同设计中的应用
建筑协同设计主要包含两个阶段：条件图阶段和设计阶段，每个阶段由五个专业的相关人员协作完成。每个专业又相应的包含若干子阶段，每个子阶段又有若干个节点，而每个节点都需要有对应的角色或岗位来协同操作完成。表1描述了建筑协同设计过程中流程节点与角色的对应关系，如R11表示初步设计阶段中条件图阶段的建筑专业的条件图节点对应的角色或者角色集。
TG-RBAC模型对工作流系统的访问控制从用户登录系统后对某一个任务实例的访问开始。首先获取系统中该用户的当前角色集以判断是否有执行该任务实例的权限；再检查该任务实例的状态并根据不同的状态得到可对该任务实例节点的操作集合及执行该任务所需的角色集合或实例团队，比如任务处于完成状态时，则用户只能拥有查看权限等；然后比较用户的激活角色集和执行节点任务所需要的角色集，如果该节点所需要的角色集为用户当前激活角色集的子集，则说明用户达到了执行该任务实例所需的角色要求；最后再比较该用户是否属于执行该任务的实例团队，若是则根据得到的该任务节点的操作集合赋予用户执行该任务实例应有的最小权限集。
4 结语
该文提出了一种支持工作流和团队协作的增强RBAC模型，并成功应用在某建筑设计院协同设计流程管理系统中。TG-RBAC模型克服了RBAC模型静态授权不能直接应用到工作流和团队协作环境中的缺点，提高了模型的安全性和灵活性。
参考文献
[1]Ebrahim Sahafizadeh，Saeed Parsa.Survey on Access Control Models [J].IEEE International Conference on Future Computer and Communication，2010，2（1）：1-3.
[2]D Ferraiolo，R S andhu.Proposed NIST standard for Role-based access control[J].ACM Transactions on Information and System Security，2001，4（3）：224-274.
[3]Sandhu R，Conyne EJ，Lfeinstein H.Role based access control models[J].IEEE Computer，1996， 29（2）：38-47.
[4]David Hollingsworth. The workflow reference model[M].Workflow Management Coalition，1995：20-44.
[5]邓集波，洪帆.基于任务的访问控制模型[J].软件学报，2003，14（1）：76-81.