By: Salah Machani, RSA, Dell Technologies Business; Co-chair of FIDO Enterprise Adoption Group
The FIDO Alliance has developed a framework for strong, multi-factor authentication (MFA) that is easy to use and deploy. Many enterprises have deployed federation to enable single sign-on (SSO) across on-premises or cloud applications. As enterprises consider deploying and leveraging FIDO for stronger authentication they question whether FIDO is intended to replace existing federation protocols or whether a complete overhaul is required to integrate FIDO with those existing protocols. The answer is no: FIDO and federation protocols are not only complementary but function optimally together.
The FIDO Alliance has published a white paper detailing how FIDO complements federation protocols and providing guidelines on how to integrate the two in order to add support for FIDO-based MFA and replace or supplement traditional authentication methods in federation environments.
FIDO’s main goal is to reduce the burden of remembering multiple passwords or having a variety of two-factor authentication form factors for separate applications. When a user registers a FIDO-enabled device (such as a Security Key or mobile device) with an application provider, a unique credential is generated and bound to the user’s account with that particular application provider. The user can use the same FIDO-enabled device and repeat the process to generate additional unique credentials for user with other application providers, without needing to carry additional devices. The credentials on the user’s device are typically locked with the same local PIN or biometric, allowing the user to authenticate across multiple applications using a single and simple gesture.
Federation protocols such as the Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) are designed to move user identity to trusted third-party authentication authorities and away from application and service providers. When a user authenticates to a trusted authentication authority, typically using a password, a time-bound assertion or token is issued for that user to present to one or multiple application providers. The user is not required to re-authenticate to the authentication authority or to every application provider, which is the definition of SSO.
FIDO authenticators are utilized by enterprises to authenticate a user when they initiate a ‘sign-in’ request to an application or to ‘step-up’ the authentication for a user session. In federated environments, FIDO can be deployed to support the two scenarios
In the initial sign-in scenario, the Application Provider redirects the user to the Application Authority, in this
Figure 1: Initial ‘Sign-in’ with FIDO-based Authentication
In the step-up scenario, after the Authentication Authority performs the initial user authentication with a particular authentication mechanism and having been redirected to the Application Provider with an assertion to that fact. That assertion is subsequently determined by the Application Provider to engender insufficient confidence for a particular resource request. Consequently, the Application Provider performs additional authentication using a FIDO-based mechanism or redirects the user back to the Authentication Authority with a request the user be re-authenticated with a FIDO-based authentication to supplement the prior non FIDO-based authentication, or a higher assurance FIDO-based authentication is desired to supplement a previous lower assurance FIDO-based authentication. Figure 2 illustrates a generic workflow for step-up authentication using FIDO in a federated environment.
Figure 2: ‘Step-up’ with FIDO-based Authentication
The full value of the integration of the two scenarios presume the existing applications can request of the Authentication Authority a FIDO-based authentication, or use a specific FIDO authenticator. The request for FIDO-based authentication can be explicit or implicit, by indicating a policy name or an assurance level that requires a FIDO authenticator. Alternatively, the Authentication Authority may enforce FIDO-based authentication by default for all users, a group of users or under certain conditions pre-defined by the Application Provider.
By allowing the user to register a FIDO authenticator with a trusted Authentication Authority and then utilize that FIDO authenticator across applications without needing to be registered directly with each one of them, federation enhances user experience, improves security, and “amplifies” FIDO deployment.
It is important to note that the trust model in FIDO and in federation protocols is different.
- With FIDO, there is direct trust between the user and the Application Provider. The Application Provider deploys a FIDO server in its infrastructure to store a user’s public credential and directly authenticate users. The Application Provider is referred to as FIDO Relying Party (RP).
- With federation protocols, the trust between the user and application provider is indirect. The trust is established between the user and the Authentication Authority, and between the Authentication Authority and the Application Provider. The user authenticates to the Authentication Authority, and the Authentication Authority issues an assertion about the identity of the user to the Application Provider.
In a combined FIDO and federation environment, the Authentication Authority acts as a FIDO RP.
FIDO answers emerging needs for rapidly changing enterprise environments, but also extends and builds on legacy protocols such as federation protocols to preserve existing functions and workflows. This way, enterprises can take advantage of FIDO security and usability benefits in the most cost effective way. To learn more, download and read the white paper.
In the paper, you will find detailed information on how FIDO can be integrated with leading federation protocols, namely SAML, OIDC, and OAuth, including how:
- A SAML Service Provider (SP) requests from the SAML Identity Provider (IDP) that user authentication be FIDO-based.
- A SAML IDP returns a SAML Assertion to the SP indicating that user authentication was performed using FIDO.
- A OIDC RP requests from the OIDC Provider that authentication be FIDO-based.
- An OIDC Provider returns a token to the RP indicating that user authentication was performed using FIDO, and how.
- FIDO could be leveraged in OAuth2 environments for user authentication prior to user consent and authorization to access a protected resource.
FIDO TechNotes highlight aspects of the FIDO specifications that are important for practitioners to understand. TechNotes shed light on architectural choices, explain best practices, and give guidance to deployers of the technology. TechNotes are part of an on-going FIDO series featuring the technology and evolution of the FIDO Alliance.
