GB/T 31501-2015 信息安全技术 鉴别与授权授权应用程序判定接口规范

GB/T 31501-2015 Information security technology—Authentication and authorization—Specification for authorization application programming decision interface

国家标准 中文简体 现行 页数:55页 | 格式:PDF

基本信息

标准号
GB/T 31501-2015
相关服务
标准类型
国家标准
标准状态
现行
中国标准分类号(CCS)
国际标准分类号(ICS)
发布日期
2015-05-15
实施日期
2016-01-01
发布单位/组织
中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会
归口单位
全国信息安全标准化技术委员会(SAC/TC 260)
适用范围
本标准定义了访问控制服务为授权应用提供的授权判定编程应用接口,并定义了与判定接口相关的数据结构和C语言形式的接口。本标准适用于访问控制服务中授权判定接口的设计和实现,访问控制服务的测试和产品采购亦可参照使用。

发布历史

研制信息

起草单位:
中国科学院软件研究所、北京数字证书鉴别中心有限公司、中科正阳信息安全技术有限公司
起草人:
冯登国、张立武、李晓峰、王雅哲、高志刚、徐震、段美姣、汪丹、黄亮、翟征德、詹榜华
出版信息:
页数:55页 | 字数:100 千字 | 开本: 大16开

内容描述

ICS35.040

L80OB

中华人民共和国国彖标准

GB/T31501—2015

信息安全技术鉴别与授权

授权应用程序判定接口规

Informationsecuritytechnology——Authenticationanauthorization—

Specificationforauthorizationapplicationprogrammingdecisioninterface

2015-05-15发布2016-01-01实施

GB/T31501—2015

目次

,、/•、-T

刖BI

引言n

1范围1

2规范性引用文件1

3术语和定义1

4缩略语3

5框架3

5.1访问控制框架3

5.2访问控制服务组件4

5.3访问控制信息5

6授权API使用模型10

6.1系统结构10

6.2支持的函数10

6.3状态机11

6.4信任模型13

7功能和可移植性要求15

7.1功能要求15

7.2移植性要求15

8常量和变量定义16

8.1字符串与类字符串数据16

8.2状态值17

8.3常量18

8.4授权和机制ID20

附录A(资料性附录)函数说明22

参考文献51

GB/T31501—2015

■ir■■i

刖吕

本标准按照GB/T1.1—2009给出的规则起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。

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

本标准起草单位:中国科学院软件研究所、北京数字证书鉴别中心有限公司、中科正阳信息安全技

术有限公司。

本标准主要起草人:冯登国、张立武、李晓峰、王雅哲、高志刚、徐震、段美姣、汪丹、黄亮、翟征德、

詹榜华.

T

GB/T31501—2015

引言

访问控制作为一种基本的安全措施在实际系统中得到广泛的应用,随着访问控制技术的日趋复杂,

访问控制已成为一类安全基础服务,而广泛的应用集成需求需要访问控制安全服务能够给应用程序提

供一个统一的编程接口,使得应用程序能够在不同的访问控制服务之间具有可移植性,而目前缺少这类

国家标准。为了解决这个问题,本标准参考了OpenGroup的技术标准(参考文献[叮)等相关标准和规

,在保证适应多种应用场景的情况下,定义了授权应用程序判定接口规。

本标准定义的授权应用程序判定接口规范可用于符合GB/T18794.3访问控制框架的系统中,尽

管本标准提供了允许主体控制哪些特权属性可以被用于访问控制授权请求判定中(通常被称为最小特

权),但并不提供特权属性管理。

本标准的设计目标如下:

a定义一个简单、灵活的API,安全组件提供者和需要安全保护的应用程序开发者可以通过调用

此API来实现授权功能;

b访问判定时可以应用透明地进行策略规则的评估;

c独立于应用的策略集中管理;

d透明地提供广泛的策略规则词法和语义(如访问控制列表、能力、标签、逻辑谓词等);

e将鉴別和授权分离;

f允许从鉴别数据中推导出授权属性;

g透明地支持任意合理的授权属性类型(如访问标识、组、角色等);

h易于在多层次结构的应用系统中提供授权服务;

i在多层应用配置中允许使用外部授权属性;

j应用程序可以访问应用于其资源的访问控制策略;

kAPI的实现支持多种访问控制机制;

l)单一程序可以同时使用多个鉴别和授权服务;

