GB/T 25062-2010 信息安全技术 鉴别与授权 基于角色的访问控制模型与管理规范

ICS35.040

L80

中华人民共和国国家标准

GB/T25062—2010

信息安全技术鉴别与授权

基于角色的访问控制模型与管理规范

Informationsecuritytechnology—Authenticationandauthorization—

Role-basedaccesscontrolmodelandmanagementspecification

2010-09-02发布2011-02-01实施

GB/T25062—2010

目次

前言in

引言N

1范围1

2规范性引用文件1

3术语和定义1

4缩略语2

5一致性2

6RBAC参考模型2

6.1概述2

6.2核心RBAC3

6.3层次RBAC4

6.4带约束的RBAC5

7RBAC系统和管理功能规范6

7.1概述6

7.2核心RBAC7

7.3层次RBAC11

7.4静态职责分离关系14

7.5动态职责分离18

附录A（资料性附录）功能规范概述23

A.1概述23

A.2核心RBAC的功能规范23

A.3层次RBAC功能规范24

A.4静态职责分离关系功能规范24

A.5动态职责分离关系功能规范25

A.6功能规范包26

附录B（资料性附录）组件原理27

B.1概述27

B.2核心RBAC27

B.3层次RBAC27

B.4静态职责分离关系27

B.5动态职责分离28

附录C（资料性附录）Z语言示例29

T

GB/T25062—2010

—1—

刖5

本标准的附录A、附录B和附录C为资料性附录。

本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口。

本标准起草单位：中国科学院软件研究所，信息安全共性技术国家工程研究中心。

本标准主要起草人：冯登国、徐震、翟征德、张敏、张凡、黄亮、庄湧。

m

GB/T25062—2010

引言

主流IT产品供应商开始在他们的数据库管理系统、安全管理系统、网络操作系统等产品中大量实

现基于角色的访问控制功能，然而却没有对其特征集达成一致。缺乏广为接受的模型，导致了对基于角

色的访问控制效用和含义理解的不规范性和不确定性。本标准参照ANSIINCITS359-2004,使用一个

参考模型来定义基于角色的访问控制的特征，并描述这些特征的功能规范，通过以上方法来解决这些不

规范与不确定的问题。

IV

GB/T25062—2010

信息安全技术鉴别与授权

基于角色的访问控制模型与管理规范

1范围

本标准规定了基于角色的访问控制(RBAC)模型、RBAC系统和管理功能规范。

本标准适用于信息系统中RBAC子系统的设计和实现，相关系统的测试和产品采购亦可参照使用。

2规范性引用文件

下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有

的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究

是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。

ISO/IEC13568,2002信息技术Z形式规范注释语法、形式系统和语义学

3术语和定义

下列术语和定义适用于本标准。

3.1

组件component

这里是指四个RBAC特征集之一：核心RBAC、层次RBAC、静态职责分离关系、动态职责分离

关系。

3.2

对象object

需要进行访问控制的系统资源，例如文件、打印机、终端、数据库记录等。

3.3

操作operation

一个程序的可执行映像，当被调用时为用户执行某些功能。

3.4

权限permission

对受RBAC保护的一个或多个对象执行某个操作的许可。

3.5

角色role

组织语境中的一个工作职能，被授予角色的用户将具有相应的权威和责任。

3.6

用户user

人、机器、网络、自主智能代理等,进行资源或服务访问的实施主体。

3.7

会话session

从用户到其激活的角色集合的一个映射。

3.8

职责分离separationofduty

限制用户获得存在利益冲突的权限集的约束，例如用户不能同时获得会计和审计的权限。

1

GB/T25062—2010

4缩略语

下列缩略语适用于本标准:

RBAC基于角色的访问控制(RoleBasedAccessControl)

SSD静态职责分离(StaticSeparationofDuty)

DSD动态职责分离(DynamicSeparationofDuty)

USERS用户集(UserSet)

ROLES角色集(RoleSet)

OBJS对象集(ObjectSet)

OPS操作集(OperationSet)

SESSIONS会话集(SessionSet)

PRMS权限集(PrivilegeManagementSet)

ACL访问控制列表(AccessControlList)

5—致性

对于特定的应用，并非所有的RBAC特征都是必要的。因此，本标准提供了一种通过对功能组件

和同一功能组件内的特征进行选择，以组装构成所需要的RBAC特征的方法。本标准首先定义了一个

