RFC 7833
A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)
A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML) ✨
RFC 7833 🎀 is a Standards Track document from the IETF, dated May 2016, with ISSN 2070-1721. The authors are J. Howlett from Jisc, S. Hartman from Painless Security, and A. Perez-Mendez (Ed.) from the University of Murcia. The header doesn't list any obsoletes or updates entries, so it doesn't replace or change any earlier RFC. 💜
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 2016Abstract 🦋
okay so this doc is about using SAML with RADIUS 🧚, specifically inside the ABFAB architecture (Application Bridging for Federated Access Beyond web). it defines two RADIUS attributes 🎀, a SAML binding 🔗, a SAML name identifier format 🏷️, two SAML profiles 📋, and two SAML confirmation methods ✅. the attributes let you wrap SAML Assertions and protocol messages inside RADIUS, so SAML entities can talk to each other using the binding 💬.
the two profiles cover ABFAB authentication and assertion Query/Request. basically a Relying Party can ask for authentication of users or machines (clients), or ask for assertions about them 🙌. those clients can be named with a Network Access Identifier (NAI) name identifier format 🪪. and the subject confirmation methods let you send requests about someone who already got authenticated, without having to name them as the subject again 💅.
ngl the artifacts here aren't ABFAB-only 🌈. they can be used in any Authentication, Authorization, and Accounting (AAA) scenario, like network access control 🛡️.
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.
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.
Copyright Notice 💖
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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 ................................................321. Introduction 🌷
okay so ABFAB (Application Bridging for Federated Access Beyond web) [RFC7831] needs to carry around SAML Assertions and protocol messages a lot 🫶.
SAML usually only does HTTP-based transports, which are called bindings [OASIS.saml-bindings-2.0-os] 🌐. those are mostly built for the SAML V2.0 web browser single sign-on profile [OASIS.saml-profiles-2.0-os]. but ABFAB wants federated identity to go beyond the web and into other apps, by building on the Authentication, Authorization, and Accounting (AAA) framework 🚀. so SAML also has to plug into AAA and protocols like RADIUS [RFC2865] and Diameter [RFC6733], not just HTTP 💅.
in summary, this document specifies:
- Two RADIUS attributes to encapsulate SAML Assertions and protocol messages, respectively. 🎀
- A SAML RADIUS binding that defines how SAML Assertions and protocol messages can be transported by RADIUS within a SAML exchange. 🔁
- A SAML name identifier format in the form of a Network Access Identifier. 🪪
- A profile of the SAML Authentication Request Protocol that uses the SAML RADIUS binding to effect SAML-based authentication and authorization. 🔐
- 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. 🔎
- Two SAML subject confirmation methods for indicating that a user or machine client is the subject of an assertion. 👑
this doc follows the rules set by [OASIS.saml-bindings-2.0-os] and [OASIS.saml-profiles-2.0-os] for making new SAML bindings and profiles, plus the other SAML conventions, whether they're formal or just common practice 📝. the big thing is the "Required Information" section for the binding (Section 4.1) and profiles (Sections 7.1 and 8.1) 📋. that section lists:
- A URI that uniquely identifies the protocol binding or profile. 🆔
- Postal or electronic contact information for the author. 📮
- A reference to previously defined bindings or profiles that the new binding updates or obsoletes. 🔄
- For a profile, any SAML confirmation method identifiers defined and/or utilized by the profile. ✅
1.1. Terminology 🧠
this doc uses words from a bunch of related standards, and they all call the same things different names 😭. so generally we go with the ABFAB term for the entity, as described in [RFC7831] 💜. here's a table that puts all the names side by side (in this doc, "NAS" means a network access server, and "AS" means an authentication 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: Terminology2. Conventions 📏
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]. 🎯
3. RADIUS SAML Attributes 🎀
okay so the SAML RADIUS binding in Section 4 of this doc uses two attributes to carry SAML Assertions and protocol messages [OASIS.saml-core-2.0-os] 🎁. because these structures are usually pretty big, the attributes use the "Long Extended Type" format [RFC6929] to wrap up their data 📦. and RADIUS entities MUST NOT include both attributes in the same RADIUS message, because they're exclusive alternatives for carrying SAML info 🙅♀️✨.
3.1. SAML-Assertion Attribute ✨
okay so this attribute is the one that carries a whole SAML Assertion 🎀 Here's what the packet layout looks like:
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 FormatHere's the breakdown, bestie 🦋
- Type:
245 - Length:
>= 5 - Extended-Type:
1 - M (More): as described in [RFC6929] 💅
- Reserved: as described in [RFC6929] 🌸
- Value: one or more octets encoding a SAML Assertion ✨
3.2. SAML-Protocol Attribute 💜
this one is the sibling, but for a SAML protocol message 🧚 same layout, different vibe:
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- Type:
245 - Length:
>= 5 - Extended-Type:
2 - M (More): as described in [RFC6929] 💖
- Reserved: as described in [RFC6929] 🫶
- Value: one or more octets encoding a SAML protocol message 🍓
4. SAML RADIUS Binding ✨👑
this is the main event 😭 The SAML RADIUS binding spells out how RADIUS [RFC2865] can be used so a RADIUS client and server can swap SAML Assertions and protocol messages. Iconic, honestly 💅
4.1. Required Information 🎀
- Identification:
urn:ietf:params:abfab:bindings:radius - Contact information:
iesg@ietf.org - Updates:
None.
4.2. Operation 🌈
okay, so here's the trust thing 🔥 In this spec, the Relying Party (RP) MUST trust any statement in the SAML messages from the Identity Provider (IdP) the same way it trusts info sitting in RADIUS attributes. Both of these entities MUST trust the RADIUS infrastructure to give them integrity for the SAML messages. Big trust energy 🫶
So, it is REQUIRED that the RADIUS exchange be protected with Transport Layer Security (TLS) encryption for RADIUS [RFC6614], which gives confidentiality and integrity protection. The only exception is when you use other methods to get those guarantees, like IPsec tunnels or a sufficiently secure internal network 🦋
Implementations of this profile can use mechanisms that let longer SAML messages ride over RADIUS transports. Examples are fragmentation of RADIUS packets [RFC7499], or larger packets for RADIUS over TCP [RADIUS-Large-Pkts] 🚀
There are two system models for SAML over RADIUS 🧚 The first is a request-response model, which uses the RADIUS SAML-Protocol attribute from Section 3 to wrap up the SAML protocol messages.
- The RADIUS client, acting as an RP, sends a SAML request element inside a RADIUS Access-Request message. This message MUST include a single instance of the RADIUS User-Name attribute, and its value MUST conform to the Network Access Identifier [RFC7542] scheme. The RP MUST NOT include more than one SAML request element 💜
- The RADIUS server, acting as an IdP, sends back a SAML protocol message inside a RADIUS Access-Accept or Access-Reject message. These messages wrap up the RADIUS exchange, so this is the only chance the IdP gets to respond in this exchange. The IdP MUST NOT include more than one SAML response. An IdP that refuses to do a message exchange with the RP can silently discard the SAML request. That can be followed by a RADIUS Access-Reject, since the same conditions that make the IdP discard the SAML request may also make the RADIUS server fail to authenticate 😬
The second system model lets a RADIUS server acting as an IdP use the RADIUS SAML-Assertion attribute from Section 3 to wrap up an unsolicited SAML Assertion. This attribute MUST be included in a RADIUS Access-Accept message. When it's included, the attribute MUST contain a single SAML Assertion 🍓
RADIUS servers MUST NOT include both the SAML-Protocol and the SAML-Assertion attribute in the same RADIUS message. If an IdP is answering a SAML request, the first system model is the one to use. An IdP MAY ignore a SAML request and send an unsolicited assertion using the second system model (so, the RADIUS SAML-Assertion attribute) 🌸
In either system model, IdPs SHOULD return a RADIUS State attribute as part of the Access-Accept message, so future SAML queries or requests can run against the same context of an authentication exchange 🎀
This binding is meant to be composed with other uses of RADIUS, like network access. So other arbitrary RADIUS attributes MAY be used in either the request or response ✨
If there's a SAML processing error, the RADIUS server MAY include a SAML response message with a suitable value for the <samlp:Status> element inside the Access-Accept or Access-Reject packet, to let the client know. Or, the RADIUS server can respond without a SAML-Protocol attribute at all 💀
4.3. Processing of Names 🧚
SAML entities using profiles that make use of this binding will usually have both the SAML and AAA names of their correspondents. Often these entities need to apply policies using those names (for example, when deciding whether to release attributes). These policies are often security-sensitive, so it matters a lot that policy is applied to these names consistently 😤
4.3.1. AAA Names 💅
These rules are about how SAML entities using profiles that make use of this binding process AAA names.
- IdPs SHOULD apply policy based on the RP's identity associated with the RADIUS Access-Request.
- RPs SHOULD apply policy based on the NAI realm associated with the RADIUS Access-Accept.
4.3.2. SAML Names 🌈
These rules are about how SAML entities using profiles that make use of this binding process SAML names.
IdPs MAY apply policy based on the RP's SAML entityID. In that case, at least one of the following methods is required to build a relationship between the SAML name and the AAA name of the RP:
- RADIUS client identity in trusted SAML metadata (as described in Section 4.3.3).
- RADIUS client identity in trusted digitally signed SAML request.
A digitally signed SAML request without the RADIUS client identity is not enough 🙈 A malicious RADIUS entity can watch a SAML message and drop it into a different RADIUS message without the consent of the issuer of that SAML message. If an IdP processed the SAML message without confirming it applied to the RADIUS message, the wrong policy could get used. Yikes 😭
RPs MAY apply policy based on the SAML issuer's entityID. In that case, at least one of the following methods is required to build a relationship between the SAML name and the AAA name of the IdP:
- RADIUS realm in trusted SAML metadata (as described in Section 4.3.3).
- RADIUS realm in trusted digitally signed SAML response or assertion.
A digitally signed SAML response alone is not enough, for the same reasons given above for SAML requests 💜
4.3.3. Mapping of AAA Names in SAML Metadata 🦋
This section adds extensions to the SAML metadata schema [OASIS.saml-metadata-2.0-os] that are required to represent the AAA names tied to a particular <EntityDescriptor> element ✨
In SAML metadata, one entity can play lots of different roles to support multiple profiles. This document defines two new roles, RADIUS IdP and RADIUS RP, which need two new subtypes of RoleDescriptorType: RADIUSIDPDescriptorType and RADIUSRPDescriptorType. These subtypes hold the extra elements needed to represent AAA names for IdP and RP entities, respectively 🎀
4.3.3.1. RADIUSIDPDescriptorType 🧚
The RADIUSIDPDescriptorType complex type extends RoleDescriptorType with elements common to IdPs that support RADIUS. It has these extra elements:
<RADIUSIDPService>[Zero or More]: zero or more elements of type EndpointType that describe RADIUS endpoints associated with the entity.<RADIUSRealm>[Zero or More]: zero or more elements of type string that represent the acceptable values of the RADIUS realm associated with the entity, taken from the realm part of the RADIUS User-Name attribute.
Here's the schema fragment that defines the RADIUSIDPDescriptorType complex type 💖
<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 Schema4.3.3.2. RADIUSRPDescriptorType ✨
okay so the RADIUSRPDescriptorType complex type extends RoleDescriptorType 💅 and it's basically the RP's version of the RADIUS vibe. It keeps all the common RP stuff and then adds its own extra elements on top 🎀 Here's the whole squad:
<RADIUSRPService>[Zero or More]: zero or more elements of type EndpointType that describe the RADIUS endpoints connected to the entity 🌸<RADIUSNasIpAddress>[Zero or More]: zero or more string elements for the acceptable values of the RADIUS NAS-IP-Address or NAS-IPv6-Address attributes linked to the entity 🦋<RADIUSNasIdentifier>[Zero or More]: zero or more string elements for the acceptable values of the RADIUS NAS-Identifier attribute tied to the entity 💜<RADIUSGssEapName>[Zero or More]: zero or more string elements for the acceptable values of the GSS-API Mechanism for the Extensible Authentication Protocol (GSS-EAP) acceptor name tied to the entity 🧚. The format for this name is described in Section 3.1 of [RFC7055], and Section 3.4 of [RFC7055] explains how that name gets decomposed and transported using RADIUS attributes 🫶
Here's the schema fragment for RADIUSRPDescriptorType, no cap it's giving very precise energy 🔥
<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 Schema4.3.4. Example of SAML Metadata That Includes AAA Names 🌈
okay now for the examples!! Figures 5 and 6 show metadata with AAA names for an IdP and an RP 😭 The IdP's SAML name is "https://IdentityProvider.com/", but its RADIUS realm is "idp.com". The RP's SAML name is "https://RelyingParty.com/SAML", and its GSS-EAP acceptor name is "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<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 RP4.4. Use of XML Signatures 🔐
this binding calls for SAML elements that support XML signatures, so the vibe is "signatures are a thing here" 🖋️ For interop, implementations of this binding MUST support a default configuration that doesn't require XML signatures at all 🫶 Implementations MAY choose to use XML signatures if they want to 💅
4.5. Metadata Considerations 📚
so this binding, plus the profiles, are mostly meant to be used without metadata 🌸 In that setup, the RADIUS infrastructure handles integrity and naming for the SAML messages and assertions, and RADIUS configuration sets the policy, like which attributes get accepted from an RP and which ones an IdP sends 🎀
Nevertheless, if metadata is used, the roles described in Section 4.3.3 MUST be present 🫶
5. Network Access Identifier Name Identifier Format 🦋
URI: urn:ietf:params:abfab:nameid-format:nai
this one indicates that the content of the element is in the form of a Network Access Identifier (NAI), using the syntax described by [RFC7542] 💜
6. RADIUS State Confirmation Method Identifiers 🧚
URI: urn:ietf:params:abfab:cm:user
URI: urn:ietf:params:abfab:cm:machine
these say the subject is the system entity (either the user or the machine) that was authenticated by a previously sent RADIUS Access-Accept message, identified by the value of that message's State attribute 🔥
7. ABFAB Authentication Profile 👑
okay this is the big one ✨ In the scenario this profile supports, a client running a User Agent asks for access to an RP. The RP uses RADIUS to authenticate the client. Specifically, the RP (acting as a RADIUS client) tries to validate the client's credentials against a RADIUS server that's acting as the client's IdP 💅 If the IdP successfully authenticates the client, it makes an authentication assertion that the RP consumes. This assertion MAY include a name identifier that the RP and the IdP can use to refer to the client 🦋
7.1. Required Information 📝
- Identification:
urn:ietf:params:abfab:profiles:authentication - Contact information: iesg@ietf.org
- SAML confirmation method identifiers: the SAML V2.0 "RADIUS State" confirmation method identifiers, either
urn:ietf:params:abfab:cm:userorurn:ietf:params:abfab:cm:machine, are used by this profile 🌈 - Updates: None.
7.2. Profile Overview 🌸
To implement this scenario, this profile of the SAML Authentication Request Protocol MUST be used together with the SAML RADIUS binding defined in Section 4 🫶
this profile is based on the SAML V2.0 web browser single sign-on profile [OASIS.saml-profiles-2.0-os], but there are some important differences, specifically:
- Authentication: this profile doesn't require 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 💖
- Bindings: this profile doesn't use HTTP-based bindings. Instead, all SAML protocol messages get transported using the SAML RADIUS binding defined in Section 4. This is meant to cut down the number of bindings implementations have to support to be interoperable 🎀
- Requests: the profile doesn't let the RP name the
<saml:Subject>of the<samlp:AuthnRequest>. This is meant to keep implementation and interop simple ✨ - Responses: the profile only lets the IdP return a single SAML message or assertion that MUST contain exactly one authentication statement. Other statements can be included in this assertion at the IdP's discretion. Again, this is meant to simplify implementation and interop 🧚
here's the message flow for this profile, bestie 👀
Client Relying Party Identity Provider
| | |
| (1) | |
| - - - - - - - - - > | |
| | |
| | (2) |
| | - - - - - - - - - - - - > |
| | |
| (3) | |
| < - - - - - - - - - |- - - - - - - - - - - - - >|
| | |
| | (4) |
| | < - - - - - - - - - - - - |
| | |
| (5) | |
| < - - - - - - - - - | |
| | |
V V V
Figure 7: Flow of MessagesThe profile describes the following steps. Within an individual step there may be one or more actual message exchanges 💅
- Client request to RP (Section 7.3.1): in step 1, the client, via a User Agent, requests a secured resource at the RP. The RP figures out that no security context exists for the client and kicks off the authentication process 🦋
- RP issues
<samlp:AuthnRequest>to IdP (Section 7.3.2). In step 2, the RP may optionally send a<samlp:AuthnRequest>message to be delivered to the IdP using the SAML-Protocol RADIUS attribute 🌸 - IdP identifies client (Section 7.3.3). In step 3, the client gets authenticated and identified by the IdP, while honoring any requirements the RP put in the
<samlp:AuthnRequest>message, if it sent one 🫶 - IdP issues
<samlp:Response>to RP (Section 7.3.4). In step 4, the IdP sends 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 didn't send a<samlp:AuthnRequest>, the IdP issues an unsolicited<samlp:Assertion>, as described in Section 7.4.4 💜 - RP grants or denies access to client (Section 7.3.5). In step 5, once it has the IdP's response, the RP can reply to the client with its own error, or it can set up its own security context for the client and return the requested resource 👑
7.3. Profile Description 📖
the ABFAB Authentication Profile is a profile of the SAML V2.0 Authentication Request Protocol [OASIS.saml-core-2.0-os]. Where the two specifications conflict, the ABFAB Authentication Profile takes precedence 🔥
7.3.1. Client Request to Relying Party 🌈
the profile starts with an arbitrary client request to the RP. There are no restrictions on the form of that request. The RP is free to use any means it likes to link the later interactions back to the original request. The RP, acting as a RADIUS client, tries to authenticate the client ✨
7.3.2. Relying Party Issues <samlp:AuthnRequest> to Identity Provider 🧚
the RP uses RADIUS to talk to 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 🦋
Profile-specific rules for the contents of the <samlp:AuthnRequest> element are given in Section 7.4.1 🎀
7.3.3. Identity Provider Identifies Client ✨
okay so the IdP has to figure out who the client is using a RADIUS authentication method, or it's giving error 🙅♀️. The IdP MUST establish the identity of the client using a RADIUS authentication method, or else it will return an error. Now if the RP sent a ForceAuthn attribute in the <samlp:AuthnRequest> element and it's present and true, the IdP MUST freshly establish this identity 🔐. No vibing off whatever session state it already has with the client, like TLS state it could use 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. Main character energy for the IdP, honestly 💅
7.3.4. Identity Provider Issues <samlp:Response> to Relying Party 💌
the IdP MUST conclude the authentication in a manner consistent with the RADIUS authentication result, no exceptions 🙅♀️. 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 gets delivered to the RP using the SAML RADIUS binding described in Section 4 🚚
Profile-specific rules about what goes inside the <samlp:Response> element live in Section 7.4.2, so go look there 👀
7.3.5. Relying Party Grants or Denies Access to Client 🔑
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]. Anything the RP does with those assertions after that is at its discretion 💖, but it has to respect any restrictions inside the assertions themselves, plus any out-of-band policy that was already set up between the IdP and the RP. Rules are rules, bestie 🫶
7.4. Use of Authentication Request Protocol 🎀
this profile is built on the Authentication Request Protocol defined in [OASIS.saml-core-2.0-os]. In the nomenclature of actors listed 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. Very clean cast list 🧚
7.4.1. <samlp:AuthnRequest> Usage 📨
The RP MUST NOT include a <saml:Subject> element in the request. That's the vibe check: the authenticated RADIUS identity is what identifies the client to the 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] 📜
If the RP wants to let the IdP create a brand new identifier for the client when none exists yet, it MUST include a <saml:NameIDPolicy> element with the AllowCreate attribute set to "true". Otherwise, only a client the IdP has already given an identifier that the RP can use can get authenticated successfully. No new identifier, no entry 🚪
The <samlp:AuthnRequest> message MAY be signed. Authentication and integrity are also provided by the SAML RADIUS binding, so it's double-covered 🛡️
7.4.2. <samlp:Response> Message Usage 💅
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. Either way, the RP gets the tea ☕
If the IdP wants 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 isn't tied to a request at all), the <samlp:Response> element has to follow these constraints:
- It MAY be signed.
- It MUST contain exactly one assertion. The
<saml:Subject>element of this assertion MUST refer to the authenticated RADIUS user 👑 - 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 🧾 - 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. No promises, just vibes 🌸
7.4.3. <samlp:Response> Message Processing Rules 🔍
The RP MUST do the following:
- 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. - 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. 🙅♀️ - 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. Time's up, babe ⏰ - Verify that any assertions relied upon are valid according to processing rules specified in [OASIS.saml-core-2.0-os].
- 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. Bye bye, sketchy assertions 🗑️
7.4.4. Unsolicited Responses 📬
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. Unsolicited means no InResponseTo, period 🦋
7.4.5. Use of the SAML RADIUS Binding 🔐
It is RECOMMENDED that the RADIUS exchange be protected using TLS encryption for RADIUS [RFC6614] to provide confidentiality and integrity protection. Lowkey a must-have for keeping things private 🤫
7.4.6. Use of XML Signatures ✍️
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. Choice is the moral of this story 💜
7.4.7. Metadata Considerations 🗂️
There are no metadata considerations particular to this profile, aside from those applying to the use of the RADIUS binding. Nothing extra to see here ✨
8. ABFAB Assertion Query/Request Profile 🧚♀️
this profile builds on the SAML V2.0 Assertion Query/Request Profile defined by [OASIS.saml-profiles-2.0-os]. That profile describes how to use 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].
Even though the SAML V2.0 Assertion Query/Request Profile doesn't care what binding is underneath, it's still super useful to describe how to use the SAML RADIUS binding from Section 4 of this document 🎯. That helps promote interoperable implementations, especially since the SAML V2.0 Assertion Query/Request Profile is mostly talked about and implemented with the SOAP binding.
8.1. Required Information 📋
Identification: urn:ietf:params:abfab:profiles:query
Contact information: iesg@ietf.org
Description: Given below.
Updates: None.
8.2. Profile Overview 🗺️
Just like the SAML V2.0 Assertion Query/Request Profile in [OASIS.saml-profiles-2.0-os], the message exchange and basic processing rules here are mostly defined by Section 3.3 of [OASIS.saml-core-2.0-os]. That section defines the messages being exchanged, and the binding used to send them does the rest. The SAML RADIUS binding in this document is what maps the message exchange onto RADIUS. Unless it's specifically noted here, every requirement in those specs still applies 🫶
Figure 8 below shows the basic template for the Query/Request Profile 👇
Relying Party Identity Provider
(SAML requester) (SAML responder)
| |
| (1) |
| - - - - - - - - - - - - - - - - - - - - - - - > |
| |
| (2) |
| < - - - - - - - - - - - - - - - - - - - - - - - |
| |
V V
Figure 8: Basic Template for Query/Request ProfileThe profile describes these steps:
- Query/Request issued by RP: In step 1, an RP kicks things off by sending an
<AssertionIDRequest>,<SubjectQuery>,<AuthnQuery>,<AttributeQuery>, or<AuthzDecisionQuery>message to a SAML authority 📤 <Response>issued by SAML authority: In step 2, the responding SAML authority (after processing the query or request) sends a<Response>message back to the RP 📥
8.3. Profile Description 🌷
8.3.1. Differences from the SAML V2.0 Assertion Query/Request Profile 🔀
This profile is identical to the SAML V2.0 Assertion Query/Request Profile, with the following exceptions:
- 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. - 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.
- 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.
8.3.2. Use of the SAML RADIUS Binding 📡
The RADIUS Access-Request sent by the RP:
- MUST include an instance of the RADIUS Service-Type attribute, having a value of Authorize-Only.
- SHOULD include the RADIUS State attribute, where this Query/Request pertains to a previously authenticated client.
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. State wins, every time 🏆
It is RECOMMENDED that the RADIUS exchange be protected using TLS encryption for RADIUS [RFC6614] to provide confidentiality and integrity protection. Same energy as before, honestly 🔒
8.3.3. Use of XML Signatures ✍️
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. Still the choice, bestie 💖
8.3.4. Metadata Considerations 🗂️
There are no metadata considerations particular to this profile, aside from those applying to the use of the RADIUS binding. Nothing new here either 🌈
9. Privacy Considerations 🔒✨
Okay bestie, privacy time! 🫶 The profiles in this doc let an RP (relying party) ask for specific info about the client, and the IdP gets to disclose that info back. So IdPs MUST apply policy to decide what gets released to a particular RP 💅. The client's identity is usually hidden from the RP unless the IdP provides it 🙈. The RP does usually know the realm of the IdP though, because it needs that to route the RADIUS packets to the right destination 🗺️.
The info the IdP releases can include generic attributes like affiliation, which lots of clients share. But even those generic bits can help pin down one specific client 👀. Other kinds of attributes might let an RP link the same client across different sessions 🔗. And some attributes could let a group of RPs link the client between each other, or link the client to personally identifiable information 😭.
These profiles don't give a client a direct way to say what info gets released 🙅♀️. That stuff can be expressed out of band, for example as part of the enrollment process 📝.
The RP may disclose privacy-sensitive info about itself as part of the request, but that's pretty unlikely in typical deployments 🤷♀️.
If RADIUS proxies are used and encryption is not used, the attributes disclosed by the IdP are visible to the proxies. That's a significant privacy exposure in some deployments 💀. Ongoing work is exploring ways to set up 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 🧐.
Using TLS to give the RADIUS exchange confidentiality is strongly encouraged 🌸. Without it, passive eavesdroppers can observe the assertions 👁️.
10. Security Considerations 🛡️💖
Serious moment, let's go 😤. In this specification, the RP MUST trust any statement in the SAML messages from the IdP the same way it trusts info in RADIUS attributes. These entities MUST trust the RADIUS infrastructure to provide integrity of the SAML messages 🧱.
And the RP MUST apply policy and filter the info based on what the IdP is permitted to assert, and on how much trust is reasonable to place in proxies between them 🚦.
XML signatures and encryption are provided as an OPTIONAL mechanism for end-to-end security ✍️. They can protect SAML messages from being modified by proxies in the RADIUS infrastructure 🛑. These mechanisms are not mandatory to implement, so it's not a must-have 🙃. 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 🕰️.
11. IANA Considerations 📚🎀
11.1. RADIUS Attributes
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 ✨.
Specifically, this document defines two new RADIUS attributes, "SAML-Assertion" and "SAML-Protocol" (see Section 3). They got the values 245.1 and 245.2 from the long extended space [RFC6929] 🦋:
Type Ext. Type Name Length Meaning
---- --------- -------------- ------ ------------------------
245 1 SAML-Assertion >=5 Encodes a SAML Assertion
245 2 SAML-Protocol >=5 Encodes a SAML protocol
message11.2. ABFAB Parameters
A brand-new top-level registry has been created, called "Application Bridging for Federated Access Beyond Web (ABFAB) Parameters" 🎉.
Inside that top-level registry, a sub-registry called "ABFAB URN Parameters" has been created. Registration in this registry is via IETF Review or Expert Review procedures [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've 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. Honestly? Today, such requests would not typically be approved 💀.
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:
+-------------------------+-----------+
| 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 Parameters11.3. Registration of the ABFAB URN Namespace
IANA has registered the "abfab" URN sub-namespace in the IETF URN sub-namespace for protocol parameters defined in [RFC3553] 🏷️.
Registry Name: abfab
Specification: RFC 7833 (this document)
Repository: ABFAB URN Parameters (Section 11.2)
Index Value: Sub-parameters MUST be specified in UTF-8, using standard URI encoding where necessary 🔑.
12. References 📖💜
12.1. Normative References
[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-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-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-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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <http://www.rfc-editor.org/info/rfc7542>.
12.2. Informative References
[RADIUS-Large-Pkts] Hartman, S., "Larger Packets for RADIUS over TCP", Work in Progress, draft-ietf-radext-bigger-packets-07, April 2016.
[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>.
[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>.
[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>.
[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>.
[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>.
[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/>.
Appendix A. XML Schema ✨
okay so this part is the actual schema 🎀 It formally defines the urn:ietf:params:xml:ns:abfab namespace from this doc, written to follow [W3C.REC-xmlschema-1]. Validating XML against it is optional, but the schema is the normative definition of what it describes. If it ever disagrees with the prose, the schema wins 👑
<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 want to give a huge shout-out to the OASIS Security Services (SAML) Technical Committee, and Scott Cantor especially, for helping out with all the SAML stuff 🙌
they also thank Jim Schaad, Leif Johansson, Klaas Wierenga, Stephen Farrell, Gabriel Lopez-Millan, and Rafa Marin-Lopez, who gave really valuable comments on this doc 💜
Authors' Addresses 📮
Josh Howlett
Jisc
Lumen House, Library Avenue, Harwell
Oxford OX11 0SG
United Kingdom
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
Phone: +34 868 88 46 44
Email: alex@um.es📦 where this page comes from
- ietf: rfc7833 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms