Different federation protocols and implementations of those protocols have many options that lead to different outcomes in the security of a system. All of these options have trade-offs in terms of complexity, robustness, and other characteristics. Choosing the right set of options for a given situation helps ensure that transactions will be as secure, functional, and efficient as possible.
There must always be a balance between the complexity of a solution and the threats it protects against, and each deployment situation will lead to its own requirements. There is, unfortunately, not a one-size-fits-all approach that can be applied blindly to all situations.
A number of different federation protocols exist, but the two most common ones today are Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). These protocols are not compatible with each other, but they offer some similar capabilities. For the most part, protocol selection will be based on the technology support available in the target environments. However, some core aspects of the protocols themselves lend them to different choices.
SAML is a protocol based on passing XML documents between different parties. The web single-sign-on profile for SAML allows it to be used as a federation protocol between websites. SAML has extensive support and deployment in some spaces, but lacks the flexibility that is often needed for modern systems. For instance, SAML is not well-suited for log in to a mobile application, nor is it a good fit for protecting API access. Additionally, most SAML federations are static in nature, or controlled by centralized federation authorities. While this is a valid model, it is limiting in terms of which applications can be used.
OIDC is a protocol based on the OAuth 2 delegation framework. While OIDC is primarily a web-focused protocol, it is also usable with mobile and native applications. Since it is built on OAuth 2, OIDC allows for delegated access to additional APIs alongside identity information, a feature that is often desirable in today’s integrations.
The Federation Assurance Level (FAL) defined in SP 800-63C Section 4 provides a set of requirements for federation transactions. These requirements are grouped into an ascending scale of three levels: FAL1, FAL2, and FAL3. Each successive level includes all the features of lower levels and adds additional requirements on top of them. Each level introduces protections against specific kinds of attacks, and these protections are applicable only in some situations.
FAL1 provides a solid basis for federation and is appropriate for the vast majority of use cases. Most off-the-shelf products operate at FAL1 today, including most common deployments of SAML and OIDC. FAL1 requires that all assertions be signed, time limited, and audience-restricted to prevent an assertion intended for one RP to be replayed at another RP. It is anticipated that most deployments will build out at FAL1 and move to FAL2 or FAL3 only when necessary.
FAL2 provides an extra layer of security by requiring that the assertion be encrypted so that the RP is the only party that can decrypt it. This level requires that the IdP manage an encryption key for the RP, which necessitates additional complexity for both parties. The keys could be managed with a traditional PKI infrastructure that relies on a trusted certificate authority, but with many protocols the keys can be instead registered directly between parties. The RP also needs to manage and protect its decryption keys in order to read the information in the assertion. If the RP’s private decryption keys are leaked to another party, the additional protections provided by FAL2 are no longer in play.
FAL3 is intended to be a forward-looking requirement and is not yet readily available in off-the-shelf standards and products. FAL3 provides an additional layer in the form of a cryptographic key that is presented by the subscriber directly to the RP in addition to the signed and encrypted assertion itself. This level requires that the IdP manage references to keys representing the subscriber at each RP in addition to managing the keys for the RPs themselves. The IdP needs to correctly associate the subscriber’s key to the correct RP in the assertion, and the RP needs to be able to process and validate the presentation of the key by the subscriber. This key could be the same key that’s presented by the subscriber at the IdP, or it could be a separate key that’s not used at the IdP. The key could be in a credential with its own attributes, such as an X.509 certificate, or it could be tied to an authenticator, such as a FIDO token. In all of these cases, the assertion needs to reference the key and the RP needs to ensure the correct key is presented by the subscriber.
Selecting and conforming to an FAL ought to be part of a larger risk management process and program. Conforming to FAL3 does not make an organization’s security infallible, but instead provides protection against particular attacks while incurring certain costs to both the applications and the subscribers. Rather than attempting to make federation infrastructure conform to the highest standards available, it is recommended to analyze the inherent risks and choose how strongly to protect against them given their severity and likelihood of occurrence.
The additional information management and implementation complexity of higher FALs cannot be ignored, and the costs to all involved have to be weighed against perceived benefits. Unless there is a compelling reason to use the features of higher FALs, FAL1 is the industry standard for most use cases. The risks of implementing a system at FAL1, when compared to higher FALs, may be negligible depending on relevant use cases and attack vectors.
Because it is the front door to many critical systems, authentication is a key piece of risk management strategy. Strong federation can protect against many potential subscriber impersonation and man-in-the-middle attacks. Instead of each RP needing to manage subscriber accounts and authenticators separately, creating many vulnerable surfaces, federation concentrates the key security practices in a dedicated component, the IdP. Upgrades to authenticators, software, and practices at the IdP automatically benefit the downstream RPs and the overall network.
Personally Identifiable Information (PII) needs to be limited to only what’s needed to perform a transaction as per Section 7.3. For many login transactions, the RP will need to know only an identifier for the current subscriber. After an initial login, this identifier is used by the RP to tie the subscriber to a record or account in the RP application, and this record often contains attributes collected from various sources including the IdP and direct interaction with the subscriber.
All assertions contain a subject identifier, which uniquely identifies the subscriber represented by the assertion to the RP. Since the subject identifier is required with every assertion, the subject identifier should not have any PII internally. For example, IdPs would not use usernames, employee numbers, simple sequences, or other easily predictable and correlatable information for the subject identifier. Instead, to prevent PII leakage, IdPs can use approved cryptography to assign random subject identifiers to all subscribers. Alternatively, IdPs could derive subject identifiers from PII using approved cryptography. For example, the IdP could run an internally unique identifier (like an employee number) through an approved hashing function. The output of the hashing function would be the subject identifier, and the PII used to generate it has been protected since it cannot be re-derived from the output of the hashing function.
Assertions at all levels can include additional attributes about the subscriber as per Section 6, potentially including PII. The RP might require some of this information to perform its function, such as an email address to contact a subscriber. However, the RP will not know if it needs information for a given subscriber before that subscriber has been logged in, since the required information could be available locally to the RP without requesting it from the IdP. This presents a dilemma for systems trying to practice data minimization. Some protocols, such as SAML, require all available attributes be present in the assertion itself. In such cases, the RP needs to be very judicious about which attributes it requests. In other protocols, such as OpenID Connect, attributes can be sent through both the assertion and a secondary channel, the UserInfo endpoint. In OpenID Connect the ID Token serves as the assertion, and by default it contains a non-PII subject identifier for the subscriber. Additional information about the subscriber can be obtained through the UserInfo Endpoint by using an OAuth access token. Since this information is communicated in the back channel from the IdP to the RP over an authenticated protected channel, it need not be separately encrypted as it is not handled or presented by an intermediary party (though of course it can be encrypted as well).
FAL2 is required if PII will be sent in an identity assertion that is passed through an intermediary such as a browser, as personally identifiable information needs to be protected in transit. If the PII is sent over the back channel instead, either in the assertion or in a separate request, then FAL2 is not required in order for the information to be sufficiently protected in transit.
Assertions can be sent either over the back channel between the IdP and RP as per Section 7.1 or over the front channel using the subscriber and their browser as an intermediary as per Section 7.2. While both methods are allowed at all FALs, back channel presentation has a number of advantages and is preferred where possible.
Since the assertion is transmitted directly from the IdP to the RP over an authenticated protected channel, the RP has a high level of assurance that the assertion is from the IdP in question. The RP can also be sure that the assertion is generated in response to a specific authentication request since the RP needs to present an assertion reference to retrieve it.
Front channel presentation systems are simpler for RPs to implement, as the RP does not have to handle assertion references or take the extra step of trading the reference for an assertions. As a consequence of this simplicity, front channel presentation systems can be more susceptible to assertion injection, whereby an attacker can present a valid assertion to an unsuspecting RP in order to force a login at that RP, potentially taking over a session. A back channel presentation system is subject only to injection of an assertion reference, which can be more strongly tied to an authentication request.
To enforce least-privilege and least-knowledge security principles, it is preferable to have each RP request its own assertion instead of re-using one assertion for multiple RPs. With front-channel presentation, it is tempting for a system to create a single assertion to be presented to multiple RPs by the browser. RPs in such a system would be configured to accept an assertion that they did not explicitly request, in order to facilitate a more seamless user experience. The subscriber’s browser then needs to determine which sites to present the assertion to, and which to request a new assertion for. With a back channel presentation mechanism, only the assertion reference is passed to the RP from the browser. Since the assertion reference is one-time use and limited to a single RP as in Section 7.1, it cannot be used accidentally multiple times at multiple RPs.
Additionally, assertions passed in the front channel are visible to an intermediary party, the browser. The assertion’s payload, which is intended for consumption by the RP, can include PII attributes, internal security information, or other sensitive data. To avoid unintended data leakage, the IdP can employ several techniques: