4 General-Purpose IdPs

In order to make subscriber accounts available through an IdP, the subscriber accounts need to be provisioned at the IdP. The means by which the subscriber account is provisioned to the IdP SHALL be disclosed in the trust agreement.

Due to the requirement for the IdP to be able to authenticate the subscriber, the IdP is often a service of the CSP and has some level of access to the attributes and authenticators in the subscriber account. Such IdPs are generally in the same security domain as the identity and access management system that houses the subscriber account.

In other cases, one or more authenticators in the subscriber account can be verified outside of the security domain, such as authenticators tied to a common PKI. In these cases, the IdP can pull subscriber attributes and account information from the authenticator to provide a federated login to RPs.

The IdP augments the subscriber account with federation-specific attributes, such as a federated identifier. The IdP can collect additional attributes for federation purposes subject to the privacy and storage requirements enumerated by the trust agreement.

The CSP can provide attributes from the subscriber account to the IdP as attribute values, derived attribute values, or attribute bundles. The CSP SHALL sign attribute bundles issued to the IdP.

After the subscriber account is provisioned to the IdP, the CSP is party to the trust agreement but is not directly involved in the federation transaction. Consequently, even if the RP fetches attributes through an identity API that is hosted by the CSP, the identity API is considered a function of the IdP and not the CSP for the purposes of these guidelines.

A federation transaction that involves a general-purpose IdP establishes the subscriber account at the IdP and culminates in an authenticated session for the subscriber at the RP. This process is shown in Fig. 6.

Fig. 6. Federation overview

A federation transaction is a multi-stage process:

Federated transactions are enabled by trust agreements, as described in Sec. 3.5. These trust agreements define which parties are fulfilling which roles, the terms under which the parties operate with each other, permission for the systems in question to connect, and the terms under which the parties interact with each other. A single trust agreement often covers multiple federation transactions. The list of available subscriber identity attributes, derived attributes, and attribute bundles is established in the trust agreement, though the decision of which attributes are released to a given RP for a given transaction is finalized during the federation transaction itself. The final set of attributes, derived attribute values, and attribute bundles to be passed to the RP is selected by processing the following:

The IdP and RP also need to perform discovery and registration to establish the cryptographic keys and identifiers that are needed for information to be securely exchanged between the parties in the federation protocol (see Sec. 4.4). While there may be an existing policy decision that represents a permission to connect (through a pre-established trust agreement), this step entails a connection and integration at the technical level. At any FAL, this stage can occur before subscribers try to access the RP. At FAL1 or FAL2, this stage could alternatively occur in response to a subscriber’s attempt to use an IdP at an RP.

In a federated identity transaction, the IdP is the source of identity and authentication attributes for the RP. The normal flow of information for a federation transaction is from the IdP to the RP. Due to the directional nature of this information flow, the IdP is considered to be upstream of the RP and the RP is considered to be downstream of the IdP. It is also possible for additional information to flow back up from the RP, particularly through the use of shared signals, as discussed in Sec. 4.8.

Trust agreements for general-purpose IdPs are generally expected to be established between the RP and the IdP, where the RP relies on the identity of the IdP to provide the basis of trust for federation transactions. It is expected that the trust agreement between the CSP and IdP is established independent of the federation transaction.

Trust agreements for general-purpose IdPs SHALL be established either:

To perform a federation transaction with a general-purpose IdP, the RP has to perform discovery and registration with that IdP, as discussed in Sec. 3.6.

The RP SHALL associate the assertion validation keys and other relevant configuration information with the IdP’s identifier, as stipulated by the trust agreement. If the validation keys and configuration information are retrieved over a network connection, request and retrieval SHALL be made over an authenticated protected channel from a location that is associated with the IdP’s identifier by the trust agreement. In many federation protocols, this is accomplished by the RP fetching the public keys and configuration data from a URL that is specified in the trust agreement as being controlled by the IdP or offered on the IdP’s behalf. It is also possible for the RP to be configured directly with this information in a manual fashion, whereby the RP’s system administrator enters the IdP information directly into the RP software’s configuration.

In some systems, particularly those governed by multi-lateral trust agreements, the discovery process can be facilitated by a third-party discovery and registration service.

Additionally, the RP SHALL register its information with either the IdP or an authority that the IdP trusts, as stipulated by the trust agreement. In many federation protocols, the RP is assigned an identifier during this stage, which the RP will use in subsequent communication with the IdP.

Parties that seek to federate MAY use a trusted third party to facilitate the discovery and registration processes if that trusted third party is identified in the trust agreement. For example, a consortium could use a hosted service that collects the configuration records of IdPs and RPs directly from participants. Instead of going to the IdP directly for its discovery record, an RP would instead go to this service and retrieve the key material for its target IdP. The IdP would, in turn, go to this service to find the identifiers and configuration information for RPs that are needed to connect. This service is often managed by the same party that fulfills the federation authority role in multilateral trust agreements, as discussed in Sec. 3.5.2.

In a federation context, the IdP acts as the verifier for authenticators bound to the subscriber account, as described in [SP800-63B]. Verification of one or more authenticators creates an authentication event that begins the authenticated session at the IdP. This authentication event serves as the basis of the IdP’s claim that the subscriber is present.

The IdP SHALL require the subscriber to have an authenticated session before any of the following events:

Additional requirements for session management and reauthentication are discussed in Sec. 4.7.

The authorized party stipulated by the trust agreement SHALL decide whether a federation transaction proceeds and, therefore, whether an assertion is issued and attributes are released to the RP. This decision can be calculated in a variety of ways, including:

The applicability of an allowlist, blocklist, or runtime decision can be influenced by aspects of the federation transaction, including the identity of the IdP and RP, the subscriber attributes requested, the xAL required, and other factors. These decisions can be facilitated by risk management systems, federation authorities, and local system policies.

For a non-normative example of an RP that has been allowlisted at an IdP for a set of subscribers to facilitate single sign-on for an enterprise application, see Sec. 9.5.

The IdP SHALL provide effective mechanisms for the redress of subscriber complaints or problems (e.g., subscriber identifies an inaccurate attribute value). See Sec. 3.5.3 for additional requirements and considerations for redress mechanisms.

In a federated environment, the RP manages its sessions separately from any sessions at the IdP. The assertion is related to both sessions, but its validity period is ultimately independent of them.

As shown in Fig. 10, an assertion is created during an authenticated session at the IdP, and processing an assertion creates an authenticated session at the RP. The validity time window of an assertion is used to manage the RP’s processing of the assertion but does not indicate the lifetime of the authenticated session at the IdP or RP. If a request comes to the IdP for a new federation transaction while the subscriber’s session is still valid at the IdP, a new and separate assertion would be created with its own validity time window. Similarly, after the RP consumes the assertion, the validity of the RP’s session is independent of the validity of the assertion. In most cases, the authenticated session at the RP will far outlive the validity of the assertion. Access granted to an identity API is likewise independent of the validity of the assertion or the lifetime of the authenticated session at the RP.

Fig. 10. Session lifetimes

The IdP terminating the subscriber’s session at the IdP will not necessarily terminate any sessions that subscriber might have at downstream RPs. The RP and IdP MAY communicate end-session events to each other if supported by the federation protocol or through shared signaling (see Sec. 4.8).

At the time of a federated transaction request, the subscriber could have a pre-existing authenticated session at the IdP that MAY be used to generate an assertion to the RP. The IdP SHALL communicate to the RP any information that the IdP has regarding the recency of the subscriber’s latest authentication event at the IdP, and the RP MAY use this information to make authorization and access decisions. Depending on the capabilities of the federation protocol in use, the IdP SHOULD allow the RP to request that the subscriber provide a fresh authentication at the IdP, such as requesting a maximum time since the subscriber’s last authentication event. For example, suppose that the subscriber authenticates at the IdP for one transaction. The subscriber then starts a federation transaction at the RP 30 minutes later. Depending on xAL requirements, the subscriber’s existing session at the IdP can be used to avoid prompting the subscriber for their authenticators. The resulting assertion to the RP will indicate that the last time the subscriber authenticated to the RP was 30 minutes in the past. The RP can then use this information to determine whether this is reasonable for the RP’s needs. If the authentication time is not sufficient for the RP, the RP can request the IdP to prompt the subscriber for a fresh authentication event.

If an RP is granted access to an identity API at the same that time the RP receives an assertion, the lifetime of the access to the identity API is independent of the lifetime of the assertion. As a consequence, the RP’s ability to successfully fetch additional attributes through an identity API SHALL NOT be used to establish or extend a session at the RP. Likewise, the inability to access an identity API SHOULD NOT be used to end the session at the RP.

While an RP could also be granted access to other non-identity APIs during the federation transaction (e.g., a subscriber’s calendar), non-identity APIs are out of the scope of these guidelines.

The RP MAY terminate its authenticated session with the subscriber or restrict access to the RP’s functions if the assertion, authentication event, or attributes do not meet the RP’s requirements. For example, if an RP is configured to allow access to certain high-risk functionality only if the federation transaction was at FAL3, but the incoming assertion only meets the requirements for FAL2, the RP could decide to deny access to the high-risk functionality while allowing access to a lower risk functionality, or the RP could choose to terminate the session entirely.

See [SP800-63B] Sec. 5 for more information about session management requirements that apply to both IdPs and RPs.

In some environments, it is useful for the IdP and RP to send information to each other outside of the federation transaction. These signals can communicate important changes in state between parties that would not otherwise be known, such as suspected fraud or an account status change. Shared signaling SHALL be limited to the allowable functions of the identity process, as discussed in Sec. 3.10.1. All uses of shared signaling SHALL be documented in the trust agreement and made available to the authorized party stipulated by the trust agreement. This documentation SHALL include the events under which a signal is sent, the type of information included in such a signal (including any personal information), any additional parameters sent with the signal, and the expected processing of a received signal. The use of shared signaling SHALL be subject to privacy review under the trust agreement. Shared signals SHALL NOT include personal information except what is necessary to identify the subscriber account in question (e.g., an account identifier or attributes that can be correlated by the receiving party).

