It’s no secret that OAuth2 and OpenID Connect are gaining in popularity. It seems that all of our customers are in the process of rolling out OAuth2 and OpenID Connect, or are thinking about it. But how can these newer protocols play nicely in your enterprise if you already have a SAML2 or WS-Federation infrastructure? The answer is an identity broker (also known as a federation proxy).
What is an Identity Broker / Federation Proxy
An identity broker (or federation proxy) accepts request from a relying party and proxies them to an identity provider. At the highest level, it works like this; OAuth2 and OpenID Connect federation requests are sent to the broker. The broker proxies those requests to your existing SAML2 identity provider or WS-Federation identity provider. The federation response is then used to create a response to the original OAuth2 or OpenID Federation request. 
Optimal Federation and Identity Services (OFIS)
This architecture is supported out of the box by Optimal IdM’s on – premise solution, Optimal Federation and Identity Services (OFIS) as well as the hosted solution, The OptimalCloud. Using OFIS as an identity broker, the relying party can make authentication requests using OAuth2, OpenID Connect, SAML2, or WS-Federation. OFIS can then proxy those requests to other identity providers using OAuth2, OpenID Connect, SAML2, or WS-Federation.
OAUTH2 Used as an Authentication Protocol
Yes, OAuth2 is considered an authorization rather than an authentication protocol. But it is often used as an authentication protocol in reality. For the purposes of this discussion we will talk about it in the same vein as OpenID Connect, SAML2, and WS-Federation. Even if used strictly for authorization, authentication will still be required, and for that authentication there might still be the need to proxy to more traditional federation protocols such as SAML2 and WS-Federation.
Cloud Synchronization Requirements
Most identity broker solutions and vendors require the enterprise to synchronize their on premise users to the cloud, or create identities in the cloud. This leads to a lot of provisioning and privacy issues. This also not the best solution as the last thing you want to do is to create more identities in order to solve your identity issues. It doesn’t simplify your problems. If using Optimal IdM OFIS, no users need to be synced to the broker.
If you are using another solution that will likely not be true. There are subtle difference in how this works depending on the grant flow being used. For the access code and implicit OAuth2 this is pretty straight forward. When an OAuth2 access request is made to the broker, the user is forwarded to a federated identity provider to perform an authentication request. The response is then received by the broker and if properly validated, the OAuth2 response is forwarded to the application. If the Resource Owner Password Profile is used, then the broker needs to proxy that OAuth2 request to the identity provider.
If the identity provider does not support OAuth2, then WS-Trust could be used for proxying the authentication requests. In the broker the claims received can be transformed to populate an OpenID Connect token or User Profile. But what if additional claims are needed? There are several ways to address that if there is an addition source of claims. But that is for another time.
OAuth2 and Open ID Connect
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
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.
Can’t wait? Get Optimal IdM IAM Services Now
Contact Us Start Your Free Trial
