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

《GB T 31501-2015 信息安全技术 鉴别与授权 授权应用程序判定接口规范.pdf》由会员分享，可在线阅读，更多相关《GB T 31501-2015 信息安全技术 鉴别与授权 授权应用程序判定接口规范.pdf（56页珍藏版）》请在麦多课文档分享上搜索。

1、 4 ICS 35.040 L 80 道昌中华人民共和国国家标准GB/T 31501-2015 信息安全技术鉴别与授权授权应用程序判定接口规范Information security technology-Auhentication and authoriz2.t:ivn一Specification fo:r authorzation application progr部nmingdecisioI in1uf士2015-05-15发布2016-01-01实施/:71飞中华人民共和国国家质量监督检验检疫总局串士啥叫:中国国家标准化管理委员会。叩GB/T 31501-2015 目次前言. . .

2、. . . . . . 1 引言. ., . . . . . n 1 范围. 2 规范性引用文件. 3 术语和定义.4 缩略语. . . . . . . . . 3 5 框架. 5.1 访问控制框架. . . . . 5.2 访问控制服务组件. . . . . 4 5.3 访问控制信息6 授权API使用模型. . . . . . . . 10 6.1 系统结构. . . . . . . . . . . . 10 6.2 支持的画数. . . . . . . . 10 6.3 状态机. 6.4 信任模型. . 7 功能和可移植性要求. . . . . . . . . . . . . . 15 7

3、.1 功能要求.7.2 移植性要求. . 8 常量和变量定义. . . . . . . . . . . . 8.1 字符串与类字符串数据. . . . . . . . 16 8.2 状态值. . . . . . . 17 8.3 常量. . . . . . . . . . . 18 8.4 授权和机制ID. . . . . 20 附录A(资料性附录)画数说明. . 22 参考文献. . . . . . . . 51 . 矗GB/T 31501-2015 .a.&. _ 目。亩本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能静及专利。本文件的发布机构不承担识别这些专利

4、的责任。本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口。本标准起草单位z中国科学院软件研究所、北京数字证书鉴别中心有限公司、中科正阳信息安全技术有限公司。本标准主要起草人z冯登国、张立武、李晓峰、王雅哲、高志刚、徐震、段美妓、汪丹、黄亮、瞿征德、詹榜华。I GB/T 31501-2015 sl 访问控制作为一种基本的安全措施在实际系统中得到广泛的应用，随着访问控制技术的日趋复杂，访问控制已成为一类安全基础服务，而广泛的应用集成需求需要访问控制安全服务能够给应用程序提供一个统一的编程接口，使得应用程序能够在不同的访问控制服务之间具有可移植性，而目前缺少这类国家标准。为了解决

5、这个问题，本标准参考了QpenGroup的技术标准(参考文献lJ)等相关栋准和规范，在保证适应多种应用场景的情况下，定义了授权应用程序判定接口规范。本标准定义的授权应用程序判定接口规范可用于符合GB/T18794.3访问控制框架的系统中，尽管本标准提供了允许主体控制哪些特权属性可以被用于访问控制授权请求判定中(通常被称为最小特权)，但并不提供特权属性管理。E 本标准的设计目标如下za) 定义一个简单、灵活的API，安全组件提供者和需要安全保护的应用程序开发者可以通过调用此API来实现授权功能;b) 访问判定时可以应用透明地进行策略规则的评估Fc) 独立于应用的策略集中管理zd) 透明地提供广泛

6、的策略规则词法和语义如访问控制列表、能力、标签、逻辑谓词等he) 将鉴别和授权分离;f) 允许从鉴别数据中推导出授权属性;g) 透明地支持任意合理的授权属性类型(如访问标识、组、角色等hh) 易于在多层次结构的应用系统中提供授权服务;。在多层应用配置中允许使用外部授权属性;j) 应用程序可以访问应用于其资源的访问控制策略1k) API的实现支持多种访问控制机制;D 单一程序可以同时使用多个鉴别和授权服务;m)支持应用程序访问与授权服务操作相关的审计数据。本标准不涉及以下内容za) 授权策略管理;b) 描述证书委托服务或语义zc) 描述一个审计服务API;d) 描述授权服务如何以及何时生成审计事

7、件;e) 在异构环境下，定义用来交换证书信息的PAC格式;f) 支持每一种可能的授权策略规则词法和语义。品1 范围信息安全技术鉴别与授权授权应用程序判定接口规范GB/T 31501-2015 本标准定义了访问控制服务为授权应用提供的授权判定编程应用接口，并定义了与判定接口相关的数据结构和C语言形式的接口。本标准适用于访问控制服务中授权判定接口的设计和实现，访问控制服务的测试和产品采购亦可参照使用。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB，尸r1894.3-2

8、003信息技术开放系统互连开放系统安全框架第3部分:访问控制框架GB, T 2号:59-2010信息安全技术术语3 术语和定义3.1 3.2 GB/T 25069-2010界定的以及下列术语和定义适用于本文件。访问控制信息access control information 用于访问控制目的的任何信息，其中包括上下文信息。GB/T 18794.3一2003，定义3.4.5J访问控制判定功能acc四scontrol decision function 一种特定功能，它通过对访问请求、ADI(发起者的、目标的、访问请求的或以前决策保留下来的ADI)以及该访问请求的上下文，使用访问控制策略规则而做出

9、访问控制判定。3.3 3.4 GB/T 18794.3-2003，定义3.4.3J访问控制判定信息access control decision information 在作出一个特定访问控制判定时可供ADF使用的部分(也可能是全部)ACI。GB/T 18794.3-2003，定义3.4.2J访问控制实施功能access control enforcement function 一种特定功能，它是每一访问请求中发起者和目标之间访问路径的一部分，并实施由ADF做出的决策。GB/T 18794.3-2003，定义3.4.4J1 GB/T 31501-2015 3.5 3.6 3.7 3.8 3.9

10、 3.10 3.11 3.12 3.13 访问请求access requ副操作和操作数，它们构成一个试图进行的访问的基本成分。GB/T 18794.3-2003，定义3.4.9J属性列表attribute list 由属性名称和属性值构成的数据列表。审计标识audit identity 包含一个用于审计目的标识的属性。授权机构authorizatioo autbority 管理授权数据的实体。能力capability 表明拥有者具有访问某项系统资源的权限的标记。许可扭cJearance 能用来与目标安全标签进行比较的发起者绑定ACIGB/T 18794.3-2003.定义3.4.13J凭证链C

11、l叫entialschain 多个凭证根据相互关系构成的具有层次的结构.凭证旬柄c.redential handle 指向凭证链的句柄。合成凭证链combined credentials ch剑n由多个凭证链构成的有序列表。列表中的第一个元素是访问请求发起者的凭证链，列表中的其他元素是传递这个访问请求的一系列中介的凭证链e3.14 判定decision ADF对判定请求的响应。3.15 判定请求decision r叫回回tAEF发送给ADF的信息，此信息询问ADF允许还是拒绝一个特定的访问请求。3.16 资格entitlement 包含ADI和访问控制策略规则信息的数据结构，应用程序可以使用此

12、信息来决定其行为或者在其代码中进行访问控制判定。3.17 标识identity 传递到aznAPI的发起者ACI，本标准使用这个术语来描述所有发起者的信息，包括名称、身份证2 GB/T 31501-2015 书和能力。3.18 3.19 3.20 3.21 3.22 3.23 发起者initiator 一个试图访问其他实体的实体(如人类用户或基于计算机的实体)。GB/T 18794.32003，定义3.4.15J中介intermediary 负责转发发起者的访问请求的实体。标签label 与受保护资源绑定的标记，其标明了此资源的安全相关属性。操作operation 发起者的访问请求中要求在受保