Signaling from the IdP to the RP SHALL require a pre-established trust agreement. Signaling from the RP to the IdP MAY be used in both pre-established and subscriber-driven trust agreements.

The IdP SHOULD send a signal to the RP regarding the following changes to the subscriber account:

If the RP receives a signal that an RP subscriber account is suspected of compromise, the RP SHOULD review actions taken by that account at the RP for suspicious activity.

The RP SHOULD send a signal to the IdP regarding the following changes to the RP subscriber account:

If the IdP receives a signal that a subscriber account is suspected of compromise, the IdP SHALL review actions taken by that account at the IdP for suspicious activity. If suspicious activity is confirmed at the IdP, the IdP SHALL signal any additional RPs that the subscriber account was used for during the suspected time frame.

Additional signals from both the IdP and RP SHALL be subject to a security review, included in the privacy risk assessment, and addressed in the trust agreement.

If the RP allows for account linking to multiple IdPs, the RP SHALL document their practices regarding signals for linked accounts. The RP SHALL ensure that the shared signals do not reveal the identity of a subscriber’s linked IdPs.

An assertion is a statement from the IdP to the RP that contains information about an authentication event for an authenticated subscriber as well as a set of attribute values, derived attribute values, or attribute bundles about or associated with that subscriber. In addition to attribute information, assertions comprise a variety of data, including assertion metadata, information about the subscriber’s authentication at the IdP, and other information that the RP can leverage (e.g., restrictions, validity time window). While the assertion’s primary function is to authenticate the user to an RP, the information conveyed in the assertion can be used by the RP for a number of use cases (e.g., identity proofing, authorization, personalization of a website). These guidelines do not restrict RP use cases nor the type of protocol or data payload used to federate an identity, provided that the chosen solution meets all mandatory requirements contained herein.

Assertions SHALL represent a discrete authentication event of the subscriber at the IdP and SHALL be processed as a discrete authentication event at the RP.

All assertions SHALL include the following attributes:

If the RP subscriber account does not use an ephemeral provisioning process, the subscriber SHALL be identified in the assertion using a federated identifier (see Sec. 3.4) or through an account resolution process (see Sec. 3.8.2).

If the subscriber is identified using a federated identifier, the assertion SHALL include:

The following aspects of the federation transaction SHALL be provided through information contained in the assertion contents or the applicable trust agreement:

The assertion SHOULD contain additional information about the authentication method used at the IdP, if available (e.g., whether the authenticator used is phishing-resistant). Some technologies that can carry information include Vectors of Trust [RFC8485] or authentication class references in [OIDC] and [SAML].

At FAL2 and above, the assertion SHALL include:

At FAL3, the assertion SHALL include one of the following:

Assertions SHALL NOT contain subscriber authentication secrets (e.g., passwords).

Assertions MAY also include additional items, including:

The RP SHALL validate the assertion by checking that all of the following are true:

An RP that uses the federated identifier to identify the subscriber SHALL NOT treat subject identifiers as inherently globally unique across IdPs. Instead, the value of the assertion’s subject identifier is processed in a namespace under the assertion issuer’s control, as discussed in Sec. 3.4. This allows an RP to talk to multiple IdPs without incorrectly conflating subjects from different IdPs.

Any release of identity attributes to the RP is subject to the terms of the trust agreement. Section 3.10 contains privacy requirements for presenting attributes in assertions. The RP MAY be given limited access to an identity API (see Sec. 3.12.3), either in the same response as the assertion is received or through some other mechanism. The RP can use this API to fetch additional identity attributes for the subscriber that are not included in the assertion itself. These attributes are also subject to the terms of the trust agreement.

The assertion’s validity time window is the time between its issuance and its expiration. This window needs to be large enough to allow the RP to process the assertion and create a local application session for the subscriber but should not be longer than necessary for such establishment, including reasonable clock drift between the IdP and RP. Long-lived assertions have a greater risk of being stolen or replayed; a short assertion validity time window mitigates this risk. Assertion validity time windows SHALL NOT be used to limit the session at the RP. See Sec. 4.7 for more information.

When the federation transaction is initiated by the RP, the RP’s request for an assertion SHALL contain:

The RP’s request SHOULD additionally contain:

When federation transactions are initiated by the IdP (at FAL1), these requirements do not apply. Federation transactions are always initiated by the RP at FAL2 or higher.

In most federation protocols, the RP and the IdP communicate with each other in two ways, each of which can be used to pass an assertion from the IdP to the RP:

There are trade-offs with each model, but both require the proper validation of the assertion. Assertions MAY also be proxied to facilitate federation between IdPs and RPs using different presentation methods, as discussed in detail in Sec. 3.3.3.