m支持应用程序访问与授权服务操作相关的审计数据。

本标准不涉及以下内容:

a授权策略管理;

b描述证书委托服务或语义;

c描述一个审计服务API;

d描述授权服务如何以及何时生成审计事件;

e在异构环境下,定义用来交换证书信息的PAC格式;

f支持每一种可能的授权策略规则词法和语义。

n

GB/T31501—2015

信息安全技术鉴别与授权

授权应用程序判定接口规

1范围

本标准定义了访问控制服务为授权应用提供的授权判定编程应用接口,并定义了与判定接口相关

的数据结构和C语言形式的接口。

本标准适用于访问控制服务中授权判定接口的设计和实现,访问控制服务的测试和产品采购亦可

参照使用。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文

件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。

GB/T18794.3—2003信息技术开放系统互连开放系统安全框架第3部分:访问控制框架

GB/T25069—2010信息安全技术术语

3术语和定义

GB/T25069—2010界定的以及下列术语和定义适用于本文件。

3.1

访问控制信息accesscontrolinformation

用于访问控制目的的任何信息,其中包括上下文信息。

[GB/T18794.3—2003,定义3.4.5]

3.2

访问控制判定功能accesscontroldecisionfunction

一种特定功能,它通过对访问请求、ADI(发起者的、目标的、访问请求的或以前决策保留下来的

ADI)以及该访问请求的上下文,使用访问控制策略规则而做出访问控制判定。

[GB/T18794.3—2003,定义3.4.3]

3.3

访问控制判定信息accesscontroldecisioninformation

在作出一个特定访问控制判定时可供ADF使用的部分(也可能是全部)ACIO

[GB/T18794.3—2003,定义3.4.2]

3.4

访问控制实施功能accesscontrolenforcementfunction

一种特定功能,它是每一访问请求中发起者和目标之间访问路径的一部分,并实施由ADF做出的

决策。

[GB/T18794.3—2003,定义3.4.4]

1

GB/T31501—2015

3.5

访问请求accessrequest

操作和操作数,它们构成一个试图进行的访问的基本成分。

[GB/T18794.3—2003,定义3.4.9]

3.6

属性列表attributelist

由属性名称和属性值构成的数据列表。

3.7

审计标识auditidentity

包含一个用于审计目的标识的属性。

3.8

授权机构aulhorizalionauthority

管理授权数据的实体。

3.9

能力capability

表明拥有者具有访问某项系统资源的权限的标记。

3.10

许可权clearance

能用来与目标安全标签进行比较的发起者绑定ACI。

[GB/T18794.3—2003,定义3.4.13]

3.11

凭证链credentialschain

多个凭证根据相互关系构成的具有层次的结构,

3.12

凭证句柄credentialhandle

指向凭证链的句柄。

3.13

合成凭证链combinecredentialschain

由多个凭证链构成的有序列表。列表中的第一个元素是访问请求发起者的凭证链,列表中的其他

元素是传递这个访问请求的一系列中介的凭证链。

3.14

判定decision

ADF对判定请求的响应。

3.15

判定请求decisionrequest

AEF发送给ADF的信息,此信息询问ADF“允许还是拒绝一个特定的访问请求”。

3.16

资格entitlement

包含ADI和访问控制策略规则信息的数据结构,应用程序可以使用此信息来决定其行为或者在其

代码中进行访问控制判定。

3.17

标识identity

传递到aznAPT的发起者ACI,本标准使用这个术语来描述所有发起者的信息,包括名称、身份证

2

GB/T31501—2015

书和能力。

3.18

发起者initiator

一个试图访问其他实体的实体(如人类用户或基于计算机的实体)。

:GB/T18794.3—2003,定义3.4.15]

3.19

中介intermediary

负责转发发起者的访问请求的实体。

3.20

标签label

与受保护资源绑定的标记,其标明了此资源的安全相关属性。

