To perhaps refresh you memory, the WSO2 ESB allows you to connect almost every system to every other system by offering transformation and mediation. The only systems that cannot be connected are those that have no communication capabilities but other than that you can let a SOAP based interface talk to a RestFUL implementation, split join or manipulate messages and a whole lot of other common enterprise challenges.
An Identity Bus does the same and can connect a service provider that accepts SAML 2.0 tokens to an identity provider that only issues OpenID Connect tokens. Without the Identity Bus this would be impossible. The Identity Bus is the middle man that mediates and transforms (much like the ESB) and therefor makes interoperability a reality. The world is not just about SAML, OAUTH2 or what ever other protocol you can imagine. The world is about interoperability between systems without, we might add, breaking the bank doing so.
The benefits are plentiful (we only focus on the primary identity bus benefits, not the general benefits of the identity server):
- Introducing a new service provider or identity provider is simple and straightforward
- Enforcing new authentication protocols is extremely easy.
- Claim and role mapping are possible
- Introducing a new federation protocol needs minimal changes
To quickly talk you through these benefit: when you add a service provider, just select which identity providers it trusts. When you add an identity provider it will be available for all service providers. Removing a service provider or identity provider is as simple as it sounds, remove it and it is gone.
When you want to add an authentication protocol (e.g. a USB Fido U2F token) you can simply add that to the Identity Server (it is already there in the current (5.1.0) version) and add this to the local and outbound authentication Configuration.
Claims can differ from SP to IDP. So it is possible to map claim A to claim B (even if they use different dialects). The same goes for roles , these can also be mapped from IDP to SP.
Lastly, when you want to add a new federation protocol, it is as simple as adding it to the Identity Server and it will be available to all service- and identity providers. No need to actuall
Introducing a new federation protocol needs minimal changes. If you have a service provider or an identity provider, which supports a proprietary federation protocol, then you only need to add that capability to the identity bus. No need to implement it at each and every identity provider or service provider.
In short, the Identity Bus makes the Identity Server from WSO2 an integral part of your ICT infrastructure allowing for interconnections between systems that normally would not be able to connect.
Federated Authentication
There can be many reasons why you would want to have a federated authenticator in your environment. Ease of use being an important reason. Offering the possibility to authenticate with Google, Facebook or Microsoft is attractive for some users since they can use existing credentials to log in to your system.
Basically, you are saying, to facebook or any other provider: you authenticate the user and inform me of the results.
The flow goes from the inbound authenticator to the authentication framework that looks to the configuration of the service provider to identify and invoke the identity provider(s) that are defined for that service provider.
The current supported federated authenticators are:
- OpenID
- SAML 2.0 Web SSO
- OAuth2/OpenID Connect
- WS-Federation (Passive)
- Yahoo
- Microsoft Windows Live
Mind your these are standards that are in some cases directly linked to an identity provider (e.g. Facebook) or need to be connected in case of OAUTH2 (to an IDP that supports this standard).
There are two parts in a federated authenticator.
- Request Builder
- Response Processor
If you need to add another federated authenticator you can write your own federated authenticator, by creating your own Java based code. Authenticators are defined by extending the AbstractApplicationAuthenticator class and implementing the FederatedApplicationAuthenticator interface. You can find more information in the documentation of WSO2 Identity Server.
OpenID Connect, the perfect addition to OAUTH2
OpenID Connect is an identity layer on top of the OAuth 2.0 authorization framework. As you might know, OAUTH2 offers delegated access using access tokens. These tokens can have a limited validity based on time (e.g. one hour). It is a federated authenticator (see previous paragraph) that you can use when specifying an Identity provider.
The concept of OpenID Connect is to to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user.
OAUTH2, by itself, is used for instance in the WSO2 API Manager where it allows access to API’s using access token and therefor making sure that only users with the right credentials are actually allowed to invoke the APIS. But it is also used by Google to authorize use of resources.
Read also our other WSO2 tutorials and blogs, written by our WSO2 Gurus. In case you need WSO2 support, contact the Yenlo WSO2 Guru team to get WSO2 Development Support or WSO2 Operational Support. Of course we do deliver excellent WSO2 training services as well, based on reallife WSO2 tutorials.
Thanks to Chinmaya Tripathy for his contribution to this blog.