13、护资源上执行的具体访问动作。特权属性证书privilege atlribute certificate; PAC 保护特权属性的数据结构，产生此属性的权威可能对其进行签名。特权属性privil鸣eatlribute 与发起者相关的属性，当与受保护资源的控制属性匹配时，用来允许或拒绝访问此受保护资源。3.24 3.25 受保护资源protect ;SUTce 访问受访问策略限制的目标。目标target 被试图访问的实体。GB/T 18794.3-2003，定义3.4.23J4 缩暗语下列缩略语造用于本文件。ACI:访问控制信息(accesscontrol inforrnation) ADF:访问

14、控制判定功能(accesscontrol decision function) ADI:访问控制判定信息(accesscontrol decision inforrnation) AEF:访问控制实施功能(accesscontrol enforcernent function) API:应用程序编程接口(applicationprograrnrning interface) aznAPI:授权应用程序编程接口(authorizationapplication prograrnrning interface) ID:标识(identity)PAC:特权属性证书(privilegeattribut

15、e certificate) SSL:安全套接层(securesockets layer) 5框架5.1 访问控制框架本标准采用的访问控制服务框架的定义见GB/T18794.3-20030 3 GB/T 31501-2015 5.2 访问控制服务组件5.2.1 ADF ADF根据ADI做出访问控制判定。ADI描述了发起者、目标、访问请求、系统和环境安全相关的属性。ADI的详细定义见5.3.2.2。图1描述了ADF用来进行访问控制判定的信息。判决请求判决发起者ADI目标ADI上下文告息ADF 访问请求ADI访问控制策略圄1ADF输入5.2.2 AEF 访问控制实施功能实施ADF的访问控制判定结果

16、。aznAPI是一个媒介，通过此API，AEF调用ADF来获取访问控制判定的结果。AEF使用此API向ADF传递ACI.如圈2所示，aznAPI的实现负责从AEF提供的ACI中推导出ADI，并且将此ADI提交给ADF.ADF根据上述ADf信息，以及访问控制策略和当前上下文ADI来做出访问判定。发起着ACI目标ACl访问请求ACI策略规则上下文ACI圄2AEF使用授权API调用ADF4 5.3 访问控制信息5.3.1 概述ACI是AEF可获取的与访问控制判定可能相关的信息。aznAPI的职责是za) 确定AEF提交的与访问控制判定有关的ACI信息sb)将AEF提交的ACI转化为ADF可用的ADI

17、;c) 将ADI提交给ADF.5.3.2 发起者信息5.3.2.1 发起者ACIGB/T 31501-2015 发起者ACI描述了访问请求发起者安全相关属性，是AEF可获取的发起者信息。由鉴别服务生成的发起者ACI数据结构在本标准中称为标识。标识可以很简单，例如只包括发起者的名称字符串z也可以很复杂，例如包括数字证书。授权API可以接受能力作为标识，能力是由鉴别服务提供的直接断言，如图3所示，在能力中并不是必须要标明发起者，无论谁拥有能力都可以使用。在图3中，发起者使用虚线来表示。能力中包括一个策略人口列表，每个人口指定了一个目标客体，同时定义规则用来描述发起者允许执行的操作。注:aznAPI

18、实现不要求支持所有的标识格式，同时也不是必须要支持能力。客体2: 发起者: 规则2.1授权断言圄3能力由授权服务产生的发起者ACI数据结构被称为PAC.并不是只有授权服务可以产生PAC，鉴别服务也可以产生PAC来声称用户标识。在推模式中，PAC是用户特权属性。(aznAPI实现中，由鉴别服务产生的PAC被当作标识来处理，以此来区分AZN自己产生的授权数据结构。)aznAPI实现也可以将PAC数据结构作为用户凭证信息的内部表示，AEF通过aznAPI是不可见这些数据结构的，PAC应符合5.3.8.1.5.3.2.2 发起者ADI发起者ADI是从发起者ACI中衍生出来的授权相关信息，通过aznAP