3.21

操作operation

发起者的访问请求中要求在受保护资源上执行的具体访问动作。

3.22

特权属性证书privilegeattributecertificate;PAC

保护特权属性的数据结构,产生此属性的权威可能对其进行签名。

3.23

特权属性privilegeattribute

与发起者相关的属性,当与受保护资源的控制属性匹配时,用来允许或拒绝访问此受保护资源。

3.24

受保护资源protecteresource

访问受访问策略限制的目标。

3.25

目标target

被试图访问的实体。

:GB/T18794.3—2003,定义3.4.23]

4缩略语

下列缩略语适用于本文件。

ACI:访问控制信息(accesscontrolinformation)

ADF:访问控制判定功能(accesscontroldecisionfunction)

ADI:访问控制判定信息(accesscontroldecisioninformation)

AEF:访问控制实施功能(accesscontrolenforcementfunction)

API:应用程序编程接口(applicationprogramminginterface)

aznAPI:授权应用程序编程接口(authorizationapplicationprogramminginterface)

ID:标识(identity)

PAC:特权属性证书(privilcgeattributecertificate)

SSL:安全套接层(securesocketslayer)

5框架

5.1访问控制框架

本标准采用的访问控制服务框架的定义见GB/T18794.3—2003o

3

GB/T31501—2015

5.2访问控制服务组件

5.2.1ADF

ADF根据ADI做出访问控制判定。ADI描述了发起者、目标、访问请求、系统和环境安全相关的

属性。ADI的详细定义见5.322。

图1描述了ADF用来进行访问控制判定的信息。

只决湧农

Sft#ADI

1.-

AD&

访何梅略

图1ADF输入

5.2.2AEF

访问控制实施功能实施ADF的访问控制判定结果。

aznAPI是一个媒介,通过此APT,AEF调用ADF来获取访问控制判定的结果。AEF使用此APT

向ADF传递ACL如图2所示,aznAPI的实现负责从AEF提供的ACT中推导出ADI,并且将此ADI

提交给ADF。ADF根据上述ADI信息,以及访问控制策略和当前上下文ADI来做出访问判定。

图2AEF使用授权API调用ADF

4

GB/T31501—2015

5.3访问控制信息

5.3.1概述

ACI是AEF可获取的与访问控制判定可能相关的信息。aznAPI的职责是:

a确定AEF提交的与访问控制判定有关的ACI信息;

b将AEF提交的ACI转化为ADF可用的ADI;

c将ADI提交给ADF。

5.3.2发起者信息

5.3.2.1发起者ACI

发起者ACI描述了访问请求发起者安全相关属性,是AEF可获取的发起者信息。

由鉴別服务生成的发起者ACI数据结构在本标准中称为标识。标识可以很简单,例如只包括发起

者的名称字符串;也可以很复杂,例如包括数字证书。

授权API可以接受能力作为标识,能力是由鉴别服务提供的直接断言,如图3所示,在能力中并不

是必须要标明发起者,无论谁拥有能力都可以使用。在图3中,发起者使用虚线来表示。能力中包括一

个策略入口列表,每个入口指定了一个目标客体,同时定义规则用来描述发起者允许执行的操作。

注:aznAPI实现不要求支持所有的标识格式,同时也不是必须要支持能力。

*保1*02

ShiftMHI.1MM2.1

图3能力

由授权服务产生的发起者ACI数据结构被称为PACO并不是只有授权服务可以产生PAC,鉴别