RBAC的特征核心集合，任何其他的特征包都必须包含这一核心特征集。在构建RBAC特征包时，角

色层次，静态约束（静态职责分离），动态约束（动态职责分离）是可选组件。

6RBAC参考模型

6.1概述

RBAC参考模型通过四个RBAC模型组件来进行定义——核心RBAC,角色层次RBAC、静态职

责分离关系、动态职责分离关系。

核心RBAC定义了能够完整地实现一个RBAC系统所必需的元素、元素集和关系的最小集合，其

中包括最基本的用户/角色分配和权限/角色分配关系。此外，它还引入了角色激活的概念作为计算机

系统中用户会话的一个组成部分。核心RBAC对于任何RBAC系统而言都是必需的，其他RBAC组

件彼此相互独立并且可以被独立地实现。

角色层次RBAC组件支持角色层次。角色层次从数学上讲是一个定义角色之间级别关系的偏序，

高级别的角色获得低级别角色的权限，低级别角色获得高级别角色的用户成员。此外，层次RBAC还

引入了角色的授权用户和授权权限的概念。

静态职责分离针对用户/角色分配定义了角色间的互斥关系。由于可能与角色继承产生不一致，静

态职责分离关系组件在没有角色层次和存在角色层次的情况下分别进行了定义。

动态职责分离关系针对用户会话中可以激活的角色定义了互斥关系。

每个模型组件都由下列子组件来定义：

a）一些基本元素集；

b）一些基于上述基本元素集的RBAC关系；

c）一些映射函数，在给定来自某个元素集的实例元素的情况下能够得到另一个元素集的某些实

例元素。

RBAC参考模型给出了一种RBAC特征的分类，可以基于这些分类的特征构建一系列RBAC特征

包。本标准的主要目的不是试图定义RBAC特征的全集，而是致力于提供一组标准的术语来定义已有

的模型和商业产品中最主要的RBAC特征。

2

GB/T25062—2010

6.2核心RBAC

核心RBAC的元素集和关系在图1中进行了定义。核心RBAC包含了5个基本的数据元素：用户

集(USERS)、角色集(ROLES)、对象集(OBJS)、操作集(OPS),权限集(PRMS)0权限被分配给角色，

角色被分配给用户，这是RBAC的基本思想°角色命名了用户和权限之间的多对多的关系。此外，核

心RBAC中还包含了用户会话集,会话是从用户到该用户的角色集的某个激活角色子集的映射。

角色是组织上下文中的一个工作职能，被授予了角色的用户将具有相应的权威和责任。权限是对

某个或某些受RBAC保护的对象执行操作的许可。操作是一个程序的可执行映像，被调用时能为用户

执行某些功能。操作和对象的类型依赖于具体系统，例如在一个文件系统中，操作可以包含读、写、执

行；在数据库管理系统中，操作包含select、insert、delete、update等。

访问控制机制的核心功能是保护系统资源。与以前的访问控制模型一致，RBAC模型中的对象是

包含或接收信息的实体。对一个实现RBAC的系统，对象可以代表信息容器(如操作系统中的文件和

目录或数据库中的表、视图、字段)，或者诸如打印机、磁盘空间、CPU周期等可耗尽的系统资源。

RBAC覆盖的对象包括所有在分配给角色的权限中出现的对象。

RBAC中一个很重要的概念是角色的相关分配关系。图1中给岀了用户分配关系(UA)和权限分

配关系(PA)0图中的箭头表示关系是多对多的(例如，一个用户可以被分配给多个角色并且一个角色

可以被分配给多个用户)。这种安排带来了给角色分配权限和给角色分配用户时的灵活性和细粒度。

如果没有这些，就有可能造成给用户分配过多的对资源的访问权限；能够更灵活地控制对资源的访问权

限也有助于最小特权原则的实施。

图1核心RBAC

用户在建立一个会话的时候可以激活他/她所被分配的角色的某个子集。一个会话只能与一个用

户关联，一个用户可能同时拥有多个会话。函数session_roles返回一个会话激活的角色，函数session_

user给出会话的用户。在用户的会话中保持激活状态的角色的权限构成了用户的可用权限。以下为

核心RBAC规范：

a)USERS,ROLES,OPS,OBJS分别代表:用户集、角色集、操作集、对象集；

