- Introduction
- Risk Management
- Selecting an FAL
- Guidance for Relying Parties
4.1 Purpose
4.2 General Guidance- 4.2.1 Validating IdP Signatures
- 4.2.2 Checking Assertion Expirations
- 4.2.3 Checking Audience Parameters
4.3 Guidance by Product Family - 4.3.1 SAML
- 4.3.2 OAuth and OpenID Connect
- Guidance for Identity Providers
5.1 Purpose
5.2 General Guidance
5.3 Guidance by Product Family- 5.3.1 SAML
- 5.3.2 OAuth and OpenID Connect
- Example Scenarios
6.1 Shibboleth and SAML
6.2 OpenID Connect and OAuth
6.3 Personal Identity Verification (PIV) card
6.4 Privacy-enhancing Federated Identity
6.5 Parallel Authentication - Brokered Identity Management
- Educational Resources
- Communicating with Stakeholders
- Conclusion
Federated identity transactions allow for a more secure more usable internet. Many products and libraries exist which enable those transactions at various levels of security. This document outlines what to look for in software that enables federation.
This document is intended to provide more direct guidance than SP 800-63C. SP 800-63C was written to be intentionally technology-agnostic. This can make it difficult for implementers to understand what was intended by the document with regard to specific protocols or products. This guide is intended to provide a more
Selecting and conforming to an FAL should be part of a larger risk management process and program. Conforming to FAL3 does not make your organization's security infallible. Rather than attempting to make your federation infrastructure conform to the highest standards available, you should analyze the risks that are inherent in your organization and choose how strongly to protect against them given their severity and liklihood of occurance.
FAL1 is the industry standard for authentication at this point in time. The risks of implementing a system at FAL1 or below 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 user impersonation and man-in-the-middle attacks. If those threats are common to your organization, you should consider implementation of FAL2 or FAL3.
FAL1 is absolutely fine for a vast majority of use cases. Most off-the-shelf products operate at FAL1 today. It is the most common implementation of SAML and OAuth on the internet.
FAL2 provides extra security and is required if personally identifiable information will be sent in an identity assertion because personally identifiable information must always be encrypted.
FAL3 is an extrememly secure forward-thinking standard that is not yet in production in off-the-shelf products. It protects against a number of different attacks that FAL2 does not protect against, but those attacks are highly unlikely unless the target system is extremely high-value.
Selecting an FAL should be part of a larger risk management strategy. If the system being protected is not high value, FAL3 may not be necessary. If the system does not transmit personally identifiable information, FAL2 may not be necessary. Consider the types of information and risk of compromise when selecting an FAL.
Relying parties need to validate a variety of elements during a federated transaction. Because relying parties depend on endpoints that are open to the internet, it is essential that they verify the origin and validity of the information that they recieve.
Relying parties can be a valuable target for attackers to impersonate valid users or gain valuable information about them. If relying parties do not check the validity of the information they receive, attackers can gain valuable access. The security of the entire ecosystem is dependent upon the security of relying parties.
Relying parties need to validate IdP signatures, assertion expirations, and audience parameters. Additionally, RPs need to test that these validation checks are working at all times because there will be no outward indication that something is wrong with the system until an attack occurs.
An identity assertion is signed by an IdP so that it cannot be forged by an attacker. The IdP is the only entity with access to its private key, so a valid signature indicates that the assertion is from the IdP itself and not an attacker. If an RP does not check the validity of the IdP signature, attackers will be able to forge identity assertions, and gain access to protected systems without authorization.
It is critically important to check whether your RP will accept unsigned assertions or assertions signed with an invalid key. Properly authorized transactions will still work even if an RP isn't checking assertion signatures, so there is no outward indication of a problem in the system. There will be no error messages or login failures to indicate that something is wrong.
Federated identity assertions are intended to be short-lived. An identity assertion which expires quickly makes it difficult for attackers to misuse the assertion. It also ensures that any identity or authorization information included in the assertion is not out-of-date. Authorized transactions can occur at an RP that is not checking assertion expirations, but that RP will be significantly less secure. Always test your system with an expired assertion to make sure that it is not accepted as valid by the RP.
When an IdP creates an assertion, it includes an audience parameter indicating which RP requested the assertion. This parameter is intended to reduce fraud by making it obvious when an attacker is replaying an assertion at a different RP.
If an RP does not check for a matching audience parameter, it is possible for an attacker to get a valid assertion from any RP registered with the IdP, and replay it to gain unauthorized access to a different RP.
It is critically important to check whether your RP will accept assertions with a missing or incorrect audience parameter. Properly authorized transactions will still work even if an RP isn't checking audience parameters, so there is no outward indication of a problem in the system. There will be no error messages or login failures to indicate that something is wrong.
There are two main product families that enable federated identity transactions - SAML and OAuth/OpenID Connect.
Be careful about passing and validating metadata. Incorrectly communicated or configured metadata could leak information about a user that was not approved for distribution. Metadata that is not validated could have been tampered with by an attacker to gain access to valuable personal information.
Always check certificates before accepting identity assertions. Attackers can forge certificates and phish users in an attempt to impersonate them.
Different OAuth grant types or "flows" are appropriate for different kinds of applications at different FALs.
The authorization code flow should be used whenever possible. It is the most common and most secure way to implement OAuth. It can accomodate all three FALs depending on the exact configuration of the application.
The implicit grant type is appropriate for applications which are implemented entirely in front-end code and have to capability to store secrets outside of the user's web browser. The lack of ability to store secrets means that these sorts of applications can only function at FAL1 because they have no method of private key management which would enable encryption of identity assertions.
The client credentials grant type is not recommended, since it does not require user interaction. Because applications using this grant type are capable of securely storing keys, these applications can function at FAL1 and FAL2. However, since no user interaction takes place during the authentication event, a holder-of-key proof cannot occur, preventing these sorts of applications from functioning at FAL3.
The resource owner credentials grant type does not qualify for FAL1, FAL2, or FAL3, and should be avoided.
The security of all users rests on the security of their identity provider. The guidance below will indicate how to implement strong security.
IdPs have the difficult task of keeping track of many RPs and deciding how much trust to bestow on each one. This guidance is intended to highlight best practices to accomplish that objective.
Much of the technical friction in identity transactions stems from IdPs which are built and configured in such a way that onboarding new RPs requires a significant amount of manual human intervention.
Much of this friction is removed when IdPs support known discovery mechanisms and simple registration.
There are three main product families that enable federated identity transactions - SAML, OAuth/OpenID Connect, and Kerberos
Publish metadata in a well-known location. While there is no widely accepted standard for SAML metadata exchange, it is advisable to use a well-documented metadata endpoint to serve your IdPs metadata in the form of a single XML file to any RP who wishes to consume it.
Only accept metadata that has been signed by the presenting RP, and always check the signature on that metadata.
Identity federations like InCommon share the metadata of hundreds of IdPs and RPs in a structured manner. Adding your IdP's metadata to such federations will help RPs to find it easily.
Apply best practices to protect user information. All SAML assertions containing personally identifyable information must conform to FAL2. That means the assertion must be encrypted to the relying party.
Assertions containing only authentication information and no personally identifiable information do not need to encrypt their assertions. They may operate at FAL1.
OpenID Connect has an established discovery mechanism. Your IdP's discovery documents should be published in JSON format at an HTTPS location ending in /.well-known/openid-configuration as specified in the OpenID Connect discovery specification.
If personally identifiable information is made available at the UserInfo endpoint, it need not be encrypted. However, if personally identifiable information is bundled with authentication information in a token, it must be encrypted to the RP and conformant with FAL2.
It is recommended that OpenID Connect IdPs support a registration endpoint to make it easy for RPs to register without manual intervention.
There is a test suite for OpenID Connect providers to verify whether their instance of OpenID Connect is compliant with the standard. That test is located at http://openid.net/certification/testing/. If your provider passes these tests, you have the option of becoming a self-certified OpenID Connect provider. This will help other participants in the OpenID Connect ecosystem find you, and find out the exact configuration of your system.
The OpenID Connect community has reviewed libraries in several different languages to search for bugs and non-compliant processes.Whenever possible, you should leverage these libraries in your development.
OpenID Connect relies heavily on the JOSE standard, particularly JWT and JWK. All tokens an keys in your implementation should conform to those standards.
You may also consider implementation of additional security standards like token binding and proof key for code exchange. While those standards are not factors in determining the FAL of your instance, they considered to be best practice in the industry.
SAML Federations like InCommon can operate at FAL1 or FAL2. Most InCommon IdPs are running on a Shibboleth identity provider. They pass assertions through a response to an authentication event. Most often, those assertions are not encrypted to the RP.
If you are running a Shibboleth IdP, you must either encrypt your assertions to the RP, or refrain from sending personally identifiable information such as eppn over the wire as an unecrypted SAML assertion.
Typically, OpenID Connect Providers interact with OAuth relying parties by providing an authentication mechanism which is separate from the transfer of personally identifiable information. As such, these providers can safely operate at FAL1 because they are not bundling identity assertions with authentication information.
Federation Assurance Levels are independent of Authenticator Assurance Levels. Any authentication device may be used to obtain any FAL, including but not limited to a Personal Identity Verification (PIV) card.
There are many benefits to using federated identity management as opposed to requiring independent registration of PIV cards for each user. Federated identity management protocols such as OpenID Connect allow users to authenticate at a relying party regardless of which authenticator they use at their IdP. This allows relying parties to securely accept registered users whose IdPs do not use PIV cards.
In many cases, relying parties do not need to know the full identity of a user. Relying parties should only request as much information as they need to complete the transaction requested by the user.
Pairwise identifiers should be used in place of perisistent or correlatable identifiiers whenever possible. This prevents relying parties from tracking or identifying individual users.
When possible, claims should be used to communicate identity information rather than raw data. For example, if a relying party needs to know whether a user is over eighteen years old, the IdP should respond that the user is over eighteen without sharing the user's age or birthdate.
In some cases a relying party may wish to confirm certain aspects of a user's identity above and beyond what the IdP provides. For example, a relying party could verify a user with an IdP, receive a picture of the user, and require that an in-person agent verify that the picture matches the identity of the person authenticating.
We call this use case "parallel authentication" because two authentication events are happening in parallel. The focus of FAL is primary on the assertions being passed from the IdP to the RP, so most authentication events occuring at the RP would not affect the FAL of the transaction. The exception to this rule is a holder-of-key authentication event. If the RP verifies in parallel that the user is in possession of a key that the IdP says they should have, that verification counts as a factor toward FAL3.
Some federated identity architectures are based on brokered identity management. In these architectures, a single broker intermediates transactions between registered IdPs and RPs. This means that each entity in the system only has to register with one broker in order to interoerate with everyone else in the system. It also means that an IdP can authenticate a user without knowledge of which RP requested the authentication event.
Recent advances in automated registration processes have made IdP/RP integrations much less onerous than they used to be. It is possible for an IdP and RP to register with each other in a very short amount of time without any manual processes. This has lessened the value of brokered identity architectures, since interoperability can be simple and fast even without a central broker.
While brokered identity management systems may appear to protect privacy by blinding an IdP from an RP, keep in mind that the broker itself is aware of all the parties involved in the transaction, and in some cases can see personally identifiable information about users. Brokered identity management systems do not prevent user tracking all together, they merely shift the ability to track users from the IdPs and RPs to the broker.
Additionally, because brokers have access to active valid identity assertions, they are capable of impersonating users. This increases the risk inherent in the entire architecture, since the broker represents a single point of failure which, if it is compromised, can in turn compromise every participant in the system.
NIST has been promoting privacy-enhancing technology in the brokered identity management space through the Privacy-Enhanced Identity Federation project. This NIST building block outlines a set of goals which would constitute a new kind of brokered architecture. This architecture leverages a broker which cannot impersonate or track users. This architecture is still theoretical, and may allow for a privacy-preserving and secure version of brokered identity management in the future.
All specifications for identity federation standards are freely available online:
OAuth 2 (RFC 6749)
OpenID Connect
Security Assertion Markup Language
These specifications outline multiple, sometimes mutually exlusive ways to implement federated identity, so be sure to read the specifications in their entirety before creating an implementation.
Federation standards communities actively track known vulnerabilities in existing standards.
The IETF lists OAuth Security Concerns in in RFC 6819 and hosts a working group to track OAuth standards and vulnerabilities.
The OpenID Foundation lists OpenID Connect security concerns within the specification itself and hosts a working group which actively tracks vulnerabilities.
OASIS has published SAML Privacy and Security Considerations and hosts a mailing list to track SAML vulnerabilities.
While it is tempting for stakeholders to request the highest level of security, that is not always in the best interest of the organization. Federated identity projects can be long and complicated. They can take resouces away from other work that a security team could be doing.
Many organizations today operate at FAL1. FAL1 is the industry standard, and there are many libraries and off-the-shelf products that can help an organization implement an FAL1 conformant federated identity system.
Conformance to FAL2 or FAL3 is appropriate for some business cases where there is a risk of fraudulent activity which would be prevented by token encryption.
Stakeholders should be aware that selecting an FAL is part of a larger risk- and resource-management process.
There are many ways to secure federated identity transactions, and many products do a very adequate job of it today, but there are ways to improve your security posture with regard to federation if doing so makes sense in your overall risk management framework.