19、I传递给ADF.aznAPI将发起者ADI存储在称为凭证链的数据结构中。因为凭证链不会传递给aznAPI的调用者，同时不同的授权服务可以使用不同的凭证链格式，所以凭证链数据结构格式定义不包括在此标准中。尽管aznAPI不允许调用者直接访问凭证链，但其提供访问凭证链属性信息的接口画数。图4显示了aznAPI如何将发起者ACI转换为凭证链，并且返回一个凭证句柄给调用者，aznAPI可以用在将特权属性从客户端推到AEF的系统中，或者要求AEF从某个存储或服务中采用拉模式获G/T 31501-2015 取特权属性的系统中。在推模式环境下，发起者ACI中包含被客户端推来的特权属性，并且被转换为可以被az

20、nAPI实现使用的内部数据。在拉模式环境下.ACI发起者只包含单一特权属性(如发起者被鉴别的名称).而aznAPI实现在构建发起者凭证链时，从适当的存储或结构中获取发起者的其他特权属性。认证服务-r-访问请求发起者AEF 柄句任信发起者ACI认证标识)aZJ民PI发起者ADI认证标识_一一一_一一_J回民PI实现发起者安全属性发起者ACI到凭证的转换圄4目标信息5.3.3 概述目标信息描述了访问请求中与目标相关的安全信息zu 目标ACI:AEF可以获取的目标信息。b) 目标ADI:aznAPI转换目标ACI获得的目标信息。5.3.3.1 目标ACI通常aznAPI需要的目标ACI数据只是目标名

21、。安全标签是此规则的特例。aznAPI可以支持包含安全标签的ADI的访问控制判定。在某些基于标签的授权系统中，授权服务并不知道标签信息是如何在目标中被编码的，以及标签是如何以与目标相关的元数据的方式存储起来的。在这些例子中.AEF需要获取目标安全标签，并将它们作为目标ACI5.3.3.2 GB/T 31501-2015 传递给aznAPI.授权API可以被实现为支持处理不同类型的标签.在支持多种标签的实现中，调用者需要明确使用的标签模式ID.使得API知道在此调用中使用哪类标签。5.3.3.3 目标ADI不同的授权服务实现可以包含不同数量的目标ADI和数据类型。目标ADI数据通常并不返回给调用

22、者，所以目标ADI数据格式不在此标准中定义。由于有些授权API调用者可能会因为其他用途使用授权策略数据，所以授权API支持将ADI数据外部化为数据结构，此数据结构称为资格。资格应符合5.3.8.2。5.3.4 请求信息5.3.4.1 概述请求信息描述了访问请求相关的安全属性zu 请求ACI是AEF可以获取的请求信息zb) 请求ADI是授权API将请求ACI转换后的请求信息。5.3.4.2 请求ACIaznAPI要求请求ACI包含请求的操作名称。5.3.4.3 请求ADI不同授权服务实现可以有不同类型和数量的请求ADI数据，请求ADI数据并不返回给调用者，所以请求ADI数据格式并不在此标准中定义

23、。5.3.5 上下文信息5.3.5.1 棋迷上下文信息描述了访问请求发生上下文的安全相关属性。上下文ACI是AEF可以获取的上下文信息。上下文ADI有两个来源za) aznAPI将上下文ACI转换后的结果zb) 授权服务可以直接获取而并非由ACI提供的上下文信息，5.3.5.2 上下文ACIaznAPI定义了四种上下文ACI数据，这些数据可以作为上下文信息传递给授权服务z时间z请求发生的时间F一-地点z请求发起的地点(源地址)I -一一路由:将请求从发起者传递到AEF通过的连接F一一鉴别质量z用于建立发起者身份的鉴别的质量。上下文信息并不局限于此。aznAPI允许AEF使用非透明类型的参数传递