b)UAcUSERSXROLES，一个多对多的映射，代表用户/角色分配关系；

c)assigned_user$(r：ROLES)f2L，SER'S,一个映射，给出分配了角色r的用户，assigned_users(r)—

{"6USERS|(",r)EUA}；

d)PRMSc,权限集；

e)PAcPERMSXROLES，一个多对多的映射，代表权限/角色分配关系；

f)assigned_^ermissions(r：RC)LES)f，一个映射，给出分配给角色r的权限,

assigned_f)ermissi(ms(r)—IpGPRMS\(p,r)GFA};

g)"s(":PRMS)〜{砂UOPS},权限到操作的映射，给出与权限"关联的操作；

h)obsCpzPRMS){<>/,cOBS},权限到对象的映射，给出与权限”关联的对象；

i)SESSIONS，会话集；

j)session_user(s:SESSIONS)fUSERS,一个从会话5到对应用户的映射；

3

GB/T25062—2010

k)sessiones(s:SESSIONS)f2""花、，一.个从会话s到其激活的角色集的映射，session_mles(s)

U〈厂GROLES|(^essi(m_users(.s),;■)€UA｝；

l)avail_session_perms(s:SESSONS)—*-2rK'/s,一个从会话$到它拥有的权限集的映射，

auail_sessio?i_/)erms(.s)=|Jre»-.«TOn_TOI>s<s)ed_!)er)nission(r)0

6.3层次RBAC

6.3.1导引

如图2所示，层次RBAC引入了角色层次。角色层次通常被作为RBAC模型的重要部分，并且经

常在RBAC商业产品中得以实现。角色层次可以有效地反映组织内权威和责任的结构。

角色层次定义了角色间的继承关系。继承通常是从权限的角度来说的，例如，如果角色门“继承”

角色七，角色厂2的所有权限都同时为角色门所拥有。在某些分布式RBAC实现中，角色层次是集中管

理的，而权限/角色分配却是非集中管理的。对这些系统，角色层次的管理主要是从用户成员包含关系

的角度进行的：如果角色□的所有用户都隐含地成为角色『2的用户，则称角色八“包含”角色/"2。这种

用户成员包含关系隐含了这样一个事实：角色心的用户将拥有角色厂2的所有权限。然而角色门和角色

七之间的权限继承关系并不对它们的用户分配做任何假设。

本标准认可两种类型的角色层次一通用角色层次和受限角色层次。通用角色层次支持任意偏序关

系，从而支持角色之间的权限和用户成员的多重继承。受限角色层次通过施加限制来得到一个简单的

树结构(即：一个角色可以拥有一个或多个直接祖先,但只能有一个直接后代)。

6.3.2通用角色层次

通用角色层次的规范在核心RBAC的基础上扩展如下内容：

a)RHPROLESXROLES是一个称为继承的角色之间的偏序关系，记作土。如果门二七，则角

色门拥有角色厂2的所有权限并且角色门的用户都将是角色代的用户；

b)authorized_users(r:ROLES)〜2,;'SERS，一个在角色层次存在的情况下从角色到该角色的授

权用户的映射，authorizedusers(r)=｛uGUSERS\r>：rA(")GUA｝；

c)authorized_^ermissitms(r:ROLES)2PRMS，一个在角色层次存在的情况下从角色到其授权

权限的映射>authorizedpermissions=｛pGPRMS\rrA(”，厂‘)€PA｝。

侧色k次

图2层次RBAC

通用角色层次支持多重继承的概念，从而使得一个角色可以从两个或者更多其他角色继承权限或

用户成员。多重继承具有两个重要的性质。第一，多重继承使得可以通过从几个低级别的角色来构建

较高级别角色的方式来定义角色间的关系以反映组织和事务的结构。第二，多重继承使得可以一致地

对待用户/角色分配关系和角色/角色继承关系。用户也可以被包含在角色层次中，并且仍然用土来代

表用户/角色分配以及用户对角色权限的继承。

在受限角色层次中，一个角色只能有一个直接后代。尽管受限角色层次不支持权限的多重继承，但

与层次RBAC比较却具有管理上的优势。

4

GB/T25062—2010

如果r,>r2并且这两个角色之间不存在其他的角色（即不存在不同于角色心和角色厂2的角色心，满

足心>r3>r2），则门是r2的直接祖先，记作n>>r2。

