Download presentation
Presentation is loading. Please wait.
1
3. RBAC2模型 RBAC2除了继承RBAC0已有的特征外，引 入了一个约束（限制）集。它规定RBAC0各部件的操作是否可被接受，只有可被接受的操作才被允许。
2
RBAC3 RBAC1 RBAC2 RBAC0 RBAC96模型族
3
RBAC96模型可用如下图表示 约 束 U 用户 P 权限 R 角色 S 会话 RH 角色层次
4
在建立一个访问控制系统的模型时，系统管理员可将权限视为一个抽象概念：
计算机操作和资源对象的任意捆绑 在一个计算环境中代表作业运行的一个原子单元 用户获得权限集以便履行职责、任务、功能或其它任何与工作相关的活动 将用户指派到一个角色，使该用户获得该角色的权限，从而具有执行这些活动的能力 指派给角色的权限，反映了机构或组织的部分的策略性决定
5
从方法和访问的粒度上细化权限指派 考虑一个例子（方法粒度细化）： 一个银行中出纳员和会计主管访问需求之间的差别。企业将出纳员角色定义为能够履行存款操作的角色。这就需要在一个存款文件中有对指定数据域的读和写访问权限 企业也可将会计主管角色定义为允许履行修正操作的角色。这些操作需要与出纳员在存款文件中所需的对指定数据域相同的读与写访问权限
6
会计主管可能不被允许处理存款或取款操作 ，而仅仅履行事后修正的操作
同样地，一旦事务完成，出纳员就不允许执行任何修正工作 这两种角色怎样区分呢？可依据可被执行的操作和写到事务log文件中的数值来区分
7
第二个例子（访问粒度细化）： 考虑一个药剂师访问病人的记录。这些记录是用来检查药物间的相互作用以及记录病人的用药情况。这些操作是必要的，但是药剂师不能阅读或修改病人记录的其他部分
8
例如，一个系统可以约束一名护士，可以在某病人的历史治疗记录中增加新的治疗项目，但通常不能修改该病人的历史记录
权限指派给角色须遵守自我约束的规则 例如，一个体检中心可以约束临床医生角色，仅在规定时间、位置张贴某些体检项目的测验，随意张贴发布，其结果会导致侵害病人隐私权等。权限指派可以与法律和规章的强制执行相关(乙肝例） 例如，一个系统可以约束一名护士，可以在某病人的历史治疗记录中增加新的治疗项目，但通常不能修改该病人的历史记录 药剂师具有为病人配药的权限，而不能开处方、施药
9
RBAC所控制的操作以及对象（客体）的类型依赖于该模型被实现的系统类型。例如，在一个操作系统中，操作可能包括读、写和执行；在一个数据库管理系统（DBMS）中，操作可能包括插入、删除、添加和更新；而在一个事务管理系统中，操作将采取一个事务的形式并展示该事务所有属性 RBAC系统的对象包括所有RBAC操作访问的对象。然而，系统对象却不包含在RBAC方案中。例如，访问系统级对象，如同步对象（e.g.，信号量，管道，和信息段）和临时对象（e.g.，临时文件和缓冲区）不必控制在RBAC保护集中。操作系统下的资源管理工作是保护那些支持进程隔离的对象，以及预防旁路攻击的安全，RBAC对象并不限于信息载体。RBAC对象能够代表可耗尽系统资源，比如打印机，磁盘空间，以及CPU周期
10
下图是一对二元关系：一是操作与对象的关系，所指的是一种权限，另一个是角色和权限的关系。
11
下图表示动态映射和静态关系之集合，这些关系和映射是用户访问一个对象必须的。这些虚线箭头描绘了动态映射，实线箭头描绘了静态关系
12
角色激活 RBAC模型所定义的属性以及映射可被分为两个独立但却相互依赖的静态和动态部件 静态部件是以RBAC关系的术语来定义的，而这些关系不包括主体概念（实际与session等价）
13
为计算机系统应用动态安全策略时，谈到主体，是激活的实体，是对受控的角色、操作和客体的访问
主体代表用户执行所有的请求。每一个主体有一个独一无二的标识符使主体能够被引用，该标识符被用来决定主体是否被指派到一个角色以及能否激活该角色 一个用户在任何时刻都可及时与多个主体相联系
14
每一个主体都可能拥有一个不同激活的角色组合。这个特征支持最小特权原则，因此一个指派给多个角色的用户，可以激活这些角色的任何子集，而便于其任务的执行
限制能被一个主体激活的角色，可以限制主体的访问空间。所谓访问空间是指派给那些被激活的角色的许可定义的访问空间。定义可应用到激活角色的约束关系，能够支持SoD策略和完善最小特权原则
15
RBAC的动态部件包括角色激活和主体访问
一个是将主体映射到用户集 另一个是每一个主体映射到一个活动角色集
16
CORE RBAC 模型如下定义： USERS, ROLES, OPS, and OBS (分别为用户, 角色, 操作, 和对象) UA USERS ×ROLES 用户和角色间的多对多映射（用户到角色指派关系） assigned_users：(r:ROLES) →2USERS 角色r到用户集的映射 形式化描述： assigned_users(r) = {u ∈ USERS |(u,r) ∈ UA} PRMS = 2(OPS × OBS) , 许可权限集 PA PRMS ×ROLES 许可权限和角色间的多对多映射（用户-权限指派关系）
17
assigned_permissions(r: ROLES) → 2PRMS
形式化描述： assigned_permissions(r) = {p ∈PRMS|(p,r) ∈PA} SUBJECTS, 主体的集合 subject_user(s: SUBJECTS) →USERS 主体 s 到主体相关用户的映射 subject_roles(s:SUBJECTS) → 2ROLES, 主体s到角色集的映射 subject_roles(si ) {r∈ROLES|(subject_user(si ),r) ∈UA}
18
性质1 角色授权 一个主体绝不可以拥有一个非授权用户的活动角色。
∀s:SUBJECTS, u : USERS, r :ROLES r∈ subject_roles(s) ^ u∈subject_user(s) ⇒ u∈assigned_users(r) access: SUBJECTS × OPS × OBS→ BOOLEAN; 如果主体s 可以op客体 o（对o实施操作 op）： access(s, op, o) =1； 否则 access(s, op, o) =0
19
性质2 对象访问授权 一个主体s能在对象o上执行操作op仅当存在一个角色r，它属于主体的活动角色集，以及存在一个指派给r的允许对o执行操作op的许可权限
s:SUBJECTS, op:OPS, o:OBS access(s, op, o) ⇒ ∃r: ROLES, p:PRMS r∈ subject_role （s）^ p ∈assigned_permissions(r) ^ (op, o) ∈p
20
企业视图到系统视图的映射 使用的专用术语中，权限是依赖系统的，而许可则被映射到权限上。每一个系统有属于它自己的操作和资源。一个角色的作用范围与权限类别有关，这些权限能够用操作和RBAC系统控制访问的系统资源来描述。尽管权限是依赖系统的，但用户和角色在跨越多个系统时能够拥有共同的含义
21
用户 “John Smith” 可以拥有多个系统账号，能够在多个系统中访问相关资源。类似地，应收会计文员角色亦可被指派跨越几个不同系统和应用程序的许可权限。总的来说，用户、角色和许可被视为全局实体，最后指派给角色的许可则仅限于局部的计算环境 Tom和John是贷款职员。他们使用他们的角色许可去读账目数据，写贷款数据和执行事务A、B和C。角色许可为用户授权，以期这些用户能够履行他们的工作，而这些权限指派给角色，使授权用户可以访问受保护的资源。为了使角色许可生效，访问权力必须被建立在受影响的服务器和应用软件中，换句话说，就是许可必须被映射到指定系统的权限集
23
核心RBAC需要卖方提供一个映射和维持角色许可关系的方法。这些映射是如何实现的并不重要，详细指出用户角色和角色权限关系才是最重要的
因为RBAC模型不会说明映射一个RBAC企业视图到系统级视图的技术要求，IT消费者必须考虑他们的具体需要和应用，去估计和比较相匹敌的产品
24
全局用户和角色，间接用户权限 第一个将企业级RBAC视图到一个系统级视图的方法，是创建和维护在RBAC用户和本地用户ID之间的直接关系以及在RBAC角色和本地群组之间的直接关系。本地管理界面可被用来保护本地资源，通常用RBAC系统创建的用户ID和群组术语来描述
25
依据上述方法，RBAC系统将各个系统中的用户帐号ID和企业级用户关联，这样可以统一管理所有的用户ID。指定系统的用户ID通常组织成用户组。相应地，安全管理员不必为每一个用户授权，仅需要授权给群组，以访问资源。在企业级映射RBAC实体到系统级权限，群组和用户ID是最重要的
26
在企业级，用户依据角色指派被组织到角色中。一个角色负责整个企业工作的一个部分的执行。是借助指派给角色的许可权限，该工作才被执行。为了创建一个企业视图到系统级群组的映射，RBAC系统将指派到对应角色中的用户填入群组。RBAC系统将本地群组的成员资格授予一个用户，该用户必须拥有该系统的账号。结果对本地系统群组中的用户，RBAC系统必须首先为其创建一个本地用户账号。RBAC系统完成这个用户、角色到用户ID以及几个本地系统中的群组的映射 也存在本地系统中的单个用户和单个角色需要映射到多个系统
27
因此，在企业级删除一个用户角色指派可能会导致该用户在多个系统中的多个群组的成员资格的删除。在企业级，任何角色映射已完成的系统中，一个用户角色指派导致用户ID的创建以及群组成员资格的授予。实施这一方案，RBAC系统在其控制范围，能通过在企业级处理用户角色指派来管理用户ID和群组。这种映射关系可存储在任何便于存储和查询的重要数据库或目录中
28
一旦RBAC系统在系统级创建了用户ID，群组和群组成员资格，本地管理员就可用本地权限来表达用户ID和群组，从而保护本地资源。例如，一个本地ACL机制可被用来表达权限。一旦这些本地权限被建立，指派给这些角色的用户可映射到这些组（保护本地系统资源的一种表达），然后这些用户可登录到那个系统访问资源
29
在企业级，用户Tom和John被指派到贷款职员角色。Tom和John的角色在系统级通过创建对应的用户ID和对应的群组（Tom和John具有这些群组的成员资格）完成到system1的映射
在系统级，一个本地管理员界面被用来创建一个ACL，此ACL给群组的贷款职员读访问loan_data目录下文件的权限
31
RBAC管理员可集中地以这些抽象操作和抽象资源术语完成权限到角色的指派，因而完成对跨越一个或多个系统的真实资源创建ACLs（亦即权限）的任务
许可到权限的映射 在企业级，为了允许定义不依赖系统的权限，RBAC系统提供了抽象操作和抽象资源。在系统级，每一个抽象操作可一对多地映射到现实系统的具体操作。通过这个映射过程，指定系统通过创建与抽象操作等价的具体操作，完成了对一般操作的翻译问题。与此相似，抽象资源能够一对多地被映射到现实系统中的真实资源 RBAC管理员可集中地以这些抽象操作和抽象资源术语完成权限到角色的指派，因而完成对跨越一个或多个系统的真实资源创建ACLs（亦即权限）的任务
32
一旦映射被建立，权限的任何变化可导致这些ACLs（权限）对应的变化。如下图，因为贷款职员被指派权限可对loans进行写操作，当抽象贷款资源被映射（例示）时，这可能会导致一个ACL的自动调配，该调配是抽象操作“写”的本地系统翻译的结果。图中抽象资源“贷款”被映射到System1的真实资源“loan_data”,和其它系统中另外2个真实资源 抽象操作“写”对应于System1中的“w”操作
34
层次结构和继承形式 层次角色可以用来支持多种组织结构，如分级制度、功能图和地域分责 继承特点 二元关系 角色层次 ⇒直接继承 直接继承的自反-传递闭包（例如，直接和间接继承）被称作简单继承 直观的说，如果甲角色的所有权限都是乙角色的权限，并且所有乙角色的用户也都是甲角色的用户，那么就说乙角色继承甲角色
35
角色层次中，继承具有高级角色可执行低级角色权限的特点，所以，可使角色-权限指派工作最小化
层次角色帮助我们利用现有角色定义新角色，并且可以使权限指派更加可视化和逻辑化，避免角色权限和成员关系的冗余 层次角色使角色-权限指派工作效率提高 角色层次中，继承具有高级角色可执行低级角色权限的特点，所以，可使角色-权限指派工作最小化
36
连接体角色 直观的说，在层次角色中使用连接体角色可以方便的定义由高层角色继承的权限集 形式化定义：定义所有角色的集合为ROLE，直接继承关系用→来表示。（Role，→）是有向非循环图，其节点代表角色，弧代表关系q→r。 通常，用弧的方向来表示由顶向下的方向。这样，当且仅当q→r，我们就称q是r的直接上级（祖先），r是q的直接下级（后代）
37
从偏序关系的角度，定义一个由继承关系“→”连接的授权链
在图中，有如下定义：当且仅当存在rx到ry的直接路径（依据箭头指向）时，rx≥ry。而且，因为偏序关系是反对称和可传递的，所以在图中不存在（有向的）环 现在可以形式化的定义一般意义的角色层次 当没有层次角色时，每个角色都会被完全压缩，成为一个单独的权限集合——所有低级别权限的抽象集
38
定义 4.1：常规分层角色： ►RH属于ROLES × ROLES，是 ROLES 上的偏序关系，称为继承关系，写做≥，仅当所有的r2的权限也是r1的权限，且所有r1的用户也是r2的用户时，才有r1≥r2 形式化描述：r1≥r2推出 authorized_permissions(r2) ∊authorized_permissions(r1)∧ authorized_users(r1) ∊authorized_users(r2) ►authorized_users(r: ROLES)→2USERS，角色层次中从角色 r 到用户集上的映射 定义为authorized_users(r)= {u∊USERS | r′≥r, ∧(u,r′) ∊UA} ►authorized_permissions(r: ROLES)→2PRMS，角色层次中从角色 r 到权限集上的映射 定义为 authorized_permissions(r) = {p∊PRMS | r≥r′, (p,r′) ∊PA}
40
除了增加结构和为权限编组提供便利外，在层次角色中，连接器角色还可以用于有限权限继承
如果在角色中有80%或更多的权限重叠，那么该机构就可以选择创建一个连接器角色，作为表达和管理权限并解决功能重叠的一种方法 角色可以被想象成一种抽象的功能和权限集合，角色层次中连接器角色还可以使角色权限的指派更加可视化
41
任给角色r,r1,r2，当r1≥r∧ r2≥r∧ authorized_permissions(r)
组织图层次 形式化定义：连接器角色定义了两个角色之间的关系，是一种有关权限共享的形式，不同角色之间的权限，其交集是非空的，但任一权限集都不是其它权限集的子集。如果存在某个角色，其授权权限是这一交集的部分或全部，那么就称此角色是连接器角色 连接器角色定义 ： 任给角色r,r1,r2，当r1≥r∧ r2≥r∧ authorized_permissions(r) (authorized_permissions(r1)∩ authorized_permissions(r2)) 时，r是r1和r2的连接器角色，其中，r1≠r且r2≠r
42
组织层次图示例
43
例如，组织层次图示例中，首席运营官这一角色并不能执行企业的所有职能，也不能访问企业的所有资源
很明显，组织层次图本身并不是用来定义行政部门中完整的职位集或角色集的，也不是用来描述行政部门内或相互之间的继承关系的 例如，组织层次图示例中，首席运营官这一角色并不能执行企业的所有职能，也不能访问企业的所有资源 但是，可以使用行政部门来定义角色和描述职能集及用户集，同时也是制定企业权限分配和管理策略的框架
44
例如，行政部门通常为服务器、数据库和设备等资源设定所有权。企业中的大部分用户都属于或本身就是某个特定行政部门的客户，而且其对资源的访问权限也需由资源所有者指派。行政部门的日常操作是本地管理员的家常便饭，这是实现精确访问控制的法宝
45
此外，还可以用行政部门结构帮助定义业务流程和工作流。例如，由某行政部门申请的旅行支票可能需要由商务部门的领导批准。某个2500美元以下的申购项目可能只要部门经理批准就行，而高于2500美元的则需要上一级领导的批准 行政部门可以被看成用户、角色和资源的容器。这样，就可以在行政部门的环境中定义特定的角色或角色类型
46
心脏病科可以包括许多具有心脏病专业经验的人员，如内科医生、心脏病专家以及各种类型的护士。当在心脏病科中创建这些功能性角色时，他们就能访问该部门所拥有的资源
他们的访问权限都是通过角色的权能和职责进行控制和管理的。例如，某位护士（NP）可进行诊断和开具处方；在心脏病科工作的护士可能有额外的权利访问病历，并且可以向病人的治疗记录中添加诊治记录
47
系统管理员也可以创建特定类型的安全管理角色
比如，创建某个安全管理角色，并使其可为用户指派心脏病科中的角色集。应用程序系统管理员可为心脏病科的角色赋予权限，并有选择的为其指定其职责范围内的权利
48
地理区域 许多企业都会根据地理区划进行组织和管理。要求他们遵守一些特殊规定的同时，许多时候会让它们独立地履行区域性职能，例如，生产制造、业务咨询、质量保证、市场销售以及利润收益等，必须将区域运营情况向企业总部报告。绝大部分情况下，区域运营会从全局战略中受益，如全局科研、开发或产品市场等。从资源访问的角度，区域运营对角色层次结构的影响很大
49
还是来看医院的例子，这家医院除了在市区医院提供核心医疗服务外，还在两个区域诊所提供儿科和化疗服务。当需要维护牵涉病人诊治、应收账款和现金收入等本地记录时，每个诊所都要访问医院病人的病历
下图说明了提供儿科和化疗服务的诊所的角色情况
51
角色类型解释 对于很多分布式企业，每个地点或行政部门都可能有同样角色的雇员，但是每个雇员访问的资源只与其所在地的那部分有关 比如银行各个分支机构的出纳员、主管或跨银行分支的财务顾问或跨部门的秘书。对于这些角色，存在一些与特定位置有关的办公室人员可以访问的文件服务器、打印机或客户数据。如果有某个普通角色（通常是跨地域的）与特定地点有关，那这就是所谓的角色类型
52
为了避免出纳员获得分散的、与任务无关的角色权限，一种情况是，可以为角色加上修饰词
常见的修饰词就是地名、分支机构、行政部门或区域名称，冠以这样的名称的角色须完成指定的功能 这一机制提供了一种依据用户特征而指派给角色的许可权限的定制方法，仅用于某些角色权限的指派（因为可能存在指派给指定类型所有角色的企业级权限-通用权限）
53
图4.9给出了三种类型的信贷员角色-东北、东南和西
根据区域修饰词，每种角色类型被唯一地指派了相应的权限。Tom和John被指派到东区信贷员角色，获得其成员资格，具有读取东北区账务和执行东北事务 A、B 和 C 的权限 所有用户指派到信贷职员角色的，无论其角色类型，都有对国债账务进行写操作的权限。当为角色类型指派权限时，只需要指派对角色类型（由修饰词定义）来说是唯一的那些权限。对所有角色类型通用的那些权限直接指派给普通角色好了
54
角色类型的概念可以由图4.9的角色修饰词来实现，但实际上，一个角色类型是角色层次的一种简单形式
55
图4.10是一个等价于图4.9的角色层次。对国债账务进行写操作的权限属于一般性权限，可以指派给国债信贷员角色，读东北区账务和执行东北事务 A、B 和 C 的权限属于东北信贷员的职责范围。将Tom和John指派给东北信贷员角色可实现与图4.9同样的访问控制策略
57
普通角色层次允许一个角色拥有多个直接祖先（可从多种资源中继承用户成员资格），同时拥有一个或多个直接后代（可从多种资源中继承权限）
普通和受限层次角色 在实际使用中，角色层次有两种，一种为普通角色层次，另一种为受限角色层次。普通角色层次支持任意的偏序关系，作为一种包含权限多重继承和角色中用户成员资格的概念的角色层次 普通角色层次允许一个角色拥有多个直接祖先（可从多种资源中继承用户成员资格），同时拥有一个或多个直接后代（可从多种资源中继承权限） 受限角色层次则受到一些限制，结果为一棵简单的树结构（例如，一个角色可以拥有一个或多个直接祖先，但只能有一个直接后代，反之亦然）
58
现在，为普通角色层次中的直接后代添加限制，以定义受限角色层次
形式化定义：如果 r1≥r2，且r1和r2之间没有角色。即在角色层次中不存在角色r3使得r1≥r3≥ r2，其中r1≠ r2且r2≠ r3，称r1是r2的直接祖先，记为：r1→r2 现在，为普通角色层次中的直接后代添加限制，以定义受限角色层次 受限角色层次： 在定义4.1上添加如下限制：任给r,r1,r2∊ROLES，r≥r1∧ r≥r2推出r1 = r2
59
定义 4.1：普通角色层次： ►RH属于ROLES × ROLES，是 ROLES 上的偏序关系，称为继承关系，写做≥，仅当所有的r2的权限也是r1的权限，且所有r1的用户也是r2的用户时，才有r1≥r2 形式化描述：r1≥r2推出 authorized_permissions(r2) ∊authorized_permissions(r1)∧ authorized_users(r1) ∊authorized_users(r2) ►authorized_users(r: ROLES)→2USERS，角色层次中从角色 r 到用户集上的映射 定义为authorized_users(r)= {u∊USERS | r′≥r, ∧(u,r′) ∊UA} ►authorized_permissions(r: ROLES)→2PRMS，角色层次中从角色 r 到权限集上的映射 定义为 authorized_permissions(r) = {p∊PRMS | r≥r′, (p,r′) ∊PA}
60
受限角色层次中的角色被限制为只能拥有单一的直接后代。虽然受限角色层次不支持多重继承，但管理方面，明显普通角色结构更有优势
到目前为止，受限角色层次的实现仍然是大多数流行的商业授权管理产品遵循的规范，虽然普通角色层次提供了极大的灵活性，可以定义出复杂的对多用户企业常见的角色结构
61
传统上，商业产品总是落后于科研成果。因为创建一个安全模型或写一篇论文要比实现和销售某项新特性产品要容易得多。同样如前面所暗示的，当前授权管理的形式并不乐观，因为任何技术进步都必须先在市场上获得成功，之后才会受欢迎。最终，树形结构成了可视化和管理系统资源的工业标准。无以计数的用户开始对使用树形结构管理目录、文件和域习以为常，甚至，最近发布的目录存储结构也被组织成树形结构
62
普通角色层次的例子 图4.11 带有组织和功能性角色的普通层次
63
图4.11将组织和功能性角色组合成一个角色继承图。普通角色层次支持多重继承的概念，允许从两个或多个角色中继承权限及用户成员资格。定义那些以组织和商业结构为其特征的角色和关系时，多重继承允许将多个下级角色（较少权限）组成一个角色 首席心脏病医生McCarthy被指派到心脏病医生角色，并因此获得了心脏病医生的权限
64
定义4.1也授予了McCarthy医生任何心脏病医生角色所继承的权限
图4.11所描绘的图给出了一个普通角色层次，图中的任何节点都可以从多个角色源中继承许可权限。这样，心脏病医生角色就可以同时从专科医生角色和心脏病科继承许可权限，并由传递性，内科医生和药房角色的权限也被继承 像这样，心脏病医生的角色既不是功能性角色，也不是组织性角色，而是一个混合性角色
65
图4.11 带有组织和功能性角色的普通层次
66
类似的，心脏病医生NP是一个混合性角色，心脏病护理专家也是。心脏病医生角色是一个联合器角色，因为它将其所继承的角色的授权许可组合到一起了。
形式化定义：联合器角色定义了一种关系形式，在这种关系中，角色从分离的直接后代中继承权限，将其授权权限组合成一个单一的高层角色（可以是联合器角色又可以是连接器角色） 定义 4.4：联合器角色： 任给角色r,r1,r2，r是r1和r2的联合器，如果r1≤r∧r2 ≤r∧authorized_permissions(r) ⊇ (authorized_permissions(r1) U authorized_permissions(r2))时，其中r1≠r且r2≠r
67
多重继承另外一个有意思的特点是它可以在角色层次中，通过统一的用户/角色指派和直接角色继承关系，表示出用户和它们的角色指派
由于角色指派，用户接受了被指派的许可，或角色继承的权限，或通过该角色继承的角色的用户成员资格 在普通层次中，所有用户角色指派可由单个用户实例完成 图4.11中McCarthy医生角色的指派由两个直接继承关系完成。从角色图中删除McCarthy医生，会删除RBAC（基于角色的访问控制）所管理的所有McCarthy医生的许可权限
68
普通层次也允许用一个面向对象的方法管理一个企业的许可权限分配
70
ARBAC97模型——基于角色的角色管理模型
包括三个部分： URA97 用户－角色管理 PRA97 权限－角色管理 RRA97 角色－层次管理 ARBAC99模型 IRBAC2000模型-基于角色转换的域间互操作模型 A-IRBAC2000模型-对IRBAC2000进行扩展，利用RBAC来管理域间角色转换 DRBAC－动态结盟环境下的分布式RBAC模型
Similar presentations
