In Bridging the OAuth2/SAML2 Divide, Part 1, we talked about how an identity broker can be used to bring OAuth2 and OpenID Connect into a SAML2 federated environment. We talked about how Optimal Federation and Identity Services (OFIS) can be used as a federation proxy to bridge OAuth2 and OpenID Connect to a SAML2 identity provider without requiring user identity information to be synced to the cloud.
Let’s dive deeper into this and look at some of the important details.
First, unless you only have one identity provider you will need to have a means of determining where the user needs to go to for authentication. For the passive side of OAuth2 and Open ID Connect that is pretty straightforward. When the user is first redirected to the identity broker for authentication he is prompted to select the identity provider to be proxied to. Once the user enter selects the identity provider he is forwarded to that identity provider for authentication. This is referred to as Home Realm Discovery (HRD).
Home Realm Discovery (HRD)
Home Realm Discovery is straightforward for passive OAuth2 and OpenID Connect grant types such as Access Code and Implicit grants. The user’s browser is redirected and there is an opportunity to ask the user to select an identity provider for authentication. But what about the active profiles such as the Resource Owner Password Grant? The Resource Owner Password Grant is performed via a REST call and there is no opportunity to give the user a choice of identity providers or to do a redirection. In this case the Home Realm Discovery is accomplished by requiring the credentials to be in the form of an email address and a password. The email address suffix is used to do the Home Realm Discovery after which the active authentication is proxied to the appropriate identity provider. This is supported out of the box by OFIS and can be set up via configuration settings.
Claims caching is another important aspect when bridging OAuth2 and OpenID Connect to SAML2. If the OAuth2 or OpenID Connect Grant is either purely passive (Implicit and Hybrid Grants) or purely active (Resource Owner Password Grant), the request can be proxied to the identity provider selected during home realm discovery. The challenge are grants that are a mixture of passive and active such as the Access Code Grant. For the Access Code Grant the user authenticates via the passive profile and in a broker configuration this authentication proxies to an identity provider selected in the Home Realm Discovery Process. Then the OpenID Connect enabled application exchanges the Access Code for an Access Token and an OpenID Connect Jwt Token that includes the claims that were returned from the identity provider. If there are no user identities synced to the broker, then the claims returned from the identity provider during the passive call need to be cached so they can be used by the REST service to create the Jwt claims returned in the active call. OFIS has proprietary technology that supports this out of the box.
So now we have completed the picture. In part 1 we talked about how OFIS can be used to bring OAuth2 and OpenID Connect into a SAML2 and WS-Federation federated environment without the need to sync identities. In part 2 we discussed how Home Realm Discovery can enable users to be authenticated to different identity providers, even when doing active profile (REST) authentication. Finally we see how claims caching can bridge the gap between purely passive authentication, such as SAML2, and OpenID Connect which requires a mixture of passive and active authentication in the Access Code Grant.