6.3.3受限角色层次

受到下述限制的通用角色层次：Vr,r,,r2GROLES,r>>nA厂0

角色层次可以用偏序图来表示。图中的节点代表角色，如果□是心的直接后代，则存在从厂指向

飞的有向箭头。在角色层次的偏序图上,rx>ry当且仅当存在从心到心的有向路径。由于角色之间的

偏序关系是传递和反对称的，所以不存在有向回路。通常，角色层次图上的箭头与角色间的继承关系相

一致都是自上而下的，因此角色用户成员的继承是自上而下的，而角色权限的继承是自下而上的。

6.4带约束的RBAC

6.4.1概述

带约束的RBAC模型增加了职责分离关系。职责分离关系可以被用来实施利益冲突（ConflictOf

Interest）策略（防止某个人或某些人同时对于不同的某些个人、某些集团或组织以及某种事物在忠诚度

和利害关系上发生矛盾的策略）以防止组织中用户的越权行为。

作为一项安全原则，职责分离在工商业界和政府部门得到了广泛的应用，其目的是保证安全威胁只

有通过多个用户之间的串通勾结才能实现。具有不同技能和利益的工作人员分别被分配一项事务中不

同的任务，以保证欺诈行为和重大错误只有通过多个用户的勾结才可能发生。本标准支持静态和动态

的职责分离。

6.4.2静态职责分离关系

在RBAC系统中，一个用户获得了相互冲突的角色的权限就会引起利益冲突。阻止这种利益冲突

的一个方法是静态职责分离，即对用户/角色分配施加约束。

本标准中定义的静态约束主要是作用于角色，特别是用户/角色分配关系，也就是说,如果用户被分

配了一个角色，他/她将不能被分配另一些特定的角色。从策略的角度，静态约束关系提供了一种有效

的在RBAC元素集上实施职责分离和其他分离规则的有效手段。静态约束通常要限制那些可能会破

坏高层职责分离策略的管理操作。

以往的RBAC模型通常通过限制一对角色上的用户分配来定义静态职责分离（一个用户不能同时

分配处于SSD关系下的两个角色）。尽管现实世界中确实存在这样的例子，这样定义的SSD在两个方

面限制性太强：SSD关系中角色集的成员数（只能为2）和角色集中角色的可能组合情况（每个用户最多

只能分配角色集中的一个角色）。在本标准中，静态职责分离通过两个参数定义：一个包含两个或更多

角色的角色集和一个大于1的阈值（用户拥有的角色中包含在该角色集中角色的数量小于这个阈值）。

例如，一个组织可能要求任何一个用户不能被分配代表采购职能的4个角色中的3个。

正如图3所示，静态职责分离可能存在于层次RBAC中。在存在角色层次的情况下，必须注意不要让

用户成员的继承违反静态职责分离策略。为此，层次RBAC也被定义为继承静态职责分离约束。在角色

层次RBAC中，为了解决可能出现的不一致性，静态职责分离被定义为针对角色的授权用户的约束。

图3层次RBAC下的静态职责分离

5

GB/T25062—2010

静态职责分离和层次RBAC下的静态职责分离分别定义如下：

a)静态职责分离

SSDU(2R()LESXN)由一组形如(r$,〃)的对构成，其中是角色的集合，/是的子集,«>2,

满足任何用户都不能同时被分配r中的"个或者更多角色，VS,")GSSD,V/U“丨/

|>?z=>fl(r)—0o

b)层次RBAC下的静态职责分离

在存在角色层次的情况下，静态职责分离基于角色的授权用户而不是直接分配了该角色的用

户进行重新定义'V(rs,n)GSSD,V/Cr.s：IZ|>authorized_users(r)=0。

6.4.3动态职责分离关系

静态职责分离关系和动态职责分离(DSD)关系的目的都是限制用户的可用权限，不过它们施加约

束的上下文不同。SSD定义并且施加约束到用户总的权限空间上，而DSD通过约束一个用户会话可以

激活的角色来限制用户的可用权限。DSD使用户可用以在不同的时问拥有不同的权限，从而进步扩

展了对最小特权原则的支持。DSD能够保证权限的有效期不超过完成某项职责所需要的时间段，这通

常被称为信任的及时撤销。在没有DSD的情况下，动态的权限撤销是非常困难的，因此通常被忽略。