24、给授权服务，使用这些参数说明应用或授权服务相关的上下文信息。使用这些通过不透明参数传递特定上下文信息格式的授权服务的应用可移植性低。5.3.5.3 上下文ADI不同的授权服务的实现可以有不同数量和类型的上下文ADI数据。上下文ADI数据在aznAPIGB/T 31501-2015 中不返回给调用者，所以在此标准中不定义上下文ADI数据格式。5.3.6 预留信息授权服务可以保留同一发起者请求的操作序列信息，并由此来做出访问控制判定。如，用于ATM中的授权服务保存了每个用户在当前所取的钱数信息，并以此来实现每天的取钱限制策略。授权服务为此目的保留的信息是ADI，并且不会通过授权API暴露给应用程序

25、。因此，保留的ADI信息的格式在此标准中不涉及。5.3.7 访问控制策略信息访问控制策略信息包括用来评估其他的ADI并且做出访问控制决策的规则。调用者并不能从授权API中获取访问控制策略信息，不同的授权服务可以使用不同类型和数量的访问控制策略信息，所以访问控制策略信息格式不在此标准中定义。授权服务可以以资格的形式外部化访问控制策略信息，这部分内容在5.3.8.2中描述。5.3.8 外部化ADI授权API对调用者有意隐藏了发起者ADI和访问控制策略信息的细节。然而，这些信息在某些情况下对调用者是有用的，因此，授权API允许授权服务外部化发起者ADI和访问控制策略信息。5.3.8.1 PACs 授

26、权API将外部化的发起者ADI放在一个称为PAC的数据结构中，图5表明了PAC的创建过程。发起者ADI的外部化允许授权服务以它的角度断言发起者的安全相关特征，这与从鉴别服务角度看到的发起者的安全相关特征是不同的。某授权服务可以使用这个功能产生签名的属性证书，其他服务以此作为授权数据源。因为此标准只定义了一个不透明的PAC结构，由一个授权服务产生的PAC不能保证被其他授权服务使用。在将来的标准中会定义一个标准的PAC结构，以此为基础，授权服务之间可以传递发起者授权属性的断言。注2签名的PAC可以用来构建委托协议.aznAPI不能提供委托服务.一个委托协议必须允许希望成为发起者请求委托的实体可以将