服务也可以产生PAC来声称用户标识。在“推模式”中,PAC是用户特权属性。(aznAPT实现中,由鉴

别服务产生的PAC被当作标识来处理,以此来区分AZN自己产生的授权数据结构oaznAPI实现也可

以将PAC数据结构作为用户凭证信息的内部表示,AEF通过aznAPI是不可见这些数据结构的,PAC

应符合5.3.&1。

5.3.2.2发起者ADI

发起者ADI是从发起者ACI中衍生出来的授权相关信息,通过aznAPI传递给ADF。aznAPI将

发起者ADI存储在称为凭证链的数据结构中。因为凭证链不会传递给aznAPT的调用者,同时不同的

授权服务可以使用不同的凭证链格式,所以凭证链数据结构格式定义不包括在此标准中。

尽管aznAPI不允许调用者直接访问凭证链,但其提供访问凭证链属性信息的接口函数。

图4显示了aznAPI如何将发起者ACI转换为凭证链,并且返回一个凭证句柄给调用者,aznAPI

可以用在将特权属性从客户端推到AEF的系统中,或者要求AEF从某个存储或服务中采用拉模式获

5

GB/T31501—2015

取特权属性的系统中。在推模式环境下,发起者ACI中包含被客户端推来的特权属性,并且被转换为

可以被aznAPI实现使用的内部数据。在拉模式环境下,ACI发起者只包含单一特权属性(如发起者被

鉴别的名称),而aznAPI实现在构建发起者凭证链时,从适当的存储或结构中获取发起者的其他特权

属性。

图4发起者ACI到凭证的转换

5.3.3目标信息

5.3.3.1概述

目标信息描述了访问请求中与目标相关的安全信息:

a目标ACI:AEF可以获取的目标信息。

b目标ADI:aznAPI转换目标ACI获得的目标信息。

5.3.3.2目标ACI

通常aznAPT需要的目标ACI数据只是目标名。

安全标签是此规则的特例。aznAPI可以支持包含安全标签的ADI的访问控制判定。在某些基于

标签的授权系统中,授权服务并不知道标签信息是如何在目标中被编码的,以及标签是如何以与目标相

关的元数据的方式存储起来的。在这些例子中,AEF需要获取目标安全标签,并将它们作为目标ACI

6

GB/T31501—2015

传递给aznAPI。授权API可以被实现为支持处理不同类型的标签。在支持多种标签的实现中,调用

者需要明确使用的标签模式ID,使得API知道在此调用中使用哪类标签。

5.3.3.3目标ADI

不同的授权服务实现可以包含不同数量的目标ADI和数据类型。目标ADI数据通常并不返回给

调用者,所以目标ADI数据格式不在此标准中定义。

由于有些授权APT调用者可能会因为其他用途使用授权策略数据,所以授权API支持将ADI数

据外部化为数据结构,此数据结构称为资格。资格应符合5.3.&2。

5.3.4请求信息

5.3.4.1概述

请求信息描述了访问请求相关的安全属性:

a请求ACI是AEF可以获取的请求信息;

b请求ADI是授权API将请求ACI转换后的请求信息。

5.3.4.2请求ACI

aznAPI要求请求ACI包含请求的操作名称。

5.3.4.3请求ADI

不同授权服务实现可以有不同类型和数量的请求ADI数据。请求ADI数据并不返回给调用者,

所以请求ADI数据格式并不在此标准中定义。

5.3.5上下文信息

5.3.5.1概述

上下文信息描述了访问请求发生上下文的安全相关属性。上下文ACI是AEF可以获取的上下文

信息。

上下文ADI有两个来源:

aaznAPI将上下文ACI转换后的结果;

b授权服务可以直接获取而并非由ACI提供的上下文信息。

5.3.5.2上下文ACI

aznAPI定义了四种上下文ACI数据,这些数据可以作为上下文信息传递给授权服务:

——时间:请求发生的时间;

——地点:请求发起的地点(源地址);

——路由:将请求从发起者传递到AEF通过的连接;

——鉴別质量:用于建立发起者身份的鉴别的质量。

上下文信息并不局限于此。aznAPI允许AEF使用非透明类型的参数传递给授权服务,使用这些

参数说明应用或授权服务相关的上下文信息。使用这些通过不透明参数传递特定上下文信息格式的授

权服务的应用可移植性低。

5.3.5.3上下文ADI

不同的授权服务的实现可以有不同数量和类型的上下文ADI数据。上下文ADI数据在aznAPI

7

GB/T31501—2015

中不返回给调用者,所以在此标准中不定义上下文ADI数据格式。

5.3.6预留信息

授权服务可以保留同一发起者请求的操作序列信息,并由此来做出访问控制判定。女口,用于ATM

中的授权服务保存了每个用户在当前所取的钱数信息,并以此来实现每天的取钱限制策略。

授权服务为此目的保留的信息是ADI,并且不会通过授权API暴露给应用程序。因此,保留的

ADI信息的格式在此标准中不涉及。

5.3.7访问控制策略信息

访问控制策略信息包括用来评估其他的ADI并且做出访问控制决策的规则。调用者并不能从授

权API中获取访问控制策略信息,不同的授权服务可以使用不同类型和数量的访问控制策略信息,所

以访问控制策略信息格式不在此标准中定义。授权服务可以以资格的形式外部化访问控制策略信息,

这部分内容在5.3.&2中描述。

5.3.8夕卜咅0化ADI

授权API对调用者有意隐藏了发起者ADI和访问控制策略信息的细节。然而,这些信息在某些情

况下对调用者是有用的,因此,授权API允许授权服务外部化发起者ADI和访问控制策略信息。

5.3.&1PACs

授权API将外部化的发起者ADI放在一个称为PAC的数据结构中,图5表明了PAC的创建

过程。

发起者ADI的外部化允许授权服务以它的角度断言发起者的安全相关特征,这与从鉴别服务角度

看到的发起者的安全相关特征是不同的。

某授权服务可以使用这个功能产生签名的属性证书,其他服务以此作为授权数据源。

因为此标准只定义了一个不透明的PAC结构,由一个授权服务产生的PAC不能保证被其他授权

服务使用。在将来的标准中会定义一个标准的PAC结构,以此为基础,授权服务之间可以传递发起者

授权属性的断言。

注:签名的PAC可以用来构建委托协议,aznAPI不能提供委托服务。一个委托协议必须允许希望成为发起者请求

委托的实体可以将以下内容传递给一个目标:被委托的请求、一个可信表示,证明最初从访问发起者处得到的

请求已经被鉴别、委托者被授权将请求以发起者的名义转发给目标的可信表示、发起者的信任表示和委托者的

凭证信息。

授权服务可以签名PAC来形成发起者的信任表示和委托者的凭证信息,甚至可以包含身份信息

(如证书发布者标识和身份证书序列号)建立起到发起者鉴别数据的一个链接,但授权服务并不在请求

中绑定PAC(以加密或其他方式)。代表发起者或作为发起者委托者身份的AEF必须使用一个独立的

加密设施或委托服务来绑定由aznAPI生成的PAC与委托请求消息。

5.3.8.2资格

授权API将外部化的访问控制策略信息存储在称为资格的数据结构中。

外部化的访问控制策略信息允许应用程序基于授权策略来定制系统的行为。例如,其允许应用程

序修改系统菜单来显示发起者可以执行的访问,而不是显示系统中所有的操作。资格信息也可以被应

用程序用来做出其自己的访问判定,而不是依赖于在授权服务中实现的ADF。

8

GB/T31501—2015

A!

L1认-11

iii

皿、匕欢他

图5凭证外部化为PAC

授权API定义了一个可移植的、每个授权服务可以支持的资格数据格式,是一个特定发起者可以

在某个特定目标上执行的操作列表。图6显示资格信息的格式示例。主体数据周围的虚线表示发起者

数据是隐含的,其并不包含在授权API返回的资格数据中。

11^1

幣11:竹惜仆列辰

图6可移植的资格示例

可移植的资格数据表示保证了在所有的授权服务中都可以被支持,但其不是非常有效的。一些授

权服务可能使用单一规则或者使用通配符来表示发起者在许多目标上的操作授权,甚至可以用一个单

一规则或表达式来描述多个发起者的授权,然而不同的授权服务使用不同的规则格式,并且不存在一个

单一规则格式可以用来有效地表示所有授权服务,基于这个原因,授权API允许授权服务以非透明类

型参数的形式返回非移植的资格信息,如图7所示,非移植资格信息可通过任意的规则方式进行描述。

9

GB/T31501—2015

4MI1

图7非移植资格示例

使用非移植资格要求调用授权API的应用程序来理解授权服务规则格式,并且防止调用授权APT

的应用程序使用有不同规则格式的授权服务。

6授权API使用模型

6.1系统结构

图8是使用授权API的系统结构。

图8授权API系统结构

在使用授权API的系统中的资源请求由AEF来仲裁。

AEF鉴别用户(通常使用鉴別服务),同时AEF也通过将访问控制信息传递给授权API来授权请

求,其完成被授权的请求并且拒绝未被授权的请求。

授权API将从AEF中发来的ACI转换成ADI,同时利用ADF做出访问判定。

ADF使用ADI和访问策略规则来判定发起者在目标上执行操作的请求是被允许还是拒绝。

6.2支持的函数

表1列出了文献口]中提供的授权API函数集,并且简单描述了每一个函数集的功能。