SSD解决在给用户分配角色的时候可能存在的利益冲突问题。DSD允许用户同时拥有两个或者

更多这样的角色：这些角色在各自独立地被激活时不会产生安全威胁，而同时被激活时就可能会产生违

反安全策略的行为。

动态职责分离被定义为针对用户会话激活的角色的约束，如图4所示。

图4动态职责分离关系

DSDU2R()LESXN由一组形如(心,”)的对构成，其中r.s-是角色的集合，"二2,满足没有任何主体

能激活rs中的"个或更多角色。

Vr.s-e2R(),ES，"&N,(rs,")cDSDn>2AIr.sI>72AV.seSESSIONS,Vrs62R(),ES,

Vrole_subsetG2M)LES,VnGN,(rs,?i)GDSD,role_suhsetCrs,role_subsetU

session_roles(s)今|role_sul)set\<?i

7RBAC系统和管理功能规范

7.1概述

RBAC功能规范描述了创建和维护RBAC元素集和RBAC关系的管理操作；进行管理查询的管理

查看函数;创建和维护用户会话的RBAC属性和进行访问控制决策的系统函数。本标准对这些函数进

行了足够细致的定义，以便支持一致性测试和保证的需要，同时给开发者提供了足够的设计灵活性以满

足用户的需求。

RBAC功能规范使用的Z标记方法由ISO/IEC13568:2002定义。唯一的例外是模式表示如下：

模式名(声明)<1谓词；……；谓词［>。

这里使用的大多数抽象数据类型和函数都来自RBAC参考模型，但在必要的时候，将会引入新的

6

GB/T25062—2010

抽象数据类型和函数。为了描述方便，这里首先需要引入符号NAM。NAM是个元素为实体标识

的抽象数据类型，这些实体可能包含在RBAC系统之中或者之外(角色、用户、会话等)。

7.2核心RBAC

7.2.1核心RBAC管理函数

本条定义了核心RBAC的管理函数。

a)AddUser

该命令创建一个新的用户。当要待创建用户尚不存在于USERS集合中时，该命令可用。命令执

行后,USERS被更新，新创建的用户不拥有任何的会话。下面的模式形式化地描述了AddUser：

AddUser(user:NAME)<]

user幺USERS

USERS'—USERSU〈user}

b)DeleteUser

该命令从RBAC数据库中删除一个已经存在的用户。该命令可用当且仅当被删除的用户是

USERS数据集的一个成员。USERS数据集、UA数据集和assigned_users函数被更新。如果一个正

处在会话中的用户被删除,如何处理该用户的会话依赖于具体实现。实际RBAC系统可以等待该会话

结束或者强行终止它。下面的模式形式化地描述了DeleteUser：

DeleteUser(user:NAME)<]

userGUSERS

[V5GSESSI(_)NS•user—sessiofi_user(.s)DeleteSession(5)]

UAf^UA\{r-ROLES・user

assigned_users'—{r：ROLES•r^{assigned_users(r)\{«.ser})}

USERS'=USERS\{user>>

c)AddRole

该命令创建一个新的角色。该命令可用当且仅当要创建的角色尚且不存在于ROLES数据集。

ROLES数据集、assigned_users和assigned_permisssions函数被更新。初始时，新创建的角色没有分

配任何用户和权限。下面的模式形式化地描述了AddRole：

AddRole{role:NAME)<

roleGROLES

ROLES'=ROLESU{role}

assigned_users'—assieel_usersU{role10}

assigned_permissio?is'—assifr?ied_/)ermissionsU{role10}[>

d)DeletcRole

该命令从RBAC数据库中删除一个角色。该命令可用当且仅当被删除的角色是ROLES数据集的

成员。如果被删除的角色在某些会话中尚且是激活的，如何处理这些话是一个具体实现需要决定的问

题。实际RBAC系统可以等待这样的会话结束或强行终止它们或从会话中删除这个角色然后允许会

话继续执行。下面的模式形式化地描述了DeletcRole：

DeleteRole(role:NAME)<]

roleGROLES

[VsGSESSIONS•roleGsession_roles(s)^DeleteSessio?i(.s)]

UA'=UA\{u:USERS・u}

assigned_users'—assigned_users\{rolei-^zssigned_users(role)}

PA'=PA\{op:OPS,obj:OBJS•(.op,obj)i—}

