This section is normative.
This section defines federation assurance levels (FALs) and the requirements for securing federation transactions at each FAL. In order to fulfill the requirements for a given FAL, the federation transaction SHALL meet or exceed all requirements listed for that FAL.
Each FAL is characterized by a set of requirements that increase the security as the FAL increases. These requirements are listed here and expanded in other sections of this document:
The RP is strongly protected from an attacker completing a federated transaction and initiating an authenticated session with a forged, captured, or modified assertion (see Sec. 3.11.1).
Table 1 provides a non-normative summary of requirements for each FAL. Each successive level subsumes and fulfills all of the requirements of lower levels (e.g., a federation process at FAL3 can be accepted at FAL2 or FAL1 since FAL3 satisfies all of the requirements of these lower levels). Combinations not found in Table 1 are possible, and agencies can choose to implement stronger protections in one or more areas of requirements at a given FAL.
Table 1. Federation assurance levels
| Requirement | FAL1 | FAL2 | FAL3 |
|---|---|---|---|
| Audience Restriction | Multiple RPs allowed per assertion; single RP per assertion recommended | Single RP per assertion | Single RP per assertion |
| Replay Protection | Required per RP | Required | Required |
| Assertion Injection Protection | Recommended for all transactions | Required; transaction begins at the RP | Required; transaction begins at the RP |
| Trust Agreement Establishment | Subscriber-driven or pre-established | Pre-established | Pre-established |
| Identifier and Key Establishment | Dynamic or Manual | Dynamic or Manual | Manual |
| Presentation | Bearer Assertion | Bearer Assertion | Holder-of-key Assertion or bound authenticator |
While many different federation implementation options are possible, the FAL is intended to provide clear guidance that represents increasingly secure deployment options. See [SP800-63] for details on how to choose the most appropriate FAL.
If no FAL is specified by the trust agreement or federation transaction, the requirements of this section still apply.
At all FALs, all federation transactions SHALL comply with the requirements in Sec. 3 to deliver an assertion to the RP and create an authenticated session at the RP. Examples of assertions used in federation protocols include the ID Token in OpenID Connect [OIDC] and the Security Assertion Markup Language [SAML] Assertion format.
At all FALs, the RP SHALL validate the assertion from the IdP, since the RP needs to trust the IdP to provide valid assertions representing the subscriber’s authentication event.
All parties in the federation SHALL employ security controls, as discussed in Sec. 3.11.
An IdP or RP can be capable of operating at multiple FALs simultaneously, depending on use case and needs. For example, an IdP could provide federation transactions at FAL3 to an RP that provides access to a set of high-risk functionality while simultaneously providing FAL2 to an RP with a lower risk profile. Similarly, an RP could require FAL2 for normal actions but require the subscriber to successfully complete an FAL3 federation transaction for higher impact or more sensitive actions at the RP. This capability extends to other dimensions, as an IdP could simultaneously have access to subscriber accounts that have been proofed at any IAL and allow authentication at any AAL. An RP talking to that IdP would normally have restrictions on the lowest IAL and AAL that it is willing to accept for access. As a consequence, trust agreements are required to establish the xALs allowed and required for different use cases (see Sec. 2.5).
FAL1 provides a basic level of protection for federation transactions and allows for a wide range of use cases and deployment decisions.
At FAL1, the federation protocol SHOULD apply assertion injection protection, as discussed in Sec. 3.11.1. The federation transaction SHOULD be initiated by the RP.
At FAL1, the IdP SHALL sign the assertion using approved cryptography. The RP SHALL validate the signature using the verification key associated with the expected IdP. The signature protects the integrity of the assertion contents and allows for the IdP to be verified as the source of the assertion.
At FAL1, the assertion SHALL be audience-restricted to a specific RP or set of RPs, and the RP SHALL validate that it is one of the targeted RPs for the given assertion. Each RP in the audience SHALL enforce replay protection mechanisms in the assertion to ensure that the same assertion is not accepted by a given RP multiple times. An assertion with multiple audiences could be accepted by multiple RPs but only once by each RP.
At FAL1, federated identifiers SHOULD NOT contain plaintext personal information, such as usernames, email addresses, employee numbers, etc.
At FAL1, the trust agreement MAY be established by the subscriber during the federation transaction, as discussed in Sec. 4.3.2. Alternatively, the trust agreement MAY be established prior to the federation transaction (i.e., a “pre-established” trust agreement), as discussed in Sec. 4.3.1.
FAL2 provides a high level of protection for federation transactions by requiring additional protections against a variety of attacks on federated systems, including attempts to inject assertions into a federated transaction. All of the requirements for FAL1 apply at FAL2, except where overridden by more specific or stringent requirements here.
At FAL2, the assertion SHALL be strongly protected from assertion injection attacks, as discussed in Sec. 3.11.1. The federation transaction SHALL be initiated by the RP.
At FAL2, the assertion SHALL be audience restricted to a single RP. The RP SHALL enforce replay protection mechanisms in the assertion.
At FAL2, federated identifiers SHALL NOT contain plaintext personal information, such as usernames, email addresses, employee numbers, etc.
At FAL2, a trust agreement SHALL be established prior to the federation transaction taking place (i.e., a “pre-established” trust agreement), as discussed in Sec. 4.3.1.
IdPs operated by or on behalf of federal agencies that present assertions at FAL2 or higher SHALL protect signing keys that are used in the generation of assertions with mechanisms validated at [FIPS140] Level 1 or higher.
FAL3 provides a very high level of protection for federation transactions and establishes very high confidence that the information communicated in the federation transaction matches what was established by the CSP and IdP. FAL3 also protects against the possibility of a compromised IdP by requiring additional authentication by the subscriber at the RP. All of the requirements at FAL1 and FAL2 apply at FAL3, except where overridden by more specific or stringent requirements here.
At FAL3, the RP SHALL verify that the subscriber is in control of an authenticator in addition to the assertion. This authenticator is either identified in a holder-of-key assertion (see Sec. 3.15) or is a bound authenticator (see Sec. 3.16).
At FAL3, a trust agreement SHALL be established prior to the federation transaction taking place (i.e., a “pre-established” trust agreement), as discussed in Sec. 4.3.1.
At FAL3, the identifiers for the CSP, IdP, and RP SHALL be established manually. Each identifier SHALL be uniquely associated with the verification keys for the party represented. Verification keys SHALL be transmitted through a trusted mechanism, which could be manual or automated, as indicated in the trust agreement. For example, a public-key certificate that represents the RP is uploaded to the IdP during a manual registration process. The RP is manually configured with a URL that it can use to download the IdP’s public key. Alternatively, the IdP and RP could each upload their respective public keys to a federation authority and then download each other’s keys from that same location. For a subscriber-controlled wallet, the RP could be manually configured with the URL that represents the CSP’s public key. The RP fetches this public key and uses it to validate the signature of the attribute bundle presented by the subscriber-controlled wallet. See Sec. 3.6 for more information on the establishment, management, rotation, and revocation of keys and their association with identifiers.
Since an IdP is capable of asserting the identities of many different subscribers with a variety of authenticators using a variety of federation parameters, the IAL, AAL, and FAL could vary across different federation transactions, even to the same RP.
IdPs SHALL support a mechanism for RPs to specify a set of minimum acceptable xALs as part of the trust agreement and SHOULD support the RP specifying a more strict minimum set at runtime as part of the federation transaction. When an RP requests a particular xAL, the IdP SHOULD fulfill that request, if possible, or SHOULD fail the request if it cannot fulfil the RP’s requested xALs. The IdP SHALL always indicate the resulting xAL in the assertion, even if the request has not been met. For example, if the subscriber has an active session that was authenticated at AAL1, but the RP has requested AAL2, the IdP needs to prompt the subscriber for AAL2 authentication to increase the security of the session at the IdP during the subscriber’s interaction at the IdP, if possible. The IdP sends the resulting AAL as part of the returned assertion, whether it is AAL1 (i.e., the step-up authentication request was not met) or AAL2 (i.e., the step-up authentication request was met successfully).
The IdP SHALL inform the RP of the following information for each federation transaction:
The RP obtains this xAL information from a combination of the terms of the trust agreement (see Sec. 3.5) and information included in the assertion (see Sec. 4.9 and Sec. 5.8). If the xAL is unchanging for all messages between the IdP and RP (e.g., enterprise scenarios in which all subscribers are identity-proofed at the same IAL and use the same authenticator type), the xAL information SHALL be included in the terms of the trust agreement between the IdP and RP. If the xAL could be within a range of possible values specified by the trust agreement, then sufficient information SHALL be included as part of the assertion contents to allow the RP to determine the xALs.
The IdP MAY indicate that no claim is made to the IAL or AAL for a given federation transaction. In such cases, no default value is assigned to the resulting xAL by the RP. That is, a federation transaction without an IAL declaration in either the trust agreement or the assertion is functionally considered to have “no IAL” and the RP cannot assume the account meets “IAL1,” which is the lowest numbered IAL described in this suite.
The RP SHALL determine the minimum IAL, AAL, and FAL that it is willing to accept for access to any offered functionality and assess all IdP assertions to ensure that these xALs have been met before granting access to protected resources. If IdP responses do not meet the requested parameters, the RP SHALL have a mechanism for addressing these requests (e.g., declining the request or routing the user to an exception handling process). The RP MAY vary its functionality based on the IAL, AAL, and FAL of a specific federated authentication. For example, an RP can allow federation transactions authenticated at AAL2 for common functionality (e.g., viewing the status of a dam system) but require AAL3 to be used for higher risk functionality (e.g., changing the flow rates of a dam system). Similarly, an RP could restrict high-risk functionality (e.g., accessing sensitive information) to only certain subscriber accounts that have been identity-proofed at IAL2 while allowing basic functionality for all subscriber accounts, regardless of IAL.
In a federation process, the RP does not have direct access to the details of the subscriber account that have been provided to the IdP by the CSP, which details determine the IAL for the subscriber account. Additionally, since the RP does not participate in the authentication event or activation event at the IdP, the RP cannot determine the AAL. The RP sees many aspects of the federation transaction that determine the FAL, but the IdP also has its own responsibilities related to FAL, including signaling the IdP’s intended FAL of the federation transaction to the RP. Consequently, the IdP SHALL provide the RP with sufficient information to determine the IAL, AAL, and the IdP’s intended FAL for each federation transaction. This MAY be done in the assertions, through previous arrangement in the trust agreement, or a combination of both.
The RP SHALL ensure that it meets its obligations in the federation transaction for the FAL declared in the transaction. For example, the RP needs to ensure that the presentation method meets the assertion injection protection requirements at FAL2 and above and that the appropriate holder-of-key proof or bound authenticator is presented at FAL3.