10

GB/T31501—2015

表1授权服务API函数

接口集命名前缀接口集支持的功能

初始化授权API的实现

azn_initialize,azn_shutdown

系统停止运行时,清除授权API的实现

创建、删除、修改和合并链

azn_creds从凭证链中获取信息

基于凭证链创建PAC

aznid基于由鉴别服务产生的鉴别标识建立鉴别链

azn_decision做出访问判定

azn_entitlement获取访问控制策略信息

azn_pac基于由授权服务产生的PAC建立凭证链

azn_error从由授权API函数返冋的状态值中获取错误信息

azn_authority由aznAPI实现支持的鉴别、授权和凭证、标签、pac发现机制

创建和删除属性/值列表

azn_attrlist将参数写入属性/值列表

从属性/值列表中渎取参数数据

azn_release释放在授权API实现中分配的数据

6.3状态机

图9概括了调用授权API应用的状态机(通常是一个AEF,AEF应该按图中的顺序调用授权

API函数。图中所描述的仅是状态机的大致情况,并没有列举出授权服务实现调用者所有可能的状态。

由于AEF通过API而不是授权API调用鉴别服务,所以图中并非每个状态都是由授权API函数调用

引起的。

图9授权API状态机概览

11

GB/T31501—2015

表2指明了可以引起状态转移的授权API函数调用和其他AEF操作。

表2授权API状态机迁移

迁移引起迁移的操作

1AEF获取已被鉴别服务鉴别的发起者的请求

2AEF获取请求,AEF鉴别发起者

3AEF获取由一个授权API实现产生的PAC所描述的发起者的请求

AEF调用azn_decision_access_allowed来授权请求(授权服务使用从环境中获取的鉴别服务标识隐含地

4

建立凭证链)

5AEF调用azn_id_get_creds,其参数中的II)为空(授权服务使用从环境中获取的鉴别标识)