assigned_permissi(ms'=assigned_permissions\{rolessig?ied_permissi(nis(role)}

ROLES'=RC)LES\{role}>

7

GB/T25062—2010

e)AssignUser

该命令给用户分配角色。该命令可用当且仅当该用户是USERS数据集的成员，该角色是ROLES

数据集的成员，并且该角色尚未分配给该用户。数据集UA和函数assigned_users被更新。下面模式

形式化地描述了该命令：

AssignUser{user，role:NAME)0

userGUSERS;roleGROLES;(user\-^>roIe)gUA

UA^=UAU(user\-^role}

assig?ied_usersr=assigned_users\{roleed_users(role)}|J

{role^{assigned_usersQrole}|J{user})}[>

f)DeassignUser

该命令删除一个角色role到用户user的分配。该命令可用当且仅当user是USERS数据集的成

员9role是ROLES数据集的成员，并且角色role已经分配给了用户user。

如果user正拥有某些会话并且role在这些会话中是激活的，如何处理这样的会话是一个具体实现

需要决定的问题。实际RBAC系统可以等待这样一个会话结束，或者强行终止它，或者取消激活该角

色。下面模式形式化地描述了该命令：

Deassi^nUser(userrole:NAME)0

userGUSERS；roleGROLES；(useri-ole)GUA

[_Vs：SESSIONS•user=sessicm_user(s)AmleGsessio?i_roles(s)^DeleleSessio?2(5)]

UAr=UA\{user\-^role}

assignecl_usersf=assigned_users\{role_users{roles}}U

{roleed_users{role)\{user})}0

g)GrantPermission

该命令给一个角色分配对一个对象执行某个操作的权限c该命令可用当日•仅当给定的(操作9对

象)代表了一项权限并且该角色是ROLES数据集的成员。在实际实现中，该命令可能实现为授予对应

于该角色的组以相应的权限，即修改对象的ACL。下面的模式形式化地定义了该命令：

GrantPermissi(m{object^operatum9role:NAME)0

^operation9ohject)PERMS；role€ROLES

PAf=PA|J{{operation?object)\-^role}

assigned_permissions^=assigned_permissions\{rolel-^zed_f)ermissions(roles)}U

{roleg?ied_per/nissions(role)U{^operation^object}})}[>

h)RevokePermission

该命令从分配给角色的权限集中撤销对某个对象执行某个操作的权限。该命令可用当且仅当(操

作,对象)代表一项权限，并且该权限已经分配给了该角色。在实际的实现中，该命令可能实现为撤销对

应于该角色的组的权限，即修改对象的ACL。

下面的模式形式化地描述了该命令：

RevokePermission(^operation9object9role:NAME)<J

(^operation^objecl^GPERMS；role€ROLES;((operation^object)\->role^GPA

PAf=PA\{(operalion9object)\->role}

assigned_permissions=assigned_permissio?is\{rolessif^nedissions(roles)}U

{roleed_^ermissions(role)\{^operation^object)})}0

7.2.2核心RBAC支持系统函数

本条定义了核心RBAC的支持系统函数。

a)CreateSession

8

GB/T25062—2010

该函数创建一个新的会话，以指定的用户作为会话拥有者，以指定的角色集作为激活角色集。该函

数可用当且仅当用户user是USERS数据集的成员并且激活角色集是用户分配的角色集的子集。在实

际RBAC实现中，会话的角色集可能对应于一些组。

下面的模式形式化地描述了该函数。SeEm参数是一个由底层系统产生的用于标识会话的标

识符。

CreateSessionCuser:NAME;ars：2X；session:NAME)

userGUSERS^arsV(r：ROLES\(useri厂)GUA}；sessio?i@SESSIONS

SESSIONS'=SESSIONSUHssiw}

session_userf=session_userU(session\-^user}

session_rolesf=session_rolesUsessionK厂s}[>

b)DeleteSession

该函数删除一个会话。该函数可用当且仅当会话标识符是SESSIONS数据集的成员。下面的

式形式化地描述了该函数。

DeleteSession(sessio?i:NAME)<|

sessionGSESSIONS

sessio/i_user'=sessio?2_user\{sessio?i\-^sessio?i_user(sessio?!)}

session_rolesf=sessicm_role\{session\-^sessio?i_roles(sessio?i)}

SESSIONS'=SESSIONS\{session}>

c)AddActiveRole