27、以下内容传递给一个目标s被委托的请求、一个可信表示，证明最初从访问发起者处得到的请求已经被鉴别、委托者被授权将请求以发起者的名义转发给目标的可信表示、发起者的信任表示和委托者的凭证信息。授权服务可以签名PAC来形成发起者的信任表示和委托者的凭证信息，甚至可以包含身份信息(如证书发布者标识和身份证书序列号)建立起到发起者鉴别数据的一个链接，但授权服务并不在请求中绑定PAC(以加密或其他方式。代表发起者或作为发起者委托者身份的AEF必须使用一个独立的加密设施或委托服务来绑定由aznAPI生成的PAC与委托请求消息。5.3.8.2 资格授权API将外部化的访问控制策略信息存储在称为资格的数据结构中。

28、外部化的访问控制策略信息允许应用程序基于授权策略来定制系统的行为。例如，其允许应用程序修改系统菜单来显示发起者可以执行的访问，而不是显示系统中所有的操作。资格信息也可以被应用程序用来做出其自己的访问判定，而不是依赖于在授权服务中实现的ADFQ8 GB/T 31501-2015 访问请求娟和AEF 发起者问问叫-MUJ发起者安全属性凭证外部化为PAC授权API定义了一个可移植的、每个授权服务可以支持的资格数据格式，是一个特定发起者可以在某个特定目标上执行的操作列表。图6显示资格信息的格式示例。主体数据周围的虚线表示发起者数据是隐含的，其并不包含在授权API返回的资格数据中。圈5目标1目标2允许的

29、操作列表允许的操作列表禁止的操作列表禁止的操作列表: 发起者: 可移植的资格示例可移植的资格数据表示保证了在所有的授权服务中都可以被支持，但其不是非常有效的。一些授权服务可能使用单一规则或者使用通配符来表示发起者在许多目标上的操作授权，甚至可以用一个单一规则或表达式来描述多个发起者的授权，然而不同的授权服务使用不同的规则格式，并且不存在一个单一规则格式可以用来有效地表示所有授权服务，基于这个原因，授权API允许授权服务以非透明类型参数的形式返回非移植的资格信息，如图7所示，非移植资格信息可通过任意的规则方式进行描述。9 圄6GB/T 31501-2015 规则2规则1非移植资格示例使用非移植资

30、格要求调用授权A凹的应用程序来理解授权服务规则格式，并且防止调用授权API的应用程序使用有不同规则格式的授权服务。圄7摆扭API使用模型6 系统结构6.1 目标图8是使用授权A凹的系统结构。发起着AEf 授权APIiIttttlllttttti-. -访问策略信息授权API具体实现发起者安全属性摆棋API系统结构在使用授权API的系统中的资源请求由AEF来仲裁。AEF鉴别用户(通常使用鉴别服务).同时AEF也通过将访问控制信息传递给授权API来授权请求，其完成被授权的请求并且拒绝未被授权的请求。授权API将从AEF中发来的ACI转换成ADI.同时利用ADF做出访问判定。ADF使用ADI和访问策

31、略规则来判定发起者在目标上执行操作的请求是被允许还是拒绝。圄8支持的画数6.2 表1列出了文献lJ中提供的授权API函数集，并且简单描述了每一个函数集的功能。10 GB/T 31501-2015 表1授权服务API函数接口集命名前缀接口集支持的功能azn_initialize, azn_shutdown 初始化授权API的实现系统停止运行时，清除授权A凹的实现创建、删除、修改和合并链azn_creds 从凭证链中获取信息基于凭证链创建PACazn_id 基于由鉴别服务产生的鉴别标识建立鉴别链azn_decision 做出访问判定azn_entitlement 获取访问控制策略信息azn_pac

32、 基于由授权服务产生的PAC建立凭证链azn_error 从由授权API函数返回的状态值中获取错误信息azn_authority 由aznAPI实现支持的鉴别、授权和凭证、标签、pac发现机制创建和删除属性/值列表azn_attrlist 将参数写人属性/值列表从属性/值列表中读取参数数据azn_release 释放在授权API实现中分配的数据6.3 状态机图9概:r，:-了调用授权API应用的状态机(逼常是一个AEF)，AEF应该按罔中的顺序调用授权API函数。匹中所描述的仅是状态机的大致情况，并没有列举出授权服务实现调用者所有可能的状态。由于AEF通过API而不是授权API调用鉴别服务，所

33、以圈中并非每个状态都是由授仅API函数调用引起的。系统获取发起者ACI (被认证标识)AEF获取发起者ACI (被认证标识AEF获取发起者ACI (PAC) 10 固9握权API状态机概览AEF获取访问判决AEF获取发起者ACI (PAC) 14 11 L GB/T 31501-2015 表2指明了可以引起状态转移的授权API函数调用和其他AEF操作。表2授扭API状态机迁移迁移引起迁移的操作1 2 3 4 5 6 7 8 9 10 11 12 13 14 AEF获取已被鉴别服务鉴别的发起者的请求AEF获取请求.AEF鉴别发起者AEF获取由一个授权API实现产生的PAC所描述的发起者的请求AE

34、F调用azn_decision_access_allowed来授权请求授权服务使用从环境中获取的鉴别服务标识隐含地|建立凭证链)AEF词用azn_id_get_creds.其参数中的ID为空(授权服务使用从环境中获取的鉴别标识)AEF调用azn_iget_creds，其参数中的田是在鉴别发起者时由AEF产生AEF词用azn_pac_get_credsAEF词用azn_crecls_combine来给发起者添加凭证链AEF调用azn-treds_rnoCtlfy来改变凭证链的属性AEF调用azn_creds_tnodify来改变凭证链的属性AEF词用azn_decision_access_all

35、owedAEF调用azn_creds_get_pacAEF调用azn_creds_get_pacAEF调用azn_decision.，_access_allowed图9的状态机可以分为三个阶段za) 凭证建立。圄9中初始状态的最左边一列的状态属于此阶段，在此阶段中.AEF使用授权API建立凭证链，授权服务将使用此凭证链作为后续操作的基础。b) 凭证修改。图9中初始状态的右边的第二列属于此阶段，在此阶段中.AEF通过修改凭证链中的数据或合并发起者的凭证链来改变发起者的凭证链。c) 凭证使用。图9中最右边一列的状态属于此阶段，在此阶段中.AEF在授权判定或创建可传递给其他AEF的PAC中使用凭证链