6AEF调用azn_id_get_creds,其参数中的11)是在鉴别发起者时由AEF产生

7AEF调用azn_pac_get_creds

8AEF调用azn_creds_combine来给发起者添加凭证链

9AEF调用azn_creds_modify来改变凭证链的属性

10AEF调用azn_creds_modify来改变凭证链的属性

11AEF调用azn_decision_access_allowed

12AEF调用azn_creds_get_pac

13AEF调用azn_creds_get_pac

14AEF调用azn_decision_access_allowed

图9的状态机可以分为三个阶段;

a凭证建立。图9中初始状态的最左边一列的状态属于此阶段,在此阶段中,AEF使用授权

API建立凭证链,授权服务将使用此凭证链作为后续操作的基础。

b凭证修改。图9中初始状态的右边的第二列属于此阶段,在此阶段中,AEF通过修改凭证链

中的数据或合并发起者的凭证链来改变发起者的凭证链。

c凭证使用。图9中最右边一列的状态属于此阶段,在此阶段中,AEF在授权判定或创建可传

递给其他AEF的PAC中使用凭证链。

6.3.1没有包括在状态图中的函数

6.3.1.1概述

为了简化状态图,状态图中忽略了一些授权API函数,这些忽略掉的函数包括:

a)管理函数;

b)内存管理;

c)出错信息的获取

d)凭证信息获取;

e)资格。

1.2管理函数

管理函数包括授权API的初始化和关闭函数。初始化在使用任何授权API函数前必须调用。关

闭函数在调用最后一个授权函数后或在AEF退出前必须被调用。

12

