.jpeg)
The WSO2 Identity Server 5.0.0 takes the identity management into a new direction. No more there will be federation silos or spaghetti identity anti-patterns. The authentication framework we introduced in IS 5.0.0 powers this all. The objective of this blog post is to introduce high-level concepts associated with the authentication framework.
Inbound Authenticators
The responsibility of inbound authenticators is to identify and parse all the incoming authentication requests and then build the corresponding response. A given inbound authenticator has two parts.1. Request Processor
2. Response Builder
For each protocol supported by WSO2 IS - there should be an inbound authenticator. Out-of-the-box it comes with inbound authenticators for SAML 2.0, OpenID, OpenID Connect, OAuth 2.0, and WS-Federation (passive). In other words, the responsibility of the SAML 2.0 request processor is to accept a SAML request from a service provider, validate the SAML request and then build a common object model understood by the authentication framework and handover the request to it. The responsibility of the SAML response builder is to accept a common object model from the authentication framework and build a SAML response out of it.
Both the request processors and the response builders are protocol aware while the authentication framework is not coupled to any protocol.
Local Authenticators
The responsibility of the local authenticators is to authenticate the user with locally available credentials. This can be either username/password or even IWA (Integrated Windows Authentication). Local authenticators are decoupled from the Inbound Authenticators. Once the initial request is handed over to the authentication framework from an inbound authenticator, the authentication framework talks to the service provider configuration component to find the set of local authenticators registered with the service provider corresponding to the current authentication request.Once the local authentication is successfully completed, the local authenticator will notify the framework. The framework will now decide no more authentication is needed and hand over the control to the corresponding response builder of the inbound authenticator.
You can develop your own local authenticators and plug them into the Identity Server.
Outbound / Federated Authenticators
The responsibility of the federated authenticators is to authenticate the user with an external system. This can be with Facebook, Google, Yahoo, LinkedIn, Twitter, Salesforce or any other identity provider. Federated authenticators are decoupled from the Inbound Authenticators. Once the initial request is handed over to the authentication framework from an inbound authenticator, the authentication framework talks to the service provider configuration component to find the set of federated authenticators registered with the service provider corresponding to the current authentication request.A federated authenticator has no value unless its associated with an identity provider. For example IS 5.0.0 out-of-the-box supports SAML 2.0, OpenID, OpenID Connect, OAuth 2.0 and WS-Federation (passive). The SAML 2 .0 federated authenticator itself has no value. It has to be associated with an Identity Provider. Google Apps can be an identity provider - with the SAML 2.0 federated authenticator. This federated authenticator knows how to generate a SAML request to the Google Apps and process a SAML response from it.
There are two parts in a federated authenticator.
1. Request Builder
2. Response Processor
Once the federation authentication is successfully completed, the federated authenticator will notify the authentication framework. The framework will now decide no more authentication is needed and hand over the control to the corresponding response builder of the inbound authenticator.
Both the request builder and the response processor are protocol aware while the authentication framework is not coupled to any protocol.
You can develop your own federated authenticators and plug them into the Identity Server.
Request-path Authenticators
This is a special type of authenticator. Request-path authenticator is always a local authenticator. Once the initial request is handed over to the authentication framework from an inbound authenticator, the authentication framework talks to the service provider configuration component to find the set of request-path authenticators registered with the service provider corresponding to the current authentication request. Then the framework will check whether there is any request-path authenticator applicable for the initial authentication request. In other words, a request path authenticator will get executed only if the initial authentication request brings the applicable set of credentials with it.The request-path authenticators always require the user credentials to be present in the initial authentication request itself. This does not need any end-user interactions with the Identity Server.
Once the request-path authentication is successfully completed, the request-path authenticator will notify the authentication framework. The framework will now decide no more authentication is needed and hand over the control to the corresponding response builder of the inbound authenticator.
Identity Provider Configuration
The responsibility of the Identity Provider configuration in IS 5.0.0 is to represent external Identity Providers. These external identity providers can be Facebook, Yahoo, Google, Salesforce, Microsoft Windows Live or whoever. If we want to authenticate users against these identity providers, then we must associate one or more Federated Authenticators. For example, if we want to authenticate users against Google Apps, then we need to associate SAML 2.0 authenticator with Salesforce identity provider. If we want to authenticate users against Yahoo - then we need to associate OpenID authenticator with it. To make this process much easier Identity Server also comes with a set of more specific federated authenticators as well. For example, if you want authenticate against Facebook, you do not need to configure OAuth 2.0 authenticator - instead you can directly use the Facebook federated authenticator.
Each identity provider configuration can also maintain a claim mapping. This is to map its own set of claims to the identity server's claims. When the response from an external identity provider is received by the response processor component of the federated authenticator - before it hands over the control to the authentication framework, the response processor will create a name/value pair of user claims received in the response from the identity provider. These claims are specific to the external identity provider. Then its the responsibility of the authentication framework to read the claim mapping configuration from the identity provider component and do the conversion. So, while inside the framework, all the user claim values will be in a common format.
The service provider configuration also defines how to authenticate users. This can be via a local authenticator, request-path authenticator or federated authenticator. Based on this configuration, Identity Server knows when it receives an authentication request (via an inbound authenticator) how to authenticate the user based on the service provider who initiates it.
Each identity provider configuration can also maintain a claim mapping. This is to map its own set of claims to the identity server's claims. When the response from an external identity provider is received by the response processor component of the federated authenticator - before it hands over the control to the authentication framework, the response processor will create a name/value pair of user claims received in the response from the identity provider. These claims are specific to the external identity provider. Then its the responsibility of the authentication framework to read the claim mapping configuration from the identity provider component and do the conversion. So, while inside the framework, all the user claim values will be in a common format.
Service Provider Configuration
The responsibility of the Service Provider configuration is to represent external service providers. These external service providers can be a web application, a mobile application, a liferay portal, Salesforce (Salesforce can be both a service provider and an identity provider), Google Apps (Google Apps can be both a service provider and an identity provider) and many more. In the service provider configuration you define how the service provider talks to the identity server - this is via inbound authenticators. When you register a service provider you need to associate one or more inbound authenticators with it.
Each service provider configuration can also maintain a
claim mapping. This is to map its own set of claims to the identity
server's claims. When the authentication framework hands-over a set of claims (which it gets from the local user store or from an external identity provider) to the response builder of the inbound authenticator, the framework will talk to the service provider configuration component, find the claim mapping and do the claim conversion. Now the response builder will receive the claims in a manner understood by the corresponding service provider.
Multi-option Authentication
The service provider can define how to authenticate users at the Identity Server, for authentication requests initiated by it. While doing that, each service provider can pick more than one authenticators - so, the end user will get multiple login options. This can be a combination of local authenticators and federated authenticators.Multi-level (multi-factor) Authentication
The service provider can define how to authenticate users at the Identity Server, for authentication requests initiated by it. While doing that, each service provider can define multiple steps and for each step it can pick more than one authenticators.