Internet Engineering Task Force (IETF) J. Howlett
Request for Comments: 7833 Jisc
Category: Standards Track S. Hartman
ISSN: 2070-1721 Painless Security
A. Perez-Mendez, Ed.
University of Murcia
May 2016
Internet Engineering Task Force (IETF) J. Howlett
Request for Comments: 7833 Jisc
Category: Standards Track S. Hartman
ISSN: 2070-1721 Painless Security
A. Perez-Mendez, Ed.
University of Murcia
May 2016
A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)
安全断言标记语言（SAML）的RADIUS属性、绑定、概要文件、名称标识符格式和确认方法
Abstract
摘要
This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting (AAA) scenario, such as network access control.
本文档描述了在web之外的联合访问（ABFAB）体系结构的应用程序桥接上下文中使用RADIUS的安全断言标记语言（SAML）。它定义了两个RADIUS属性、一个SAML绑定、一个SAML名称标识符格式、两个SAML概要文件和两个SAML确认方法。RADIUS属性允许在RADIUS中封装SAML断言和协议消息，从而允许SAML实体使用绑定进行通信。这两个概要文件描述了此绑定在ABFAB身份验证和断言查询/请求中的应用，使依赖方能够请求用户或机器（客户端）的身份验证或断言。这些客户端可以使用网络访问标识符（NAI）名称标识符格式命名。最后，主题确认方法允许为之前经过身份验证的用户或机器发出请求和查询，而无需显式地将其标识为主题。本文档中定义的工件的使用不是ABFAB独有的。它们可以应用于任何身份验证、授权和计费（AAA）场景，例如网络访问控制。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7833.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7833.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. Conventions .....................................................5
3. RADIUS SAML Attributes ..........................................5
3.1. SAML-Assertion Attribute ...................................6
3.2. SAML-Protocol Attribute ....................................7
4. SAML RADIUS Binding .............................................8
4.1. Required Information .......................................8
4.2. Operation ..................................................8
4.3. Processing of Names ........................................9
4.3.1. AAA Names ..........................................10
4.3.2. SAML Names .........................................10
4.3.3. Mapping of AAA Names in SAML Metadata ..............11
4.3.4. Example of SAML Metadata That Includes AAA Names ...13
4.4. Use of XML Signatures .....................................14
4.5. Metadata Considerations ...................................14
5. Network Access Identifier Name Identifier Format ...............14
6. RADIUS State Confirmation Method Identifiers ...................15
7. ABFAB Authentication Profile ...................................15
7.1. Required Information ......................................15
7.2. Profile Overview ..........................................16
7.3. Profile Description .......................................18
7.3.1. Client Request to Relying Party ....................18
7.3.2. Relying Party Issues <samlp:AuthnRequest>
to Identity Provider ...............................18
7.3.3. Identity Provider Identifies Client ................18
7.3.4. Identity Provider Issues <samlp:Response>
to Relying Party ...................................19
7.3.5. Relying Party Grants or Denies Access to Client ....19
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. Conventions .....................................................5
3. RADIUS SAML Attributes ..........................................5
3.1. SAML-Assertion Attribute ...................................6
3.2. SAML-Protocol Attribute ....................................7
4. SAML RADIUS Binding .............................................8
4.1. Required Information .......................................8
4.2. Operation ..................................................8
4.3. Processing of Names ........................................9
4.3.1. AAA Names ..........................................10
4.3.2. SAML Names .........................................10
4.3.3. Mapping of AAA Names in SAML Metadata ..............11
4.3.4. Example of SAML Metadata That Includes AAA Names ...13
4.4. Use of XML Signatures .....................................14
4.5. Metadata Considerations ...................................14
5. Network Access Identifier Name Identifier Format ...............14
6. RADIUS State Confirmation Method Identifiers ...................15
7. ABFAB Authentication Profile ...................................15
7.1. Required Information ......................................15
7.2. Profile Overview ..........................................16
7.3. Profile Description .......................................18
7.3.1. Client Request to Relying Party ....................18
7.3.2. Relying Party Issues <samlp:AuthnRequest>
to Identity Provider ...............................18
7.3.3. Identity Provider Identifies Client ................18
7.3.4. Identity Provider Issues <samlp:Response>
to Relying Party ...................................19
7.3.5. Relying Party Grants or Denies Access to Client ....19
7.4. Use of Authentication Request Protocol ....................19
7.4.1. <samlp:AuthnRequest> Usage .........................19
7.4.2. <samlp:Response> Message Usage .....................20
7.4.3. <samlp:Response> Message Processing Rules ..........20
7.4.4. Unsolicited Responses ..............................21
7.4.5. Use of the SAML RADIUS Binding .....................21
7.4.6. Use of XML Signatures ..............................21
7.4.7. Metadata Considerations ............................21
8. ABFAB Assertion Query/Request Profile ..........................21
8.1. Required Information ......................................22
8.2. Profile Overview ..........................................22
8.3. Profile Description .......................................23
8.3.1. Differences from the SAML V2.0 Assertion
Query/Request Profile ..............................23
8.3.2. Use of the SAML RADIUS Binding .....................23
8.3.3. Use of XML Signatures ..............................24
8.3.4. Metadata Considerations ............................24
9. Privacy Considerations .........................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................25
11.1. RADIUS Attributes ........................................25
11.2. ABFAB Parameters .........................................26
11.3. Registration of the ABFAB URN Namespace ..................27
12. References ....................................................27
12.1. Normative References .....................................27
12.2. Informative References ...................................29
Appendix A. XML Schema ............................................30
Acknowledgments ...................................................32
Authors' Addresses ................................................32
7.4. Use of Authentication Request Protocol ....................19
7.4.1. <samlp:AuthnRequest> Usage .........................19
7.4.2. <samlp:Response> Message Usage .....................20
7.4.3. <samlp:Response> Message Processing Rules ..........20
7.4.4. Unsolicited Responses ..............................21
7.4.5. Use of the SAML RADIUS Binding .....................21
7.4.6. Use of XML Signatures ..............................21
7.4.7. Metadata Considerations ............................21
8. ABFAB Assertion Query/Request Profile ..........................21
8.1. Required Information ......................................22
8.2. Profile Overview ..........................................22
8.3. Profile Description .......................................23
8.3.1. Differences from the SAML V2.0 Assertion
Query/Request Profile ..............................23
8.3.2. Use of the SAML RADIUS Binding .....................23
8.3.3. Use of XML Signatures ..............................24
8.3.4. Metadata Considerations ............................24
9. Privacy Considerations .........................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................25
11.1. RADIUS Attributes ........................................25
11.2. ABFAB Parameters .........................................26
11.3. Registration of the ABFAB URN Namespace ..................27
12. References ....................................................27
12.1. Normative References .....................................27
12.2. Informative References ...................................29
Appendix A. XML Schema ............................................30
Acknowledgments ...................................................32
Authors' Addresses ................................................32
Within the ABFAB (Application Bridging for Federated Access Beyond web) architecture [RFC7831], it is often desirable to convey Security Assertion Markup Language (SAML) Assertions and protocol messages.
在ABFAB（用于web之外的联邦访问的应用程序桥接）体系结构[RFC7831]中，通常需要传递安全断言标记语言（SAML）断言和协议消息。
SAML typically only considers the use of HTTP-based transports, known as bindings [OASIS.saml-bindings-2.0-os], which are primarily intended for use with the SAML V2.0 web browser single sign-on profile [OASIS.saml-profiles-2.0-os]. However, the goal of ABFAB is to extend the applicability of federated identity beyond the web to other applications by building on the Authentication, Authorization, and Accounting (AAA) framework. Consequently, there exists a requirement for SAML to integrate with the AAA framework and with protocols such as RADIUS [RFC2865] and Diameter [RFC6733], in addition to HTTP.
SAML通常只考虑使用基于HTTP的传输，称为绑定[OASIS.SAML-bindings-2.0-os]，主要用于SAML V2.0 web浏览器单点登录配置文件[OASIS.SAML-profiles-2.0-os]。然而，ABFAB的目标是通过构建身份验证、授权和记帐（AAA）框架，将联合身份的适用性扩展到web以外的其他应用程序。因此，除了HTTP之外，SAML还需要与AAA框架以及RADIUS[RFC2865]和DIAMER[RFC6733]等协议集成。
In summary, this document specifies:
总之，本文件规定：
o Two RADIUS attributes to encapsulate SAML Assertions and protocol messages, respectively.
o 两个RADIUS属性分别封装SAML断言和协议消息。
o A SAML RADIUS binding that defines how SAML Assertions and protocol messages can be transported by RADIUS within a SAML exchange.
o 定义SAML断言和协议消息如何在SAML交换中通过RADIUS传输的SAML RADIUS绑定。
o A SAML name identifier format in the form of a Network Access Identifier.
o 网络访问标识符形式的SAML名称标识符格式。
o A profile of the SAML Authentication Request Protocol that uses the SAML RADIUS binding to effect SAML-based authentication and authorization.
o SAML身份验证请求协议的配置文件，使用SAML RADIUS绑定实现基于SAML的身份验证和授权。
o A profile of the SAML Assertion Query and Request Protocol that uses the SAML RADIUS binding to effect the query and request of SAML Assertions.
o SAML断言查询和请求协议的概要文件，它使用SAML RADIUS绑定影响SAML断言的查询和请求。
o Two SAML subject confirmation methods for indicating that a user or machine client is the subject of an assertion.
o 两种SAML主题确认方法，用于指示用户或机器客户端是断言的主题。
This document adheres to the guidelines stipulated by [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for defining new SAML bindings and profiles, respectively, and other conventions applied formally or otherwise within SAML. In particular, this document provides a "Required Information" section for the binding (Section 4.1) and profiles (Sections 7.1 and 8.1) that enumerate:
本文件遵循[OASIS.saml-bindings-2.0-os]和[OASIS.saml-profiles-2.0-os]分别规定的定义新saml绑定和配置文件的指南，以及正式或以其他方式在saml中应用的其他约定。特别是，本文件为绑定（第4.1节）和概要（第7.1节和第8.1节）提供了“所需信息”部分，其中列举了：
o A URI that uniquely identifies the protocol binding or profile.
o 唯一标识协议绑定或配置文件的URI。
o Postal or electronic contact information for the author.
o 作者的邮政或电子联系信息。
o A reference to previously defined bindings or profiles that the new binding updates or obsoletes.
o 对新绑定更新或废弃的先前定义的绑定或概要文件的引用。
o In the case of a profile, any SAML confirmation method identifiers defined and/or utilized by the profile.
o 在概要文件的情况下，概要文件定义和/或使用的任何SAML确认方法标识符。
This document uses terminology from a number of related standards that tend to adopt different terms for similar or identical concepts. In general, this document uses, when possible, the ABFAB term for the entity, as described in [RFC7831]. For reference, we include the following table, which maps the different terms into a single view. (In this document, "NAS" refers to a network access server, and "AS" refers to an authentication server.)
本文件使用了许多相关标准中的术语，这些标准倾向于对类似或相同的概念采用不同的术语。一般来说，如[RFC7831]所述，本文件在可能的情况下使用实体的ABFAB术语。为了便于参考，我们提供了下表，该表将不同的术语映射到单个视图中。（在本文档中，“NAS”指网络访问服务器，“AS”指身份验证服务器。）
+----------+-----------+------------------+-------------------+
| Protocol | Client | Relying Party | Identity Provider |
+----------+-----------+------------------+-------------------+
| ABFAB | Client | Relying Party | Identity Provider |
| | | | |
| SAML | Subject | Service Provider | Identity Provider |
| | Principal | Requester | Responder |
| | | Consumer | Issuer |
| | | | |
| RADIUS | User | NAS | AS |
| | | RADIUS client | RADIUS server |
+----------+-----------+------------------+-------------------+
+----------+-----------+------------------+-------------------+
| Protocol | Client | Relying Party | Identity Provider |
+----------+-----------+------------------+-------------------+
| ABFAB | Client | Relying Party | Identity Provider |
| | | | |
| SAML | Subject | Service Provider | Identity Provider |
| | Principal | Requester | Responder |
| | | Consumer | Issuer |
| | | | |
| RADIUS | User | NAS | AS |
| | | RADIUS client | RADIUS server |
+----------+-----------+------------------+-------------------+
Table 1: Terminology
表1：术语
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The SAML RADIUS binding defined in Section 4 of this document uses two attributes to convey SAML Assertions and protocol messages [OASIS.saml-core-2.0-os]. Owing to the typical size of these structures, these attributes use the "Long Extended Type" format [RFC6929] to encapsulate their data. RADIUS entities MUST NOT include both attributes in the same RADIUS message, as they represent exclusive alternatives to convey SAML information.
本文档第4节中定义的SAML RADIUS绑定使用两个属性来传递SAML断言和协议消息[OASIS.SAML-core-2.0-os]。由于这些结构的典型大小，这些属性使用“长扩展类型”格式[RFC6929]来封装其数据。RADIUS实体不能在同一个RADIUS消息中同时包含这两个属性，因为它们代表传递SAML信息的唯一备选方案。
This attribute is used to encode a SAML Assertion. Figure 1 represents the format of this attribute.
此属性用于对SAML断言进行编码。图1显示了该属性的格式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SAML-Assertion Format
图1:SAML断言格式
Type
类型
245
245
Length
长
>= 5
>= 5
Extended-Type
扩展型
1
1.
M (More)
M（更多）
As described in [RFC6929].
如[RFC6929]所述。
Reserved
含蓄的
As described in [RFC6929].
如[RFC6929]所述。
Value
价值
One or more octets encoding a SAML Assertion.
编码SAML断言的一个或多个八位字节。
This attribute is used to encode a SAML protocol message. Figure 2 represents the format of this attribute.
此属性用于对SAML协议消息进行编码。图2显示了该属性的格式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SAML-Protocol Format
图2:SAML协议格式
Type
类型
245
245
Length
长
>= 5
>= 5
Extended-Type
扩展型
2
2.
M (More)
M（更多）
As described in [RFC6929].
如[RFC6929]所述。
Reserved
含蓄的
As described in [RFC6929].
如[RFC6929]所述。
Value
价值
One or more octets encoding a SAML protocol message.
编码SAML协议消息的一个或多个八位字节。
The SAML RADIUS binding defines how RADIUS [RFC2865] can be used to enable a RADIUS client and server to exchange SAML Assertions and protocol messages.
SAML RADIUS绑定定义了如何使用RADIUS[RFC2865]使RADIUS客户端和服务器能够交换SAML断言和协议消息。
Identification: urn:ietf:params:abfab:bindings:radius
Identification: urn:ietf:params:abfab:bindings:radius
Contact information: iesg@ietf.org
联系方式：iesg@ietf.org
Updates: None.
更新：无。
In this specification, the Relying Party (RP) MUST trust any statement in the SAML messages from the Identity Provider (IdP) in the same way that it trusts information contained in RADIUS attributes. These entities MUST trust the RADIUS infrastructure to provide integrity of the SAML messages.
在本规范中，依赖方（RP）必须以信任RADIUS属性中包含的信息的方式信任来自身份提供者（IdP）的SAML消息中的任何语句。这些实体必须信任RADIUS基础设施以提供SAML消息的完整性。
Hence, it is REQUIRED that the RADIUS exchange be protected using Transport Layer Security (TLS) encryption for RADIUS [RFC6614] to provide confidentiality and integrity protection, unless alternative methods to ensure them are used, such as IPsec tunnels or a sufficiently secure internal network.
因此，要求使用RADIUS传输层安全（TLS）加密[RFC6614]来保护RADIUS交换，以提供机密性和完整性保护，除非使用其他方法来确保它们，如IPsec隧道或足够安全的内部网络。
Implementations of this profile can take advantage of mechanisms to permit the transport of longer SAML messages over RADIUS transports, such as the support of fragmentation of RADIUS packets [RFC7499] or larger packets for RADIUS over TCP [RADIUS-Large-Pkts].
此配置文件的实现可以利用机制来允许通过RADIUS传输传输更长的SAML消息，例如支持RADIUS数据包的碎片[RFC7499]或通过TCP传输RADIUS的更大数据包[RADIUS Large PKT]。
There are two system models for the use of SAML over RADIUS. The first is a request-response model, using the RADIUS SAML-Protocol attribute defined in Section 3 to encapsulate the SAML protocol messages.
在半径上使用SAML有两种系统模型。第一个是请求-响应模型，使用第3节中定义的RADIUS SAML协议属性来封装SAML协议消息。
1. The RADIUS client, acting as an RP, transmits a SAML request element within a RADIUS Access-Request message. This message MUST include a single instance of the RADIUS User-Name attribute whose value MUST conform to the Network Access Identifier [RFC7542] scheme. The RP MUST NOT include more than one SAML request element.
1. RADIUS客户端充当RP，在RADIUS访问请求消息中传输SAML请求元素。此消息必须包含RADIUS用户名属性的单个实例，其值必须符合网络访问标识符[RFC7542]方案。RP不得包含多个SAML请求元素。
2. The RADIUS server, acting as an IdP, returns a SAML protocol message within a RADIUS Access-Accept or Access-Reject message. These messages necessarily conclude a RADIUS exchange, and therefore this is the only opportunity for the IdP to send a response in the context of this exchange. The IdP MUST NOT include more than one SAML response. An IdP that refuses to perform a message exchange with the RP can silently discard the SAML request (this could subsequently be followed by a RADIUS Access-Reject, as the same conditions that cause the IdP to discard the SAML request may also cause the RADIUS server to fail to authenticate).
2. RADIUS服务器充当IdP，在RADIUS访问接受或访问拒绝消息中返回SAML协议消息。这些消息必然会结束RADIUS交换，因此这是IdP在此交换上下文中发送响应的唯一机会。IdP不得包含多个SAML响应。拒绝与RP进行消息交换的IdP可以静默地放弃SAML请求（随后可能会出现RADIUS访问拒绝，因为导致IdP放弃SAML请求的相同条件也可能导致RADIUS服务器无法进行身份验证）。
The second system model permits a RADIUS server acting as an IdP to use the RADIUS SAML-Assertion attribute defined in Section 3 to encapsulate an unsolicited SAML Assertion. This attribute MUST be included in a RADIUS Access-Accept message. When included, the attribute MUST contain a single SAML Assertion.
第二个系统模型允许充当IdP的RADIUS服务器使用第3节中定义的RADIUS SAML断言属性封装未经请求的SAML断言。此属性必须包含在RADIUS访问接受消息中。包含时，该属性必须包含单个SAML断言。
RADIUS servers MUST NOT include both the SAML-Protocol and the SAML-Assertion attribute in the same RADIUS message. If an IdP is producing a response to a SAML request, then the first system model is used. An IdP MAY ignore a SAML request and send an unsolicited assertion using the second system model (that is, using the RADIUS SAML-Assertion attribute).
RADIUS服务器不得在同一RADIUS消息中同时包含SAML协议和SAML断言属性。如果IdP正在生成对SAML请求的响应，则使用第一个系统模型。IdP可以忽略SAML请求，并使用第二个系统模型（即使用RADIUS SAML断言属性）发送未经请求的断言。
In either system model, IdPs SHOULD return a RADIUS State attribute as part of the Access-Accept message so that future SAML queries or requests can be run against the same context of an authentication exchange.
在任何一种系统模型中，IDP都应该返回RADIUS State属性作为Access Accept消息的一部分，以便将来的SAML查询或请求可以在身份验证交换的相同上下文中运行。
This binding is intended to be composed with other uses of RADIUS, such as network access. Therefore, other arbitrary RADIUS attributes MAY be used in either the request or response.
此绑定旨在与RADIUS的其他用途（如网络访问）结合使用。因此，可以在请求或响应中使用其他任意RADIUS属性。
In the case of a SAML processing error, the RADIUS server MAY include a SAML response message with an appropriate value for the <samlp:Status> element within the Access-Accept or Access-Reject packet to notify the client. Alternatively, the RADIUS server can respond without a SAML-Protocol attribute.
在SAML处理错误的情况下，RADIUS服务器可能会在Access Accept或Access Reject数据包中包含一条SAML响应消息，该消息具有<samlp:Status>元素的适当值，以通知客户端。或者，RADIUS服务器可以在没有SAML协议属性的情况下响应。
SAML entities using profiles making use of this binding will typically possess both the SAML and AAA names of their correspondents. Frequently, these entities will need to apply policies using these names -- for example, when deciding to release attributes. Often, these policies will be security-sensitive, and so it is important that policy is applied on these names consistently.
使用使用此绑定的概要文件的SAML实体通常将同时拥有其对应者的SAML和AAA名称。通常，这些实体需要使用这些名称应用策略——例如，在决定发布属性时。通常，这些策略会对安全性敏感，因此对这些名称应用一致的策略非常重要。
These rules relate to the processing of AAA names by SAML entities using profiles making use of this binding.
这些规则涉及SAML实体使用使用此绑定的概要文件处理AAA名称。
o IdPs SHOULD apply policy based on the RP's identity associated with the RADIUS Access-Request.
o IDP应根据RP与RADIUS访问请求相关的身份应用策略。
o RPs SHOULD apply policy based on the NAI realm associated with the RADIUS Access-Accept.
o RPs应基于与RADIUS访问接受关联的NAI领域应用策略。
These rules relate to the processing of SAML names by SAML entities using profiles making use of this binding.
这些规则涉及SAML实体使用使用此绑定的概要文件处理SAML名称。
IdPs MAY apply policy based on the RP's SAML entityID. In such cases, at least one of the following methods is required in order to establish a relationship between the SAML name and the AAA name of the RP:
IDP可以基于RP的SAML entityID应用策略。在这种情况下，为了在SAML名称和RP的AAA名称之间建立关系，至少需要以下方法之一：
o RADIUS client identity in trusted SAML metadata (as described in Section 4.3.3).
o 可信SAML元数据中的RADIUS客户端标识（如第4.3.3节所述）。
o RADIUS client identity in trusted digitally signed SAML request.
o 受信任的数字签名SAML请求中的RADIUS客户端标识。
A digitally signed SAML request without the RADIUS client identity is not sufficient, since a malicious RADIUS entity can observe a SAML message and include it in a different RADIUS message without the consent of the issuer of that SAML message. If an IdP were to process the SAML message without confirming that it applied to the RADIUS message, inappropriate policy would be used.
没有RADIUS客户端标识的数字签名SAML请求是不够的，因为恶意RADIUS实体可以观察SAML消息并将其包含在不同的RADIUS消息中，而无需该SAML消息的颁发者的同意。如果IdP在未确认SAML消息是否适用于RADIUS消息的情况下处理SAML消息，则将使用不适当的策略。
RPs MAY apply policy based on the SAML issuer's entityID. In such cases, at least one of the following methods is required in order to establish a relationship between the SAML name and the AAA name of the IdP:
RPs可以基于SAML颁发者的entityID应用策略。在这种情况下，为了在SAML名称和IdP的AAA名称之间建立关系，需要以下方法中的至少一种：
o RADIUS realm in trusted SAML metadata (as described in Section 4.3.3).
o 可信SAML元数据中的RADIUS域（如第4.3.3节所述）。
o RADIUS realm in trusted digitally signed SAML response or assertion.
o 受信任的数字签名SAML响应或断言中的RADIUS域。
A digitally signed SAML response alone is not sufficient, for the same reasons as those described above for SAML requests.
仅数字签名SAML响应是不够的，原因与上述SAML请求相同。
This section defines extensions to the SAML metadata schema [OASIS.saml-metadata-2.0-os] that are required in order to represent AAA names associated with a particular <EntityDescriptor> element.
本节定义了SAML元数据模式[OASIS.SAML-metadata-2.0-os]的扩展，这些扩展是表示与特定<EntityDescriptor>元素关联的AAA名称所必需的。
In SAML metadata, a single entity may act in many different roles in the support of multiple profiles. This document defines two new roles: RADIUS IdP and RADIUS RP, requiring the declaration of two new subtypes of RoleDescriptorType: RADIUSIDPDescriptorType and RADIUSRPDescriptorType. These subtypes contain the additional elements required to represent AAA names for IdP and RP entities, respectively.
在SAML元数据中，单个实体可以在支持多个概要文件的过程中扮演许多不同的角色。本文档定义了两个新角色：RADIUS IdP和RADIUS RP，需要声明RoleDescriptorType的两个新子类型：RadiusDPDescriptorType和RADIUSRPDescriptorType。这些子类型包含分别表示IdP和RP实体的AAA名称所需的附加元素。
The RADIUSIDPDescriptorType complex type extends RoleDescriptorType with elements common to IdPs that support RADIUS. It contains the following additional elements:
RADIUSIDPDescriptorType复杂类型使用支持RADIUS的IDP通用元素扩展RoleDescriptorType。它包含以下附加元素：
<RADIUSIDPService> [Zero or More] Zero or more elements of type EndpointType that describe RADIUS endpoints that are associated with the entity.
<RadiusDPService>[Zero或More]EndpointType类型的零个或多个元素，用于描述与实体关联的RADIUS端点。
<RADIUSRealm> [Zero or More] Zero or more elements of type string that represent the acceptable values of the RADIUS realm associated with the entity, obtained from the realm part of the RADIUS User-Name attribute.
<RADIUSRealm>[Zero或More]字符串类型的零个或多个元素，表示与实体关联的RADIUS领域的可接受值，从RADIUS用户名属性的领域部分获得。
The following schema fragment defines the RADIUSIDPDescriptorType complex type:
以下架构片段定义了RadiusDPDescriptorType复杂类型：
<complexType name="RADIUSIDPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="abfab:RADIUSIDPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="abfab:RADIUSRealm"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSIDPService" type="md:EndpointType"/>
<element name="RADIUSRealm" type="string"/>
<complexType name="RADIUSIDPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="abfab:RADIUSIDPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="abfab:RADIUSRealm"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSIDPService" type="md:EndpointType"/>
<element name="RADIUSRealm" type="string"/>
Figure 3: RADIUSIDPDescriptorType Schema
图3:RadiusidDescriptorType模式
The RADIUSRPDescriptorType complex type extends RoleDescriptorType with elements common to RPs that support RADIUS. It contains the following additional elements:
RADIUSRPDescriptorType复杂类型使用支持RADIUS的RPs通用的元素扩展RoleDescriptorType。它包含以下附加元素：
<RADIUSRPService> [Zero or More] Zero or more elements of type EndpointType that describe RADIUS endpoints that are associated with the entity.
<RADIUSRPService>[Zero或More]EndpointType类型的零个或多个元素，用于描述与实体关联的RADIUS端点。
<RADIUSNasIpAddress> [Zero or More] Zero or more elements of type string that represent the acceptable values of the RADIUS NAS-IP-Address or NAS-IPv6-Address attributes associated with the entity.
<RadiunSiapAddress>[Zero或More]表示与实体关联的RADIUS NAS IP地址或NAS-IPv6-Address属性的可接受值的字符串类型的零个或多个元素。
<RADIUSNasIdentifier> [Zero or More] Zero or more elements of type string that represent the acceptable values of the RADIUS NAS-Identifier attribute associated with the entity.
<RADIUNSIAIdentifier>[Zero或More]表示与实体关联的RADIUS NAS标识符属性的可接受值的字符串类型的零个或多个元素。
<RADIUSGssEapName> [Zero or More] Zero or more elements of type string that represent the acceptable values of the GSS-API Mechanism for the Extensible Authentication Protocol (GSS-EAP) acceptor name associated with the entity. The format for this name is described in Section 3.1 of [RFC7055], while Section 3.4 of [RFC7055] describes how that name is decomposed and transported using RADIUS attributes.
<RADIUSGssEapName>[Zero或More]表示与实体关联的可扩展身份验证协议（GSS-EAP）接受方名称的GSS-API机制的可接受值的字符串类型的零个或多个元素。[RFC7055]第3.1节描述了该名称的格式，而[RFC7055]第3.4节描述了如何使用RADIUS属性分解和传输该名称。
The following schema fragment defines the RADIUSRPDescriptorType complex type:
以下架构片段定义了RADIUSRPDescriptorType复杂类型：
<complexType name="RADIUSRPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="md:RADIUSRPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIpAddress"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIdentifier"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSGssEapName"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSRPService" type="md:EndpointType"/>
<element name="RADIUSNasIpAddress" type="string"/>
<element name="RADIUSNasIdentifier" type="string"/>
<element name="RADIUSGssEapName" type="string"/>
<complexType name="RADIUSRPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="md:RADIUSRPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIpAddress"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIdentifier"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSGssEapName"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSRPService" type="md:EndpointType"/>
<element name="RADIUSNasIpAddress" type="string"/>
<element name="RADIUSNasIdentifier" type="string"/>
<element name="RADIUSGssEapName" type="string"/>
Figure 4: RADIUSRPDescriptorType Schema
图4:RADIUSRPDescriptorType模式
Figures 5 and 6 illustrate examples of metadata that includes AAA names for an IdP and an RP, respectively. The IdP's SAML name is "https://IdentityProvider.com/", whereas its RADIUS realm is "idp.com". The RP's SAML name is "https://RelyingParty.com/SAML", being its GSS-EAP acceptor name "nfs/fileserver.rp.com@RP.COM".
图5和图6分别展示了元数据示例，其中包括IdP和RP的AAA名称。IdP的SAML名称为“https://IdentityProvider.com/，而其RADIUS领域为“idp.com”。RP的SAML名称为“https://RelyingParty.com/SAML，作为其GSS-EAP接受程序名称“nfs/fileserver.rp。com@RP.COM".
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:abfab="urn:ietf:params:xml:ns:abfab"
entityID="https://IdentityProvider.com/SAML">
<RoleDescriptor
xsi:type="abfab:RADIUSIDPDescriptorType"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<RADIUSRealm>idp.com</RADIUSRealm>
</RoleDescriptor>
</EntityDescriptor>
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:abfab="urn:ietf:params:xml:ns:abfab"
entityID="https://IdentityProvider.com/SAML">
<RoleDescriptor
xsi:type="abfab:RADIUSIDPDescriptorType"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<RADIUSRealm>idp.com</RADIUSRealm>
</RoleDescriptor>
</EntityDescriptor>
Figure 5: Metadata for the IdP
图5:IdP的元数据
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:abfab="urn:ietf:params:xml:ns:abfab"
entityID="https://RelyingParty.com/SAML">
<RoleDescriptor
xsi:type="abfab:RADIUSRPDescriptorType"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<RADIUSGssEapName>nfs/fileserver.rp.com@RP.COM</RADIUSGssEapName>
</RoleDescriptor>
</EntityDescriptor>
<EntityDescriptor
xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:abfab="urn:ietf:params:xml:ns:abfab"
entityID="https://RelyingParty.com/SAML">
<RoleDescriptor
xsi:type="abfab:RADIUSRPDescriptorType"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<RADIUSGssEapName>nfs/fileserver.rp.com@RP.COM</RADIUSGssEapName>
</RoleDescriptor>
</EntityDescriptor>
Figure 6: Metadata for the RP
图6:RP的元数据
This binding calls for the use of SAML elements that support XML signatures. To promote interoperability, implementations of this binding MUST support a default configuration that does not require the use of XML signatures. Implementations MAY choose to use XML signatures.
此绑定要求使用支持XML签名的SAML元素。为了促进互操作性，此绑定的实现必须支持不需要使用XML签名的默认配置。实现可以选择使用XML签名。
This binding, and the profiles, are mostly intended to be used without metadata. In this usage, RADIUS infrastructure is used to provide integrity and naming of the SAML messages and assertions. RADIUS configuration is used to provide policy, including which attributes are accepted from an RP and which attributes are sent by an IdP.
此绑定和概要文件主要用于不使用元数据的情况。在这种用法中，RADIUS基础设施用于提供SAML消息和断言的完整性和命名。RADIUS配置用于提供策略，包括从RP接受哪些属性以及由IdP发送哪些属性。
Nevertheless, if metadata is used, the roles described in Section 4.3.3 MUST be present.
然而，如果使用元数据，则必须存在第4.3.3节中描述的角色。
URI: urn:ietf:params:abfab:nameid-format:nai
URI: urn:ietf:params:abfab:nameid-format:nai
Indicates that the content of the element is in the form of a Network Access Identifier (NAI) using the syntax described by [RFC7542].
指示元素的内容采用[RFC7542]所述语法的网络访问标识符（NAI）形式。
URI: urn:ietf:params:abfab:cm:user
URI: urn:ietf:params:abfab:cm:user
URI: urn:ietf:params:abfab:cm:machine
URI: urn:ietf:params:abfab:cm:machine
Indicates that the subject is the system entity (either the user or machine) authenticated by a previously transmitted RADIUS Access-Accept message, as identified by the value of that RADIUS message's State attribute.
指示主题是由先前传输的RADIUS访问接受消息（由RADIUS消息的状态属性值标识）验证的系统实体（用户或计算机）。
In the scenario supported by the ABFAB Authentication Profile, a client controlling a User Agent requests access to an RP. The RP uses RADIUS to authenticate the client. In particular, the RP, acting as a RADIUS client, attempts to validate the client's credentials against a RADIUS server acting as the client's IdP. If the IdP successfully authenticates the client, it produces an authentication assertion that is consumed by the RP. This assertion MAY include a name identifier that can be used between the RP and the IdP to refer to the client.
在ABFAB身份验证配置文件支持的场景中，控制用户代理的客户端请求访问RP。RP使用RADIUS对客户端进行身份验证。特别是，RP作为RADIUS客户端，尝试根据作为客户端IdP的RADIUS服务器验证客户端的凭据。如果IdP成功对客户端进行身份验证，它将生成一个由RP使用的身份验证断言。该断言可能包括一个名称标识符，可在RP和IdP之间用于引用客户端。
Identification: urn:ietf:params:abfab:profiles:authentication
Identification: urn:ietf:params:abfab:profiles:authentication
Contact information: iesg@ietf.org
联系方式：iesg@ietf.org
SAML confirmation method identifiers: The SAML V2.0 "RADIUS State" confirmation method identifiers -- either urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine -- are used by this profile.
SAML确认方法标识符：SAML V2.0“RADIUS State”确认方法标识符——urn:ietf:params:abfab:cm:user或urn:ietf:params:abfab:cm:machine——由该配置文件使用。
Updates: None.
更新：无。
To implement this scenario, this profile of the SAML Authentication Request Protocol MUST be used in conjunction with the SAML RADIUS binding defined in Section 4.
要实现此场景，SAML身份验证请求协议的此配置文件必须与第4节中定义的SAML RADIUS绑定结合使用。
This profile is based on the SAML V2.0 web browser single sign-on profile [OASIS.saml-profiles-2.0-os]. There are some important differences; specifically:
此配置文件基于SAML V2.0 web浏览器单点登录配置文件[OASIS.SAML-profiles-2.0-os]。有一些重要的区别；明确地：
Authentication: This profile does not require the use of any particular authentication method. The ABFAB architecture does require the use of the Extensible Authentication Protocol (EAP) [RFC3579], but this specification may be used in other non-ABFAB scenarios.
身份验证：此配置文件不需要使用任何特定的身份验证方法。ABFAB体系结构确实需要使用可扩展身份验证协议（EAP）[RFC3579]，但本规范可用于其他非ABFAB场景。
Bindings: This profile does not use HTTP-based bindings. Instead, all SAML protocol messages are transported using the SAML RADIUS binding defined in Section 4. This is intended to reduce the number of bindings that implementations must support to be interoperable.
绑定：此配置文件不使用基于HTTP的绑定。相反，所有SAML协议消息都使用第4节中定义的SAML RADIUS绑定进行传输。这是为了减少实现必须支持的可互操作绑定的数量。
Requests: The profile does not permit the RP to name the <saml:Subject> of the <samlp:AuthnRequest>. This is intended to simplify implementation and interoperability.
请求：配置文件不允许RP命名<samlp:AuthnRequest>的<saml:Subject>。这旨在简化实现和互操作性。
Responses: The profile only permits the IdP to return a single SAML message or assertion that MUST contain exactly one authentication statement. Other statements may be included within this assertion at the discretion of the IdP. This is intended to simplify implementation and interoperability.
响应：配置文件只允许IdP返回一条SAML消息或断言，该消息或断言必须只包含一条身份验证语句。IdP可自行决定在本声明中包含其他声明。这旨在简化实现和互操作性。
Figure 7 below illustrates the flow of messages within this profile.
下面的图7说明了此概要文件中的消息流。
Client Relying Party Identity Provider
| | |
| (1) | |
| - - - - - - - - - > | |
| | |
| | (2) |
| | - - - - - - - - - - - - > |
| | |
| (3) | |
| < - - - - - - - - - |- - - - - - - - - - - - - >|
| | |
| | (4) |
| | < - - - - - - - - - - - - |
| | |
| (5) | |
| < - - - - - - - - - | |
| | |
V V V
Client Relying Party Identity Provider
| | |
| (1) | |
| - - - - - - - - - > | |
| | |
| | (2) |
| | - - - - - - - - - - - - > |
| | |
| (3) | |
| < - - - - - - - - - |- - - - - - - - - - - - - >|
| | |
| | (4) |
| | < - - - - - - - - - - - - |
| | |
| (5) | |
| < - - - - - - - - - | |
| | |
V V V
Figure 7: Flow of Messages
图7：消息流
The following steps are described by the profile. Within an individual step, there may be one or more actual message exchanges.
配置文件描述了以下步骤。在单个步骤中，可能有一个或多个实际的消息交换。
1. Client request to RP (Section 7.3.1): In step 1, the client, via a User Agent, makes a request for a secured resource at the RP. The RP determines that no security context for the client exists and initiates the authentication process.
1. 客户端对RP的请求（第7.3.1节）：在步骤1中，客户端通过用户代理请求RP的安全资源。RP确定客户端不存在安全上下文，并启动身份验证过程。
2. RP issues <samlp:AuthnRequest> to IdP (Section 7.3.2). In step 2, the RP may optionally issue a <samlp:AuthnRequest> message to be delivered to the IdP using the SAML-Protocol RADIUS attribute.
2. RP向IdP发布<samlp:AuthnRequest>（第7.3.2节）。在步骤2中，RP可以选择性地发出<samlp:AuthnRequest>消息，以使用SAML协议RADIUS属性传递给IdP。
3. IdP identifies client (Section 7.3.3). In step 3, the client is authenticated and identified by the IdP, while honoring any requirements imposed by the RP in the <samlp:AuthnRequest> message if provided.
3. IdP识别客户（第7.3.3节）。在步骤3中，客户机由IdP进行身份验证和识别，同时遵守RP在<samlp:AuthnRequest>消息（如果提供）中强加的任何要求。
4. IdP issues <samlp:Response> to RP (Section 7.3.4). In step 4, the IdP issues a <samlp:Response> message to the RP using the SAML RADIUS binding. The response either indicates an error or includes a SAML authentication statement in exactly one SAML Assertion. If the RP did not send a <samlp:AuthnRequest>, the IdP issues an unsolicited <samlp:Assertion>, as described in Section 7.4.4.
4. 国内流离失所者问题<samlp:Response>（第7.3.4节）。在步骤4中，IdP使用SAML RADIUS绑定向RP发出<samlp:Response>消息。响应要么指示错误，要么仅在一个SAML断言中包含SAML身份验证语句。如果RP未发送<samlp:AuthnRequest>，则IdP会发出未经请求的<samlp:Assertion>，如第7.4.4节所述。
5. RP grants or denies access to client (Section 7.3.5). In step 5, having received the response from the IdP, the RP can respond to the client with its own error, or can establish its own security context for the client and return the requested resource.
5. RP授予或拒绝访问客户（第7.3.5节）。在步骤5中，在接收到来自IdP的响应之后，RP可以用自己的错误响应客户端，或者可以为客户端建立自己的安全上下文并返回请求的资源。
The ABFAB Authentication Profile is a profile of the SAML V2.0 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where both specifications conflict, the ABFAB Authentication Profile takes precedence.
ABFAB身份验证配置文件是SAML V2.0身份验证请求协议[OASIS.SAML-core-2.0-os]的配置文件。当两个规范冲突时，ABFAB身份验证配置文件优先。
The profile is initiated by an arbitrary client request to the RP. There are no restrictions on the form of the request. The RP is free to use any means it wishes to associate the subsequent interactions with the original request. The RP, acting as a RADIUS client, attempts to authenticate the client.
配置文件由向RP发出的任意客户端请求发起。请求的形式没有限制。RP可以自由使用其希望将后续交互与原始请求关联的任何方式。RP充当RADIUS客户端，尝试对客户端进行身份验证。
The RP uses RADIUS to communicate with the client's IdP. The RP MAY include a <samlp:AuthnRequest> within this RADIUS Access-Request message using the SAML-Protocol RADIUS attribute. The "next hop" destination MAY be the IdP or, alternatively, an intermediate RADIUS proxy.
RP使用RADIUS与客户的IdP通信。RP可以使用SAML协议RADIUS属性在此RADIUS访问请求消息中包含<samlp:AuthnRequest>。“下一跳”目的地可以是IdP，或者，也可以是中间半径代理。
Profile-specific rules for the contents of the <samlp:AuthnRequest> element are given in Section 7.4.1.
第7.4.1节给出了<samlp:AuthnRequest>元素内容的配置文件特定规则。
The IdP MUST establish the identity of the client using a RADIUS authentication method, or else it will return an error. If the ForceAuthn attribute in the <samlp:AuthnRequest> element (if sent by the RP) is present and true, the IdP MUST freshly establish this identity rather than relying on any existing session state it may have with the client (for example, TLS state that may be used for session resumption). Otherwise, and in all other respects, the IdP may use any method to authenticate the client, subject to the constraints called out in the <samlp:AuthnRequest> message.
IdP必须使用RADIUS身份验证方法建立客户端的身份，否则将返回错误。如果<samlp:AuthnRequest>元素中的ForceAuthn属性（如果由RP发送）存在且为true，则IdP必须重新建立此标识，而不是依赖其与客户端之间可能存在的任何现有会话状态（例如，可用于会话恢复的TLS状态）。否则，在所有其他方面，IdP可以使用任何方法来认证客户机，这取决于<samlp:AuthnRequest>消息中调用的约束。
The IdP MUST conclude the authentication in a manner consistent with the RADIUS authentication result. The IdP MAY issue a <samlp:Response> message to the RP that is consistent with the authentication result, as described in [OASIS.saml-core-2.0-os]. This SAML response is delivered to the RP using the SAML RADIUS binding described in Section 4.
IdP必须以与RADIUS认证结果一致的方式结束认证。IdP可向RP发出与认证结果一致的<samlp:Response>消息，如[OASIS.saml-core-2.0-os]所述。使用第4节中描述的SAML半径绑定将SAML响应传递给RP。
Profile-specific rules regarding the contents of the <samlp:Response> element are given in Section 7.4.2.
第7.4.2节给出了有关<samlp:Response>元素内容的配置文件特定规则。
If a <samlp:Response> message is issued by the IdP, the RP MUST process that message and any enclosed assertion elements as described in [OASIS.saml-core-2.0-os]. Any subsequent use of the assertion elements is at the discretion of the RP, subject to any restrictions contained within the assertions themselves or from any previously established out-of-band policy that governs the interaction between the IdP and the RP.
如果IdP发出<samlp:Response>消息，RP必须按照[OASIS.saml-core-2.0-os]中所述处理该消息和任何附带的断言元素。断言元素的任何后续使用由RP自行决定，受断言本身中包含的任何限制或任何先前制定的管理IdP和RP之间交互的带外政策的限制。
This profile is based on the Authentication Request Protocol defined in [OASIS.saml-core-2.0-os]. In the nomenclature of actors enumerated in Section 3.4 of that document, the RP is the requester, the User Agent is the attesting entity, and the client is the subject.
此配置文件基于[OASIS.saml-core-2.0-os]中定义的身份验证请求协议。在该文件第3.4节列举的参与者名称中，RP是请求者，用户代理是认证实体，客户是主体。
The RP MUST NOT include a <saml:Subject> element in the request. The authenticated RADIUS identity identifies the client to the IdP.
RP不得在请求中包含<saml:Subject>元素。通过身份验证的RADIUS标识向IdP标识客户端。
An RP MAY include any message content described in Section 3.4.1 of [OASIS.saml-core-2.0-os]. All processing rules are as defined in [OASIS.saml-core-2.0-os].
RP可包括[OASIS.saml-core-2.0-os]第3.4.1节中所述的任何消息内容。所有处理规则都在[OASIS.saml-core-2.0-os]中定义。
If the RP wishes to permit the IdP to establish a new identifier for the client if none exists, it MUST include a <saml:NameIDPolicy> element with the AllowCreate attribute set to "true". Otherwise, only a client for whom the IdP has previously established an identifier usable by the RP can be authenticated successfully.
如果RP希望允许IdP为客户端建立新标识符（如果不存在），则必须包含AllowCreate属性设置为“true”的<saml:NameIDPolicy>元素。否则，只有IdP先前为其建立了可由RP使用的标识符的客户端才能被成功认证。
The <samlp:AuthnRequest> message MAY be signed. Authentication and integrity are also provided by the SAML RADIUS binding.
<samlp:AuthnRequest>消息可能已签名。SAML RADIUS绑定还提供身份验证和完整性。
If the IdP cannot or will not satisfy the request, it MUST respond with a <samlp:Response> message containing an appropriate error status code or codes and/or respond with a RADIUS Access-Reject message.
如果IdP不能或不会满足请求，则必须使用包含适当错误状态代码的<samlp:Response>消息进行响应，和/或使用RADIUS访问拒绝消息进行响应。
If the IdP wishes to return an error, it MUST NOT include any assertions in the <samlp:Response> message. Otherwise, if the request is successful (or if the response is not associated with a request), the <samlp:Response> element is subject to the following constraints:
如果IdP希望返回错误，则它不得在<samlp:Response>消息中包含任何断言。否则，如果请求成功（或者响应未与请求关联），则<samlp:response>元素受以下约束：
o It MAY be signed.
o 可以签字。
o It MUST contain exactly one assertion. The <saml:Subject> element of this assertion MUST refer to the authenticated RADIUS user.
o 它必须只包含一个断言。此断言的<saml:Subject>元素必须引用经过身份验证的RADIUS用户。
o The assertion MUST contain a <saml:AuthnStatement>. Also, the assertion MUST contain a <saml:Subject> element with at least one <saml:SubjectConfirmation> element containing a <saml:ConfirmationMethod> element of urn:ietf:params:abfab:cm:user or urn:ietf:params:abfab:cm:machine that reflects the authentication of the client to the IdP. Since the <samlp:Response> message is in response to a <samlp:AuthnRequest>, the InResponseTo attribute (in both the <saml:SubjectConfirmationData> and <saml:Response> elements) MUST match the request's ID. The <saml:Subject> element MAY use the NAI name identifier format described in Section 5 to establish an identifier between the RP and the IdP.
o 断言必须包含<saml:AuthnStatement>。此外，断言必须包含一个<saml:Subject>元素，其中至少有一个<saml:SubjectConfirmation>元素包含urn:ietf:params:abfab:cm:user或urn:ietf:params:abfab:cm:machine的<saml:ConfirmationMethod>元素，该元素反映了客户端对IdP的身份验证。由于<samlp:Response>消息是对<samlp:AuthnRequest>的响应，因此InResponseTo属性（在<saml:SubjectConfirmationData>和<saml:Response>元素中）必须与请求的ID匹配。<saml:Subject>元素可以使用第5节中描述的NAI名称标识符格式在RP和IdP之间建立标识符。
o Other conditions MAY be included as requested by the RP or at the discretion of the IdP. The IdP is NOT obligated to honor the requested set of conditions in the <samlp:AuthnRequest>, if any.
o 根据RP的要求或IdP的决定，可包括其他条件。IdP没有义务遵守<samlp:AuthnRequest>中请求的条件集（如果有）。
The RP MUST do the following:
RP必须执行以下操作：
o Assume that the client's identifier implied by a SAML <Subject> element, if present, takes precedence over an identifier implied by the RADIUS User-Name attribute.
o 假设SAML<Subject>元素暗示的客户机标识符（如果存在）优先于RADIUS用户名属性暗示的标识符。
o Verify that the InResponseTo attribute in the "RADIUS State" <saml:SubjectConfirmationData> equals the ID of its original <samlp:AuthnRequest> message, unless the response is unsolicited, in which case the attribute MUST NOT be present.
o 验证“RADIUS状态”中的InResponseTo属性<saml:SubjectConfirmationData>是否等于其原始<samlp:AuthnRequest>消息的ID，除非响应是未经请求的，在这种情况下，该属性不得存在。
o If a <saml:AuthnStatement> used to establish a security context for the client contains a SessionNotOnOrAfter attribute, the security context SHOULD be discarded once this time is reached, unless the RP reestablishes the client's identity by repeating the use of this profile.
o 如果用于为客户端建立安全上下文的<saml:AuthnStatement>包含SessionNotOnOrAfter属性，则在达到此时间后应丢弃安全上下文，除非RP通过重复使用此配置文件重新建立客户端的身份。
o Verify that any assertions relied upon are valid according to processing rules specified in [OASIS.saml-core-2.0-os].
o 根据[OASIS.saml-core-2.0-os]中指定的处理规则，验证所依赖的任何断言是否有效。
o Any assertion that is not valid or whose subject confirmation requirements cannot be met MUST be discarded and MUST NOT be used to establish a security context for the client.
o 任何无效的断言或其主题确认要求无法满足的断言都必须丢弃，并且不得用于为客户端建立安全上下文。
An IdP MAY initiate this profile by delivering an unsolicited assertion to an RP. This MUST NOT contain any <saml:SubjectConfirmationData> elements containing an InResponseTo attribute.
IdP可以通过向RP发送未经请求的断言来启动此配置文件。此配置文件不得包含任何包含InResponseTo属性的<saml:SubjectConfirmationData>元素。
It is RECOMMENDED that the RADIUS exchange be protected using TLS encryption for RADIUS [RFC6614] to provide confidentiality and integrity protection.
建议使用RADIUS的TLS加密[RFC6614]来保护RADIUS交换，以提供机密性和完整性保护。
This profile calls for the use of SAML elements that support XML signatures. To promote interoperability, implementations of this profile MUST NOT require the use of XML signatures. Implementations MAY choose to use XML signatures.
此概要文件要求使用支持XML签名的SAML元素。为了促进互操作性，此概要文件的实现不得要求使用XML签名。实现可以选择使用XML签名。
There are no metadata considerations particular to this profile, aside from those applying to the use of the RADIUS binding.
除了适用于使用RADIUS绑定的元数据之外，此概要文件没有特定的元数据注意事项。
This profile builds on the SAML V2.0 Assertion Query/Request Profile defined by [OASIS.saml-profiles-2.0-os]. That profile describes the use of the Assertion Query and Request Protocol defined by Section 3.3 of [OASIS.saml-core-2.0-os] with synchronous bindings, such as the SOAP binding defined in [OASIS.saml-bindings-2.0-os].
此配置文件基于[OASIS.SAML-profiles-2.0-os]定义的SAML V2.0断言查询/请求配置文件。该概要文件描述了[OASIS.saml-core-2.0-os]第3.3节定义的断言查询和请求协议与同步绑定的使用，如[OASIS.saml-bindings-2.0-os]中定义的SOAP绑定。
Although the SAML V2.0 Assertion Query/Request Profile is independent of the underlying binding, it is nonetheless useful to describe the use of the SAML RADIUS binding defined in Section 4 of this document, in the interest of promoting interoperable implementations, particularly as the SAML V2.0 Assertion Query/Request Profile is most frequently discussed and implemented in the context of the SOAP binding.
尽管SAML V2.0断言查询/请求概要文件独立于底层绑定，但为了促进可互操作的实现，描述本文档第4节中定义的SAML RADIUS绑定的使用仍然很有用，特别是SAML V2.0断言查询/请求概要文件最常在SOAP绑定上下文中讨论和实现。
Identification: urn:ietf:params:abfab:profiles:query
Identification: urn:ietf:params:abfab:profiles:query
Contact information: iesg@ietf.org
联系方式：iesg@ietf.org
Description: Given below.
说明：见下文。
Updates: None.
更新：无。
As with the SAML V2.0 Assertion Query/Request Profile defined by [OASIS.saml-profiles-2.0-os], the message exchange and basic processing rules that govern this profile are largely defined by Section 3.3 of [OASIS.saml-core-2.0-os], which defines the messages to be exchanged, in combination with the binding used to exchange the messages. The SAML RADIUS binding described in this document defines the binding of the message exchange to RADIUS. Unless specifically noted here, all requirements defined in those specifications apply.
与[OASIS.SAML-profiles-2.0-os]定义的SAML V2.0断言查询/请求配置文件一样，控制该配置文件的消息交换和基本处理规则主要由[OASIS.SAML-core-2.0-os]的第3.3节定义，该节定义了要交换的消息，并结合了用于交换消息的绑定。本文档中描述的SAML RADIUS绑定定义了消息交换到RADIUS的绑定。除非此处特别注明，否则这些规范中定义的所有要求均适用。
Figure 8 below illustrates the basic template for the Query/Request Profile.
下面的图8说明了查询/请求概要文件的基本模板。
Relying Party Identity Provider
(SAML requester) (SAML responder)
| |
| (1) |
| - - - - - - - - - - - - - - - - - - - - - - - > |
| |
| (2) |
| < - - - - - - - - - - - - - - - - - - - - - - - |
| |
V V
Relying Party Identity Provider
(SAML requester) (SAML responder)
| |
| (1) |
| - - - - - - - - - - - - - - - - - - - - - - - > |
| |
| (2) |
| < - - - - - - - - - - - - - - - - - - - - - - - |
| |
V V
Figure 8: Basic Template for Query/Request Profile
图8：查询/请求概要文件的基本模板
The following steps are described by the profile:
配置文件描述了以下步骤：
1. Query/Request issued by RP: In step 1, an RP initiates the profile by sending an <AssertionIDRequest>, <SubjectQuery>, <AuthnQuery>, <AttributeQuery>, or <AuthzDecisionQuery> message to a SAML authority.
1. RP发出的查询/请求：在步骤1中，RP通过向SAML机构发送<AssertiondRequest>、<SubjectQuery>、<AuthnQuery>、<AttributeQuery>或<AuthzDecisionQuery>消息来启动配置文件。
2. <Response> issued by SAML authority: In step 2, the responding SAML authority (after processing the query or request) issues a <Response> message to the RP.
2. <Response>由SAML权威机构发布：在步骤2中，响应的SAML权威机构（在处理查询或请求后）向RP发布<Response>消息。
This profile is identical to the SAML V2.0 Assertion Query/Request Profile, with the following exceptions:
此配置文件与SAML V2.0断言查询/请求配置文件相同，但有以下例外：
o When processing the SAML request, the IdP MUST give precedence to the client's identifier implied by the RADIUS State attribute, if present, over the identifier implied by the SAML request's <Subject>, if any.
o 处理SAML请求时，IdP必须优先于RADIUS State属性（如果存在）所暗示的客户端标识符，而不是SAML请求的<Subject>所暗示的标识符（如果有）。
o In respect to Sections 6.3.1 and 6.5 of [OASIS.saml-profiles-2.0-os], this profile does not consider the use of metadata (as in [OASIS.saml-metadata-2.0-os]). See Section 8.3.4.
o 关于[OASIS.SAML PrruleSe2.0OS]的6.3.1和6.5节，此配置文件不考虑元数据的使用（如[OASIS.SAML Meta ADATA 2.0OS]）。见第8.3.4节。
o In respect to Sections 6.3.2, 6.4.1, and 6.4.2 of [OASIS.saml-profiles-2.0-os], this profile additionally stipulates that implementations of this profile MUST NOT require the use of XML signatures. See Section 8.3.3.
o 关于[OASIS.saml-profiles-2.0-os]的第6.3.2节、第6.4.1节和第6.4.2节，本概要文件另外规定，本概要文件的实现不得要求使用XML签名。见第8.3.3节。
The RADIUS Access-Request sent by the RP:
RP发送的RADIUS访问请求：
o MUST include an instance of the RADIUS Service-Type attribute, having a value of Authorize-Only.
o 必须包含RADIUS服务类型属性的实例，其值为Authorize Only。
o SHOULD include the RADIUS State attribute, where this Query/Request pertains to a previously authenticated client.
o 应包括RADIUS State属性，其中该查询/请求属于先前经过身份验证的客户端。
When processing the SAML request, the IdP MUST give precedence to the client's identifier implied by the RADIUS State attribute over the identifier implied by the SAML request's <Subject>, if any.
在处理SAML请求时，IdP必须将RADIUS State属性所暗示的客户端标识符优先于SAML请求的<Subject>所暗示的标识符（如果有）。
It is RECOMMENDED that the RADIUS exchange be protected using TLS encryption for RADIUS [RFC6614] to provide confidentiality and integrity protection.
建议使用RADIUS的TLS加密[RFC6614]来保护RADIUS交换，以提供机密性和完整性保护。
This profile calls for the use of SAML elements that support XML signatures. To promote interoperability, implementations of this profile MUST NOT require the use of XML signatures. Implementations MAY choose to use XML signatures.
此概要文件要求使用支持XML签名的SAML元素。为了促进互操作性，此概要文件的实现不得要求使用XML签名。实现可以选择使用XML签名。
There are no metadata considerations particular to this profile, aside from those applying to the use of the RADIUS binding.
除了适用于使用RADIUS绑定的元数据之外，此概要文件没有特定的元数据注意事项。
The profiles defined in this document allow an RP to request specific information about the client and allow an IdP to disclose information about that client. In this sense, IdPs MUST apply policy to decide what information is released to a particular RP. Moreover, the identity of the client is typically hidden from the RP unless provided by the IdP. Conversely, the RP does typically know the realm of the IdP, as it is required to route the RADIUS packets to the right destination.
本文件中定义的配置文件允许RP请求有关客户的特定信息，并允许IdP披露有关该客户的信息。从这个意义上说，IdP必须应用政策来决定向特定RP发布哪些信息。此外，除非IdP提供，否则客户的身份通常对RP隐藏。相反，RP通常知道IdP的领域，因为需要将RADIUS数据包路由到正确的目的地。
The kind of information that is released by the IdP can include generic attributes such as affiliation shared by many clients. But even these generic attributes can help to identify a specific client. Other kinds of attributes may also provide an RP with the ability to link the same client between different sessions. Finally, other kinds of attributes might provide a group of RPs with the ability to link the client between them or with personally identifiable information about the client.
IdP发布的信息类型可以包括通用属性，例如许多客户共享的从属关系。但即使这些通用属性也有助于识别特定的客户机。其他类型的属性也可以为RP提供在不同会话之间链接同一客户机的能力。最后，其他类型的属性可能会为一组RPs提供在它们之间链接客户机的能力，或者提供关于客户机的个人可识别信息。
These profiles do not directly provide a client with a mechanism to express preferences about what information is released. That information can be expressed out of band, for example, as part of the enrollment process.
这些概要文件并不直接为客户机提供一种机制来表达关于发布什么信息的偏好。该信息可以在带外表示，例如，作为注册过程的一部分。
The RP may disclose privacy-sensitive information about itself as part of the request, although this is unlikely in typical deployments.
RP可能会在请求中披露有关其自身的隐私敏感信息，尽管这在典型部署中不太可能。
If RADIUS proxies are used and encryption is not used, the attributes disclosed by the IdP are visible to the proxies. This is a significant privacy exposure in some deployments. Ongoing work is exploring mechanisms for creating TLS connections directly between the RADIUS client and the RADIUS server to reduce this exposure. If proxies are used, the impact of exposing SAML Assertions to the proxies needs to be carefully considered.
如果使用RADIUS代理且未使用加密，则IdP公开的属性对代理可见。在某些部署中，这是一种严重的隐私暴露。正在进行的工作是探索在RADIUS客户端和RADIUS服务器之间直接创建TLS连接的机制，以减少这种暴露。如果使用代理，则需要仔细考虑向代理公开SAML断言的影响。
The use of TLS to provide confidentiality for the RADIUS exchange is strongly encouraged. Without this, passive eavesdroppers can observe the assertions.
强烈鼓励使用TLS为RADIUS交换提供机密性。如果没有这一点，被动窃听者可以观察断言。
In this specification, the RP MUST trust any statement in the SAML messages from the IdP in the same way that it trusts information contained in RADIUS attributes. These entities MUST trust the RADIUS infrastructure to provide integrity of the SAML messages.
在本规范中，RP必须以信任RADIUS属性中包含的信息的方式信任来自IdP的SAML消息中的任何语句。这些实体必须信任RADIUS基础设施以提供SAML消息的完整性。
Furthermore, the RP MUST apply policy and filter the information based on what information the IdP is permitted to assert and on what trust is reasonable to place in proxies between them.
此外，RP必须根据允许IdP声明的信息以及在他们之间的代理中合理放置的信任，应用策略并过滤信息。
XML signatures and encryption are provided as an OPTIONAL mechanism for end-to-end security. These mechanisms can protect SAML messages from being modified by proxies in the RADIUS infrastructure. These mechanisms are not mandatory to implement. It is believed that ongoing work to provide direct TLS connections between a RADIUS client and RADIUS server will provide similar assurances but better deployability. XML security is appropriate for deployments where end-to-end security is required but proxies cannot be removed or where SAML messages need to be verified at a later time or by parties not involved in the authentication exchange.
XML签名和加密作为端到端安全性的可选机制提供。这些机制可以保护SAML消息不被RADIUS基础设施中的代理修改。这些机制不是强制实施的。据信，在RADIUS客户端和RADIUS服务器之间提供直接TLS连接的持续工作将提供类似的保证，但具有更好的可部署性。XML安全性适用于需要端到端安全性但无法删除代理的部署，或者SAML消息需要稍后或由未参与身份验证交换的各方验证的部署。
The Attribute Types and Attribute Values defined in this document have been registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes, and registries created by this document, IANA has placed them at <http://www.iana.org/assignments/radius-types>.
本文件中定义的属性类型和属性值已由互联网分配号码管理局（IANA）根据BCP 26[RFC5226]从[RFC3575]的“IANA注意事项”部分所述的RADIUS名称空间中注册。对于本文档创建的RADIUS数据包、属性和注册表，IANA已将它们放置在<http://www.iana.org/assignments/radius-types>.
In particular, this document defines two new RADIUS attributes, entitled "SAML-Assertion" and "SAML-Protocol" (see Section 3), with assigned values of 245.1 and 245.2 from the long extended space [RFC6929]:
特别是，本文件定义了两个新的RADIUS属性，标题为“SAML断言”和“SAML协议”（见第3节），从长扩展空间[RFC6929]中分配了245.1和245.2的值：
Type Ext. Type Name Length Meaning
---- --------- -------------- ------ ------------------------
245 1 SAML-Assertion >=5 Encodes a SAML Assertion
245 2 SAML-Protocol >=5 Encodes a SAML protocol
message
Type Ext. Type Name Length Meaning
---- --------- -------------- ------ ------------------------
245 1 SAML-Assertion >=5 Encodes a SAML Assertion
245 2 SAML-Protocol >=5 Encodes a SAML protocol
message
A new top-level registry has been created, entitled "Application Bridging for Federated Access Beyond Web (ABFAB) Parameters".
创建了一个新的顶级注册表，名为“Web之外的联邦访问应用程序桥接（ABFAB）参数”。
In this top-level registry, a sub-registry entitled "ABFAB URN Parameters" has been created. Registration in this registry is via IETF Review or Expert Review procedures [RFC5226].
在这个顶级注册表中，创建了一个名为“ABFAB URN参数”的子注册表。通过IETF审查或专家审查程序[RFC5226]在本注册中心注册。
This paragraph gives guidance to designated experts. Registrations in this registry are generally only expected as part of protocols published as RFCs on the IETF stream; other URIs are expected to be better choices for non-IETF work. Expert review is permitted mainly to allow early registration related to specifications under development when the community believes they have reached sufficient maturity. The expert SHOULD evaluate the maturity and stability of such an IETF-stream specification. Experts SHOULD review anything not from the IETF stream for consistency and consensus with current practice. Today, such requests would not typically be approved.
本段为指定专家提供指导。该注册表中的注册通常仅作为IETF流上作为RFC发布的协议的一部分；其他URI有望成为非IETF工作的更好选择。允许专家评审的主要目的是，当社区认为正在开发的规范已达到足够成熟时，允许提前注册相关规范。专家应评估此类IETF流规范的成熟度和稳定性。专家应审查IETF流以外的任何内容，以确保与当前实践的一致性和共识。如今，这类请求通常不会得到批准。
If a parameter named "paramname" is registered in this registry, then its URN will be "urn:ietf:params:abfab:paramname". The initial registrations are as follows:
如果在该注册表中注册了名为“paramname”的参数，则其URN将为“URN:ietf:params:abfab:paramname”。初步注册情况如下：
+-------------------------+-----------+
| Parameter | Reference |
+-------------------------+-----------+
| bindings:radius | Section 4 |
| nameid-format:nai | Section 5 |
| profiles:authentication | Section 7 |
| profiles:query | Section 8 |
| cm:user | Section 6 |
| cm:machine | Section 6 |
+-------------------------+-----------+
+-------------------------+-----------+
| Parameter | Reference |
+-------------------------+-----------+
| bindings:radius | Section 4 |
| nameid-format:nai | Section 5 |
| profiles:authentication | Section 7 |
| profiles:query | Section 8 |
| cm:user | Section 6 |
| cm:machine | Section 6 |
+-------------------------+-----------+
ABFAB Parameters
ABFAB参数
IANA has registered the "abfab" URN sub-namespace in the IETF URN sub-namespace for protocol parameters defined in [RFC3553].
IANA已在IETF URN子命名空间中为[RFC3553]中定义的协议参数注册了“abfab”URN子命名空间。
Registry Name: abfab
注册名称：abfab
Specification: RFC 7833 (this document)
规范：RFC 7833（本文件）
Repository: ABFAB URN Parameters (Section 11.2)
存储库：ABFAB URN参数（第11.2节）
Index Value: Sub-parameters MUST be specified in UTF-8, using standard URI encoding where necessary.
索引值：必须在UTF-8中指定子参数，必要时使用标准URI编码。
[OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-bindings-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-bindings-2.0-os.pdf>.
[OASIS.saml-bindings-2.0-os]Cantor，S.，Hirsch，F.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（saml）V2.0的绑定”，OASIS标准saml-bindings-2.0-os，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-bindings-2.0-os.pdf>。
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS.saml-core-2.0-os]Cantor，S.，Kemp，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（saml）V2.0的断言和协议”，OASIS标准saml-core-2.0-os，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>。
[OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 2005, <http://docs.oasis-open.org/security/ saml/v2.0/saml-metadata-2.0-os.pdf>.
[OASIS.saml-metadata-2.0-os]Cantor，S.，Moreh，J.，Philpott，R.，和E.Maler，“OASIS安全断言标记语言（saml）V2.0的元数据”，OASIS标准saml-metadata-2.0-os，2005年3月<http://docs.oasis-open.org/security/ saml/v2.0/saml-metadata-2.0-os.pdf>。
[OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-profiles-2.0-os.pdf>.
[OASIS.saml-profiles-2.0-os]休斯，J.，坎托，S.，霍奇斯，J.，赫希，F.，米什拉，P.，菲尔波特，R.，和E.马勒，“OASIS安全断言标记语言（saml）V2.0的配置文件”，OASIS标准OASIS.saml-profiles-2.0-os，2005年3月<http://docs.oasis-open.org/security/saml/v2.0/ saml-profiles-2.0-os.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, DOI 10.17487/RFC3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，DOI 10.17487/RFC3575，2003年7月<http://www.rfc-editor.org/info/rfc3575>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September 2003, <http://www.rfc-editor.org/info/rfc3579>.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，DOI 10.17487/RFC3579，2003年9月<http://www.rfc-editor.org/info/rfc3579>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <http://www.rfc-editor.org/info/rfc6614>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<http://www.rfc-editor.org/info/rfc6614>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 6929，DOI 10.17487/RFC6929，2013年4月<http://www.rfc-editor.org/info/rfc6929>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <http://www.rfc-editor.org/info/rfc7542>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<http://www.rfc-editor.org/info/rfc7542>.
[RADIUS-Large-Pkts] Hartman, S., "Larger Packets for RADIUS over TCP", Work in Progress, draft-ietf-radext-bigger-packets-07, April 2016.
[RADIUS大数据包]Hartman，S.，“TCP上RADIUS的大数据包”，正在进行的工作，草稿-ietf-radext-BIGER-PACKES-072016年4月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，DOI 10.17487/RFC3553，2003年6月<http://www.rfc-editor.org/info/rfc3553>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC7055] Hartman, S., Ed., and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", RFC 7055, DOI 10.17487/RFC7055, December 2013, <http://www.rfc-editor.org/info/rfc7055>.
[RFC7055]Hartman，S.，Ed.，和J.Howlett，“可扩展身份验证协议的GSS-API机制”，RFC 7055，DOI 10.17487/RFC7055，2013年12月<http://www.rfc-editor.org/info/rfc7055>.
[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/RFC7499, April 2015, <http://www.rfc-editor.org/info/rfc7499>.
[RFC7499]Perez Mendez，A.，Ed.，Marin Lopez，R.，Pereniguez Garcia，F.，Lopez Millan，G.，Lopez，D.，和A.DeKok，“支持RADIUS数据包碎片化”，RFC 7499，DOI 10.17487/RFC7499，2015年4月<http://www.rfc-editor.org/info/rfc7499>.
[RFC7831] Howlett, J., Hartman, S., Tschofenig, H., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", RFC 7831, DOI 10.17487/RFC7831, May 2016, <http://www.rfc-editor.org/info/rfc7831>.
[RFC7831]Howlett，J.，Hartman，S.，Tschofenig，H.，和J.Schaad，“Web之外联邦访问（ABFAB）架构的应用程序桥接”，RFC 7831，DOI 10.17487/RFC7831，2016年5月<http://www.rfc-editor.org/info/rfc7831>.
[W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC-xmlschema-1, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.REC-xmlschema-1]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构第二版”，W3C REC-xmlschema-1，2004年10月<http://www.w3.org/TR/xmlschema-1/>.
The following schema formally defines the "urn:ietf:params:xml:ns:abfab" namespace used in this document, in conformance with [W3C.REC-xmlschema-1]. Although XML validation is optional, the schema that follows is the normative definition of the constructs it defines. Where the schema differs from any prose in this specification, the schema takes precedence.
以下模式正式定义了本文档中使用的“urn:ietf:params:xml:ns:abfab”命名空间，符合[W3C.REC-xmlschema-1]。尽管XML验证是可选的，但下面的模式是它定义的结构的规范定义。如果模式与本规范中的任何散文不同，则以模式为准。
<schema
targetNamespace="urn:ietf:params:xml:ns:abfab"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:abfab="urn:ietf:params:xml:ns:abfab"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
version="1.0">
<schema
targetNamespace="urn:ietf:params:xml:ns:abfab"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:abfab="urn:ietf:params:xml:ns:abfab"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
version="1.0">
<import namespace="urn:oasis:names:tc:SAML:2.0:metadata"/>
<import namespace="urn:oasis:names:tc:SAML:2.0:metadata"/>
<complexType name="RADIUSIDPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="abfab:RADIUSIDPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="abfab:RADIUSRealm"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSIDPService" type="md:EndpointType"/>
<element name="RADIUSRealm" type="string"/>
<complexType name="RADIUSIDPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="abfab:RADIUSIDPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="abfab:RADIUSRealm"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSIDPService" type="md:EndpointType"/>
<element name="RADIUSRealm" type="string"/>
<complexType name="RADIUSRPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="md:RADIUSRPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIpAddress"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIdentifier"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSGssEapName"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSRPService" type="md:EndpointType"/>
<element name="RADIUSNasIpAddress" type="string"/>
<element name="RADIUSNasIdentifier" type="string"/>
<element name="RADIUSGssEapName" type="string"/>
</schema>
<complexType name="RADIUSRPDescriptorType">
<complexContent>
<extension base="md:RoleDescriptorType">
<sequence>
<element ref="md:RADIUSRPService"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIpAddress"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSNasIdentifier"
minOccurs="0" maxOccurs="unbounded"/>
<element ref="md:RADIUSGssEapName"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RADIUSRPService" type="md:EndpointType"/>
<element name="RADIUSNasIpAddress" type="string"/>
<element name="RADIUSNasIdentifier" type="string"/>
<element name="RADIUSGssEapName" type="string"/>
</schema>
Acknowledgments
致谢
The authors would like to acknowledge the OASIS Security Services (SAML) Technical Committee, and Scott Cantor in particular, for their help with the SAML-related material.
作者要感谢OASIS安全服务（SAML）技术委员会，特别是Scott Cantor，感谢他们对SAML相关材料的帮助。
The authors would also like to acknowledge the collaboration of Jim Schaad, Leif Johansson, Klaas Wierenga, Stephen Farrell, Gabriel Lopez-Millan, and Rafa Marin-Lopez, who have provided valuable comments on this document.
作者还要感谢Jim Schaad、Leif Johansson、Klaas Wierenga、Stephen Farrell、Gabriel Lopez Millan和Rafa Marin Lopez的合作，他们对本文件提出了宝贵的意见。
Authors' Addresses
作者地址
Josh Howlett Jisc Lumen House, Library Avenue, Harwell Oxford OX11 0SG United Kingdom
英国牛津哈维尔图书馆大道Josh Howlett Jisc Lumen House OX11 0SG
Phone: +44 1235 822363
Email: Josh.Howlett@ja.net
Phone: +44 1235 822363
Email: Josh.Howlett@ja.net
Sam Hartman Painless Security
山姆·哈特曼无痛安全
Email: hartmans-ietf@mit.edu
Email: hartmans-ietf@mit.edu
Alejandro Perez-Mendez (editor) University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
Alejandro Perez Mendez（编辑）穆尔西亚大学艾斯皮纳多S/N，计算机科学学院，穆尔西亚，西班牙30100
Phone: +34 868 88 46 44
Email: alex@um.es
Phone: +34 868 88 46 44
Email: alex@um.es