36、。6.3.1 没有包括在状态圄中的函数6.3. 1. 1 概述为了简化状态图，状态图中忽略了一些授权API函数，这些忽略掉的函数包括:a) 管理函数zb) 内存管理Pc) 出错信息的获取;d) 凭证信息获取Ee) 资格。6.3.1.2 管理画敢管理函数包括授权A凹的初始化和关闭函数。初始化在使用任何授权API函数前必须调用。关闭函数在调用最后一个授权函数后或在AEF退出前必须被调用。12 GB/T 31501-2015 6.3.1.3 内存管理这些画数包括创建和删除凭证链和属性列表数据结构。这些数据结构必须在使用前被创建。在创建凭证链的调用中假定凭证链的内存通过调用azn_creds_crea

37、te已被分配。授权服务不释放凭证链和属性数据结构内存，AEF必须调用azn_release或azn_credentiaLdelete来释放内存。6.3.1.4 出错信息的获取在调用授权API函数返回一个出错状态后，可以调用出错信息获取函数。6.3.1.5 凭证信息获取在建立凭证链后的任何时候都可以调用此类函数。6.3.1.6 资格在建立凭证链后的任何时候都可以调用此类函数。6.4 信任模型6.4 .1 概述安全系统的每一个组件需要知道其信任哪些组件，以及它们可以被信任来做什么。本条目表述了使用授权API的系统组件之间的信任关系。6.4.2 鉴别和授权的关系授权API将鉴别和授权分离开来，如图1

38、0所示:目标圄10鉴别和授权的关系发起者可以使用鉴别服务来创建一个标识，AEF在接收发起者访问请求时获取此标识。AEF调用授权API将发起者标识转化为凭证链，凭证链被用来做访问控制判定。在实现中如果需要将发起者的请求传递给另一个AEF，AEF可以调用授权API将凭证链转化成一个PAC，此PAC表示授权服务对发起者的观点(此处不是鉴别服务对发起者的观点，鉴别服务的观点表示为标识。另外一个AEF接收到此PAC后，可以将其转化为一个凭证链，此凭证链可用于访问控制判定。GB/T 31501-2015 在一个使用授权A凹的系统中2 鉴别数据表示为标识; 发起者的授权数据ACI，在授权服务中总是表示为凭证

39、链; 关于发起者的授权数据ACI在授权服务外总是表示为PACo基于以上原因，可以区分鉴别数据和授权数据。关于鉴别数据的可信判定取决于AEF，一个授权API实现并不对其他AEF传递来的身份信息是否可信作出判断。6.4.3 TCB边界图11表示AEF、授权API、ADF、PAC服务、鉴别服务和鉴别服务使用的任何机制均位于系统的可信计算基(TCB)中，因此需要防止其未经授权被修改。发起者圄11授权API系统中的信任关系系统中的组件有如下信任关系za) 目标资源的属主信任AEF，隐含地信任鉴别和授权服务(包含在最外边的灰色框内的所有组件)，以此来阻止非授权的发起者访问目标。b) 鉴别服务信任鉴别机制功