GB/T31501—2015

6.3.1.3内存管理

这些函数包括创建和删除凭证链和属性列表数据结构。这些数据结构必须在使用前被创建。在创

建凭证链的调用中假定凭证链的内存通过调用azn_creds_create已被分配。授权服务不释放凭证链和

属性数据结构内存,AEF必须调用azn_release或azn_credential_delete来释放内存。

6.3.1.4出错信息的获取

在调用授权API函数返回一个出错状态后,可以调用出错信息获取函数。

6.3.1.5凭证信息获取

在建立凭证链后的任何时候都可以调用此类函数。

6.3.1.6资格

在建立凭证链后的任何时候都可以调用此类函数。

6.4信任模型

6.4.1概述

安全系统的每一个组件需要知道其信任哪些组件,以及它们可以被信任来做什么。本条目表述了

使用授权API的系统组件之间的信任关系。

6.4.2鉴别和授权的关系

授权API将鉴別和授权分离开来,如图10所示:

鉴别和授权的关系

发起者可以使用鉴別服务来创建一个标识,AEF在接收发起者访问请求时获取此标识。

AEF调用授权API将发起者标识转化为凭证链,凭证链被用来做访问控制判定。

在实现中如果需要将发起者的请求传递给另一个AEF,AEF可以调用授权API将凭证链转化成

一个PAC,此PAC表示授权服务对发起者的观点(此处不是鉴別服务对发起者的观点,鉴別服务的观

点表示为标识)。

另外一个AEF接收到此PAC后,可以将其转化为一个凭证链,此凭证链可用于访问控制判定。

13

GB/T31501—2015

在一个使用授权API的系统中:

•鉴别数据表示为标识;

•发起者的授权数据ACI,在授权服务中总是表示为凭证链;

•关于发起者的授权数据ACI在授权服务外总是表示为PAC0

基于以上原因,可以区分鉴别数据和授权数据。

关于鉴别数据的可信判定取决于AEF,—个授权APT实现并不对其他AEF传递来的身份信息是

否可信作出判断。

6.4.3TCB边界

图11表示AEF、授权API、ADF、PAC服务、鉴別服务和鉴別服务使用的任何机制均位于系统的可

信计算基(TCB中,因此需要防止其未经授权被修改。

图11授权API系统中的信任关系

系统中的组件有如下信任关系:

a目标资源的属主信任AEF,隐含地信任鉴别和授权服务(包含在最外边的灰色框内的所有组

件),以此来阻止非授权的发起者访问目标。

b)鉴别服务信任鉴別机制功能正确,同时能够提供发起者正确的标识。

cAEF信任鉴别服务提供正确的和经过鉴别的发起者标识,隐含地信任鉴別机制。

d授权API信任AEF提供正确的ACI0

eAEF信任授权API能够做出并且返回正确的访问判定,同时可以返回正确的PAC、资格和凭

证链特权属性,AEF隐含地信任授权服务。

f)授权服务信任实现基于发起者安全属性存储能够将发起者标识正确地转化为凭证链。

g授权API信任PAC服务能够将凭证链正确地转化为PAC服务,并且返回正确的凭证链特权

属性。

14

GB/T31501—2015

h)授权API实现和PAC服务信任安全属性存储能保持正确的信息。

1)授权API信任授权服务ADF能够基于访问控制策略做出正确的访问判定°

j)授权API信任授权服务的资格服务(ES)能够基于访问控制策略存储返回正确的资格。

k)ADF和ES信任访问控制策略存储包含正确的信息。

7功能和可移植性要求

7.1功能要求

7.1.1函数

表3中描述的函数应该在aznAPI中实现,并且要与本标准保持一致。

表3必须实现的函数

函数名称说明

azn_atttlist_*rallaltrlistcalls*/

azn_creds_create

azn_creds_delete

azn_decision_access_allowed

azn_error_*I*allerrorcalls*/

azn_id_get_creds

azn_initialize

azn_release/*allreleasecalls*/

azn_shutdown

在第6章中描述的其他函数功能可以选择实现,而对于未实现的功能,函数要返回AZN_S_UN-

