[要約] RFC 7833は、RADIUS属性、バインディング、プロファイル、名前識別子フォーマット、およびセキュリティアサーションマークアップ言語（SAML）の確認方法に関する規格です。このRFCの目的は、RADIUSとSAMLの統合を容易にし、セキュリティ認証の効率と信頼性を向上させることです。
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.
このドキュメントでは、RADIUSでのセキュリティアサーションマークアップ言語（SAML）の、Web経由のフェデレーションアクセスのアプリケーションブリッジング（ABFAB）アーキテクチャのコンテキストでの使用について説明します。 2つのRADIUS属性、SAMLバインディング、SAML名前識別子形式、2つのSAMLプロファイル、および2つのSAML確認メソッドを定義します。 RADIUS属性は、RADIUS内のSAMLアサーションおよびプロトコルメッセージのカプセル化を許可し、SAMLエンティティがバインディングを使用して通信できるようにします。 2つのプロファイルは、ABFAB認証およびアサーションクエリ/リクエストに対するこのバインディングのアプリケーションを記述し、依存パーティがユーザーまたはマシン（クライアント）の認証またはアサーションをリクエストできるようにします。これらのクライアントには、ネットワークアクセス識別子（NAI）の名前識別子の形式を使用して名前を付けることができます。最後に、サブジェクト確認メソッドを使用すると、以前に認証されたユーザーまたはマシンに対して、それらをサブジェクトとして明示的に識別する必要なく、要求とクエリを発行できます。このドキュメントで定義されているアーティファクトの使用は、ABFABに限定されません。これらは、ネットワークアクセス制御などの認証、承認、およびアカウンティング（AAA）シナリオに適用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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は通常、バインディング[OASIS.saml-bindings-2.0-os]と呼ばれるHTTPベースのトランスポートの使用のみを考慮します。これは、主にSAML V2.0 Webブラウザーシングルサインオンプロファイル[OASIS.samlでの使用を目的としています。 -profiles-2.0-os]。ただし、ABFABの目標は、認証、承認、およびアカウンティング（AAA）フレームワークを構築することにより、フェデレーションIDの適用性をWebを超えて他のアプリケーションに拡張することです。したがって、SAMLには、HTTPに加えて、AAAフレームワークや、RADIUS [RFC2865]やDiameter [RFC6733]などのプロトコルと統合する必要があります。
In summary, this document specifies:
要約すると、このドキュメントでは次のことを指定しています。
o Two RADIUS attributes to encapsulate SAML Assertions and protocol messages, respectively.
o SAMLアサーションとプロトコルメッセージをそれぞれカプセル化するための2つのRADIUS属性。
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 RADIUSバインディングを使用してSAMLベースの認証と許可を行うSAML Authentication Request Protocolのプロファイル。
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 RADIUSバインディングを使用してSAMLアサーションのクエリとリクエストに影響を与えるSAMLアサーションクエリとリクエストプロトコルのプロファイル。
o Two SAML subject confirmation methods for indicating that a user or machine client is the subject of an assertion.
o ユーザーまたはマシンクライアントがアサーションの対象であることを示すための2つの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用語を使用します。参考のために、さまざまな用語を1つのビューにマップする次の表を含めます。 （このドキュメントでは、「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 |
+----------+-----------+------------------+-------------------+
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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バインディングは、2つの属性を使用してSAMLアサーションとプロトコルメッセージを伝達します[OASIS.saml-core-2.0-os]。これらの構造の一般的なサイズにより、これらの属性は「Long Extended Type」形式[RFC6929]を使用してデータをカプセル化します。 RADIUSエンティティは、SAML情報を伝達するための排他的な代替手段を表すため、同じRADIUSメッセージに両方の属性を含めることはできません。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SAML-Assertion Format
図1：SAMLアサーションフォーマット
Type
タイプ
245
２４５
Length
長さ
>= 5
＞＝ ５
Extended-Type
拡張タイプ
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アサーションをエンコードする1つ以上のオクテット。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SAML-Protocol Format
図2：SAMLプロトコルの形式
Type
タイプ
245
２４５
Length
長さ
>= 5
＞＝ ５
Extended-Type
拡張タイプ
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プロトコルメッセージをエンコードする1つ以上のオクテット。
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
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メッセージ内のステートメントを信頼する必要があります。これらのエンティティは、SAMLメッセージの整合性を提供するためにRADIUSインフラストラクチャを信頼する必要があります。
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.
したがって、IPsecトンネルや十分に安全な内部ネットワークなどの代替手段を使用しない限り、RADIUS [RFC6614]のトランスポート層セキュリティ（TLS）暗号化を使用してRADIUS交換を保護し、機密性と完全性を保護する必要があります。 。
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パケット[RFC7499]またはRADIUS over TCP [RADIUS-Large-Pkts]のフラグメンテーションのサポートなど、RADIUSトランスポートを介したより長いSAMLメッセージのトランスポートを許可するメカニズムを利用できます。
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.
RADIUSを介したSAMLの使用には、2つのシステムモデルがあります。 1つ目は、セクション3で定義されたRADIUS SAML-Protocol属性を使用して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. RPとして機能するRADIUSクライアントは、RADIUS Access-Requestメッセージ内でSAML要求要素を送信します。このメッセージには、値がネットワークアクセス識別子[RFC7542]スキームに準拠している必要があるRADIUS User-Name属性の単一のインスタンスが含まれている必要があります。 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. IdPとして機能するRADIUSサーバーは、RADIUS Access-AcceptまたはAccess-Rejectメッセージ内でSAMLプロトコルメッセージを返します。これらのメッセージは必然的にRADIUS交換を完了するため、これがIdPがこの交換のコンテキストで応答を送信する唯一の機会です。 IdPに複数のSAML応答を含めることはできません。 RPとのメッセージ交換の実行を拒否するIdPは、SAMLリクエストをサイレントに破棄できます（これに続いて、RADIUS Access-Rejectが発生する可能性があります。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.
2番目のシステムモデルでは、IdPとして機能するRADIUSサーバーが、セクション3で定義されたRADIUS SAML-Assertion属性を使用して、非送信請求SAMLアサーションをカプセル化できるようにします。この属性は、RADIUS Access-Acceptメッセージに含める必要があります。含める場合、属性には単一の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-ProtocolおよびSAML-Assertion属性の両方を含めてはなりません（MUST NOT）。 IdPがSAMLリクエストへの応答を生成している場合、最初のシステムモデルが使用されます。 IdPは、SAMLリクエストを無視し、2番目のシステムモデルを使用して（つまり、RADIUS SAML-Assertion属性を使用して）非送信請求アサーションを送信できます（MAY）。
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状態属性をAccess-Acceptメッセージの一部として返し、将来のSAMLクエリまたは要求を認証交換の同じコンテキストに対して実行できるようにする必要があります（SHOULD）。
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パケット内の<samlp：Status>要素に適切な値を含むSAML応答メッセージを含めることができます（MAY）。または、RADIUSサーバーはSAML-Protocol属性なしで応答できます。
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は、RADIUS Access-Requestに関連付けられたRPのIDに基づいてポリシーを適用する必要があります（SHOULD）。
o RPs SHOULD apply policy based on the NAI realm associated with the RADIUS Access-Accept.
o RPは、RADIUS Access-Acceptに関連付けられたNAIレルムに基づいてポリシーを適用する必要があります（SHOULD）。
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に基づいてポリシーを適用する場合があります。そのような場合、RPのSAML名とAAA名の間の関係を確立するために、以下のメソッドの少なくとも1つが必要です。
o RADIUS client identity in trusted SAML metadata (as described in Section 4.3.3).
o 信頼されたSAMLメタデータ内のRADIUSクライアントID（セクション4.3.3で説明）。
o RADIUS client identity in trusted digitally signed SAML request.
o 信頼できるデジタル署名されたSAMLリクエストのRADIUSクライアントID。
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メッセージを監視し、そのSAMLメッセージの発行者の同意なしに別のRADIUSメッセージに含めることができるため、RADIUSクライアントIDのないデジタル署名されたSAML要求では不十分です。 IdPが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:
RPは、SAML発行者のentityIDに基づいてポリシーを適用してもよい（MAY）。このような場合、SAML名とIdPのAAA名の関係を確立するには、次のメソッドの少なくとも1つが必要です。
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.
このセクションでは、特定の<EntityDescriptor>要素に関連付けられたAAA名を表すために必要なSAMLメタデータスキーマ[OASIS.saml-metadata-2.0-os]の拡張機能を定義します。
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の2つの新しい役割を定義しています。RoleDescriptorTypeの2つの新しいサブタイプであるRADIUSIDPDescriptorTypeと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.
<RADIUSIDPService> [ゼロ以上]エンティティに関連付けられているRADIUSエンドポイントを記述するタイプEndpointTypeのゼロ以上の要素。
<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> [ゼロ以上]エンティティに関連付けられたRADIUSレルムの許容値を表す文字列型の0個以上の要素。RADIUSユーザー名属性のレルム部分から取得されます。
The following schema fragment defines the RADIUSIDPDescriptorType complex type:
次のスキーマフラグメントは、RADIUSIDPDescriptorType複合型を定義しています。
<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：RADIUSIDPDescriptorTypeスキーマ
The RADIUSRPDescriptorType complex type extends RoleDescriptorType with elements common to RPs that support RADIUS. It contains the following additional elements:
RADIUSRPDescriptorType複合型は、RADIUSをサポートするRPに共通の要素でRoleDescriptorTypeを拡張します。次の追加要素が含まれています。
<RADIUSRPService> [Zero or More] Zero or more elements of type EndpointType that describe RADIUS endpoints that are associated with the entity.
<RADIUSRPService> [ゼロ以上]エンティティに関連付けられているRADIUSエンドポイントを説明するタイプEndpointTypeのゼロ以上の要素。
<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.
<RADIUSNasIpAddress> [ゼロ以上]エンティティに関連付けられたRADIUS NAS-IP-AddressまたはNAS-IPv6-Address属性の許容値を表す文字列型の0個以上の要素。
<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.
<RADIUSNasIdentifier> [ゼロ以上]エンティティに関連付けられたRADIUS NAS-Identifier属性の許容値を表す文字列型の0個以上の要素。
<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> [ゼロ以上]エンティティに関連付けられた拡張認証プロトコル（GSS-EAP）アクセプター名のGSS-APIメカニズムの許容値を表す文字列型の0個以上の要素。この名前の形式は、[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"/>
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>
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>
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
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: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 Access-Acceptメッセージによって認証されたシステムエンティティ（ユーザーまたはマシンのいずれか）であることを示します。RADIUSメッセージのState属性の値によって識別されます。
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を使用してクライアントを認証します。特に、RADIUSクライアントとして機能するRPは、クライアントのIdPとして機能するRADIUSサーバーに対してクライアントの資格情報を検証しようとします。 IdPがクライアントを正常に認証すると、RPによって消費される認証アサーションが生成されます。このアサーションには、RPとIdPの間でクライアントを参照するために使用できる名前識別子が含まれる場合があります。
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
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つ以上の実際のメッセージ交換が行われる場合があります。
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はオプションで、SAML-Protocol RADIUS属性を使用してIdPに配信される<samlp：AuthnRequest>メッセージを発行できます。
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>メッセージが提供されている場合は、RPによって課せられた要件が満たされます。
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. IdPはRPに<samlp：Response>を発行します（セクション7.3.4）。ステップ4で、IdPはSAML RADIUSバインディングを使用してRPに<samlp：Response>メッセージを発行します。応答はエラーを示すか、または1つのSAMLアサーションにSAML認証ステートメントを含みます。 RPが<samlp：AuthnRequest>を送信しなかった場合、セクション7.4.4で説明されているように、IdPは非送信請求の<samlp：Assertion>を発行します。
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で、RPはIdPから応答を受信すると、独自のエラーでクライアントに応答するか、クライアントの独自のセキュリティコンテキストを確立して、要求されたリソースを返すことができます。
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は、後続の対話を元の要求に関連付ける任意の手段を自由に使用できます。 RADIUSクライアントとして機能するRPは、クライアントの認証を試みます。
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-Protocol RADIUS属性を使用して、このRADIUS Access-Requestメッセージ内に<samlp：AuthnRequest>を含めることができます。 「ネクストホップ」宛先はIdP、または代わりに中間RADIUSプロキシになる場合があります。
Profile-specific rules for the contents of the <samlp:AuthnRequest> element are given in Section 7.4.1.
<samlp：AuthnRequest>要素の内容に関するプロファイル固有のルールは、セクション7.4.1に記載されています。
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認証方式を使用してクライアントのIDを確立する必要があります。確立しない場合、エラーが返されます。 <samlp：AuthnRequest>要素のForceAuthn属性（RPによって送信された場合）が存在し、trueの場合、IdPは、クライアントとの既存のセッション状態（TLSなど）に依存するのではなく、このIDを新たに確立する必要がありますセッションの再開に使用される可能性がある状態）。それ以外の場合、および他のすべての点で、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認証結果と一貫した方法で認証を終了する必要があります。 [OASIS.saml-core-2.0-os]で説明されているように、IdPは認証結果と一致する<samlp：Response>メッセージをRPに発行できます（MAY）。このSAML応答は、セクション4で説明されているSAML RADIUSバインディングを使用してRPに配信されます。
Profile-specific rules regarding the contents of the <samlp:Response> element are given in Section 7.4.2.
<samlp：Response>要素の内容に関するプロファイル固有のルールについては、セクション7.4.2を参照してください。
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.
<samlp：Response>メッセージがIdPによって発行された場合、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>要素を含めてはなりません（MUST NOT）。認証されたRADIUS IDは、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で説明されているメッセージコンテンツを含めることができます（MAY）。すべての処理ルールは[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 Access-Rejectメッセージで応答する必要があります。
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 正確に1つのアサーションを含める必要があります。このアサーションの<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>が含まれている必要があります。また、アサーションには、少なくとも1つの<saml：SubjectConfirmation>要素を含む<saml：Subject>要素と、urn：ietf：params：abfab：cm：userまたはurn：ietf：params：の<saml：ConfirmationMethod>要素が含まれている必要があります。 IdPに対するクライアントの認証を反映するabfab：cm：machine。 <samlp：Response>メッセージは<samlp：AuthnRequest>に応答するため、InResponseTo属性（<saml：SubjectConfirmationData>要素と<saml：Response>要素の両方）は、要求のIDと一致する必要があります。 <saml：Subject>要素は、RPとIdP間の識別子を確立するために、セクション5で説明されているNAI名識別子フォーマットを使用できます（MAY）。
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 User-Name属性によって暗示される識別子よりも優先されると想定します。
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 State" <saml：SubjectConfirmationData>のInResponseTo属性が元の<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がこのプロファイルの使用を繰り返してクライアントのIDを再確立しない限り、この時刻に到達するとセキュリティコンテキストを破棄する必要があります。
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 有効ではない、またはサブジェクトの確認要件を満たせないアサーションは破棄する必要があり、クライアントのセキュリティコンテキストを確立するために使用してはなりません（MUST NOT）。
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に配信することにより、このプロファイルを開始できます（MAY）。これには、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署名の使用を要求してはなりません（MUST NOT）。実装は、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
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]のセクション3.3で主に定義されています。 -2.0-os]は、メッセージの交換に使用されるバインディングと組み合わせて、交換されるメッセージを定義します。このドキュメントで説明する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
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は<AssertionIDRequest>、<SubjectQuery>、<AuthnQuery>、<AttributeQuery>、または<AuthzDecisionQuery>メッセージをSAML機関に送信することにより、プロファイルを開始します。
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. SAMLオーソリティによって発行された<Response>：ステップ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状態属性によって暗示されるクライアントの識別子が存在する場合、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-profiles-2.0-os]のセクション6.3.1および6.5に関して、このプロファイルはメタデータの使用を考慮していません（[OASIS.saml-metadata-2.0-os]のように）。セクション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 Authorize-Onlyの値を持つRADIUS Service-Type属性のインスタンスを含める必要があります。
o SHOULD include the RADIUS State attribute, where this Query/Request pertains to a previously authenticated client.
o このクエリ/リクエストが以前に認証されたクライアントに関係するRADIUS状態属性を含める必要があります。
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状態属性によって暗示されるクライアントの識別子を、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署名の使用を要求してはなりません（MUST NOT）。実装は、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によって提供されない限り、クライアントのIDは通常RPから隠されます。逆に、RADIUSパケットを正しい宛先にルーティングする必要があるため、RPは通常、IdPの領域を認識します。
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に提供します。最後に、他の種類の属性は、RPのグループに、それらの間のクライアントをリンクする機能、またはクライアントに関する個人を特定できる情報を提供する場合があります。
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メッセージ内のすべてのステートメントを信頼する必要があります。これらのエンティティは、SAMLメッセージの整合性を提供するためにRADIUSインフラストラクチャを信頼する必要があります。
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署名と暗号化は、エンドツーエンドのセキュリティのためのオプションのメカニズムとして提供されます。これらのメカニズムは、RADIUSインフラストラクチャのプロキシによってSAMLメッセージが変更されるのを防ぐことができます。これらのメカニズムの実装は必須ではありません。 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>.
このドキュメントで定義されている属性タイプと属性値は、BCP 26 [RFC5226]に従って、[RFC3575]の「IANAに関する考慮事項」セクションで説明されているように、RADIUS名前空間からInternet Assigned Numbers Authority（IANA）によって登録されています。このドキュメントで作成された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]:
特に、このドキュメントでは、「SAML-Assertion」と「SAML-Protocol」（セクション3を参照）という2つの新しいRADIUS属性を定義し、長い拡張スペース[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
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 Parameters」というサブレジストリーが作成されています。このレジストリへの登録は、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ストリーム仕様の成熟度と安定性を評価する必要があります（SHOULD）。専門家は、現在の慣行との一貫性とコンセンサスについて、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 |
+-------------------------+-----------+
ABFAB Parameters
ABFABパラメータ
IANA has registered the "abfab" URN sub-namespace in the IETF URN sub-namespace for protocol parameters defined in [RFC3553].
IANAは、[RFC3553]で定義されているプロトコルパラメータのIETF URNサブ名前空間に「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.
インデックス値：サブパラメーターは、必要に応じて標準のURIエンコーディングを使用して、UTF-8で指定する必要があります。
[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.、and E. Maler、 "Bindings for the OASIS Security Assertion Markup Language（SAML）V2。 0 "、OASIS Standard Binding-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/binding-binding-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.、and E. Maler、 "Assertions and Protocols for the OASIS Security Assertion Markup Language（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.、and E. Maler、 "Metadata for the OASIS Security Assertion Markup Language（SAML）V2.0"、OASIS Standard 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] Hughes、J.、Cantor、S.、Hodges、J.、Hirsch、F.、Mishra、P.、Philpott、R.、およびE. Maler、「Profiles for the 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、「Remote Authentication Dial In User Service（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（Remote Authentication Dial In User Service）Support For Extensible Authentication Protocol（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.、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>。
[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、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、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。、「The Network Access Identifier」、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-Large-Pkts] Hartman、S。、「RADIUS over TCPのより大きなパケット」、作業中、draft-ietf-radext-bigger-packets-07、2016年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、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、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、「RFCで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.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、DOI 10.17487 / RFC6733、October 2012、<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、「Extensible Authentication Protocolの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]ハウレット、J。、ハートマン、S.、Tschofenig、H。、およびJ.シャード、「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 Schema Part 1：Structures Second Edition」、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検証はオプションですが、以下のスキーマは、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">
<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="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）技術委員会、特にSAML関連資料への支援に対してScott Scottを認めたいと思います。
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.
著者はまた、このドキュメントに貴重なコメントを提供してくれたジムシャード、レイフヨハンソン、クラースウィレンガ、スティーブンファレル、ガブリエルロペスミラン、およびラファマリンロペスのコラボレーションを認めたいと思います。
Authors' Addresses
著者のアドレス
Josh Howlett Jisc Lumen House, Library Avenue, Harwell Oxford OX11 0SG United Kingdom
Josh Howlett Jisc Lumen House、Library Avenue、Harwell Oxford OX11 0SGイギリス
Phone: +44 1235 822363
Email: Josh.Howlett@ja.net
Sam Hartman Painless Security
サムハートマンの痛みのないセキュリティ
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（編集者）ムルシア大学Campus de Espinardo S / N、Faculty of Computer Science Murcia 30100 Spain
Phone: +34 868 88 46 44
Email: alex@um.es