40、能正确，同时能够提供发起者正确的标识。c) AEF信任鉴别服务提供正确的和经过鉴别的发起者标识，隐含地信任鉴别机制。d) 授权API信任AEF提供正确的ACloe) AEF信任授权API能够做出并且返回正确的访问判定，同时可以返回正确的PAC、资格和凭证链特权属性，AEF隐含地信任授权服务。f) 授权服务信任实现基于发起者安全属性存储能够将发起者标识正确地转化为凭证链。g) 授权API信任PAC服务能够将凭证链正确地转化为PAC服务，并且返回正确的凭证链特权属性。14 GB/T 31501-2015 h) 授权API实现和PAC服务信任安全属性存储能保持正确的信息。i) 授权API信任授权服务

41、ADF能够基于访问控制策略做出正确的访问判定。j) 授权API信任授权服务的资格服务(ES)能够基于访问控制策略存储返回正确的资格。k) ADF和ES信任访问控制策略存储包含正确的信息。7 功能和可移植性要求7.1 功能要求7. 1. 1 函数表3中描述的函数应该在aznAPI中实现，并且要与本标准保持一致。表3必须实现的函数函数名称说明azn_atttlist_ /. all attrlist calls / azn_creds_create azn_creds_delete azn_decision_access_allowed azn_error_ . /. all error call

42、s / azn_id_get_creds azn一initializeazn_release /. all release calls / azn shutdown 在第6章中描述的其他函数功能可以选择实现，而对于未实现的功能，函数要返回AZN一旦UNIMPLEMENTED_FUNCTION 0 本标准采用标准C语言格式对aznAPI函数进行了定义和描述，参见附录A.7.1.2 授权、服务、模式和机制所有的授权服务实现必须支持使用AZN_NULL_ID，此参数表明使用缺省的权威和缺省的机制ID。提供资格服务、标记模式、凭证修改服务和PAC服务的授权实现必须支持使用AZN_NULL_ID.此参数

43、表明使用缺省的服务或模式。授权服务实现不要求支持任何显式权威、模式、机制或服务ID.将来，补克标准可以定义授权、模式、机制和服务ID的标准可移植集合。7. 1.3 属性所有授权API实现必须能够从azn_initialize中返回AZN_C_VERSION属性和其字符值。7.2 移植性要求应用程序如果只使用以上描述的aznAPI的功能，并且aznAPI的不同实现都支持应用程序的资源和操作，那么这些不同实现之间具有可移植性。15 GB/T 31501-2015 本标准不为受保护的资源或操作定义标准的命名空间或命名词法。在受保护的资源和操作的命名空间和命名词法定义前，程序开发者需要检查他们的授权A

44、PI文档，以此来保证他们的资源名称和操作名称在其使用的授权API中被支持。8 常量和变量定义8.1 字符串与类字符串数据8. 1. 1 缓冲区大量的授权API程序采用内存缓冲区作为其参数或返回值。内存缓冲区在授权API间传递，同时调用者使用azn_buffer_t来描述单字节缓冲区，此数据类型是一个指向缓冲区描述符的指针，其缓冲区描述符包括一个长度域和一个值域，长度域描述数据长度，而值域包含一个指向真实数据的指针ztypedef struct azn_buffer_desc_struct size_t length; void val ue; azn_buffer_desc, azn_buffer_t; azn_buffer_desc对象内存的分配和释放应由应用程序来执行，新创建的azn_buffer_desc对象可以初始化为AZN_C_EMPTY_BUFFER o azn_buffer_t客体在azn_attrlist_get_entry_buffer_ value和azn_creds_get_pac中是一个输出，在这种情