IMPLEMENTED_FUNCTI()N。

本标准采用标准C语言格式对aznAPI函数进行了定义和描述,参见附录A。

7.1.2授权、服务、模式和机制

所有的授权服务实现必须支持使用AZN_NULL_ID,此参数表明使用缺省的权威和缺省的机

制TD0

提供资格服务、标记模式、凭证修改服务和PAC服务的授权实现必须支持使用AZN_NULL_ID,

此参数表明使用缺省的服务或模式。

授权服务实现不要求支持任何显式权威、模式、机制或服务ID。

将来,补充标准可以定义授权、模式、机制和服务ID的标准可移植集合。

7.1.3属性

所有授权API实现必须能够从azn_initialize中返回AZN_C_VERSION属性和其字符值。

7.2移植性要求

应用程序如果只使用以上描述的aznAPI的功能,并且aznAPI的不同实现都支持应用程序的资源

和操作,那么这些不同实现之间具有可移植性。

15

GB/T31501—2015

本标准不为受保护的资源或操作定义标准的命名空间或命名词法。

在受保护的资源和操作的命名空间和命名词法定义前,程序开发者需要检查他们的授权API文

档,以此来保证他们的资源名称和操作名称在其使用的授权API中被支持。

8常量和变量定义

&1字符串与类字符串数据

&1.1缓冲区

大量的授权API程序采用内存缓冲区作为其参数或返回值。内存缓冲区在授权API间传递,同时

调用者使用azn_buffer_t来描述单字节缓冲区,此数据类型是一个指向缓冲区描述符的指针,其缓冲区

描述符包括一个长度域和一个值域,长度域描述数据长度,而值域包含一个指向真实数据的指针:

typcdefstruct

azn_buf£er_desc_struct{

size_tlength;

void*value;

}azn_buffer_desc»*azn_buffer_t;

azn_buf£er_dcsc对象内存的分配和释放应由应用程序来执行,新创建的azn_buffer_dcsc对象可以

初始化为AZN_C_EMPTY_BUFFERo

azn_buffer_t客体在azn_attrlist_get_entry_buf£er_value和azn_creds_get_pac中是—输出,在

这种情况下,在azn」)uffer_desc中的缓冲区数组分配由授权API来实现,此种缓冲区必须由应用程序

调用azn_rclease_buffer来释放。

8.1.2字符串

大量的授权API程序以字符串作为其输入参数和返回值,调用者使用azn_String_t数据类型在授

权API间传递字符串:

typcdefchar*azn_string_t;

这是一个字符串数据类型,用来编码标识能力、许可或类似概念。

字符串使用以“\0”为结尾的UTF-8字符数组来表示。

&1.3凭证句柄

大量的授权API以凭证句柄为其参数或返回凭证句柄。调用者使用aZn_crcds_h_t数据类型在授

权API间传递凭证句柄:

typcdefunsignedintazn_creds_h_t

各种类型的azn_creds_h_t被非透明地处理,这与凭证链的具体实现有关。

在应用程序使用凭证句柄前,其必须调用azn_crcds_create来初始化句柄,此函数分配一个新的、

空的凭证链结构,并将其与一个句柄相关联,并返回此句柄。

当应用程序不再需要一个凭证链结构时,应用程序必须调用azn_creds_delete来释放凭证链结构。

&1.4属性列表句柄

大量的授权API程序以属性列表句柄为其参数或者返回一个属性列表句柄。调用者使用azn_at-

trlist_h_t数据类型在授权API间传递属性列表句柄。

typcdefunsignedintazn_attrlist_h_t

16

GB/T31501—2015

各种azn_attrlist_h_l被非透明地处理,这与授权API实现维护的名称/值对列表有关。授权API

提供接口通过属性列表句柄指定属性列表来获取名称/值对。

在应用程序使用属性列表句柄前,应用程序必须调用azn_attrlist_create来初始化句柄。

当应用程序不需要此句柄时,需要调用azn_attrlist_dclcte来删除句柄。

&2状态值

授权API程序返回类型为azn_status_t的状态编码:

typcdefunsignedintazn_status_t

定制服务

    推荐标准