A recent research done by the analyst firm Quocirca confirms that many businesses now have more external users than internal ones: in Europe 58 percent transact directly with users from other businesses and/or consumers; for the UK alone the figure is 65 percent. If you look at the history, most enterprises grow today via acquisitions, mergers and partnerships. In U.S only, mergers and acquisitions volume totaled to $865.1 billion in the first nine months of 2013, according to Dealogic. That’s a 39% increase over the same period a year ago — and the highest nine-month total since 2008.
What does this mean to enterprise identity management ?
You would have to work with multiple heterogeneous user stores – authentication protocols – legacy systems and many more.
SAML, OpenID, OpenID Connect, WS-Federation all support identity federation – cross domain authentication. But, can we always expect all the parties in a federation use case to support SAML, OpenID or OpenID Connect ? Most of the federation systems we see today are in silos. It can be a silo of SAML federation, a silo of OpenID Connect federation or a silo of OpenID federation.
Even in a given federation silo how do you scale with increasing number of service providers and identity providers? Each service provider has to trust each identity provider and this leads into the Spaghetti Identity anti-pattern.
Federation Silos and Spaghetti Identity are two anti-patterns directly addressed by the Identity Bus pattern.
With Identity Bus, a given service provider is not coupled to a given identity provider – and also not coupled to a given federation protocol. A user should be able to login into a service provider which accepts only SAML 2.0 tokens with an identity provider who only issues OpenID Connect tokens. The identity bus acts as the middle-man who mediates and transforms identity tokens between heterogeneous identity protocols.
Let’s see some of the benefits of the Identity Bus pattern.
- Introducing a new service provider is extremely easy. You only need to register the service provider at the identity bus and from the there pick which identity providers it trusts. No need to add the service provider configuration to each and every identity provider.
- Removing an existing service provider is extremely easy. You only need to remove the service provider from the identity bus. No need to remove the service provider from each and every identity provider.
- Introducing an new identity provider is extremely easy. You only need to register the identity provider at the identity bus. It will be available for any service provider.
- Removing an existing identity provider is extremely easy. You only need to remove the identity provider from the identity bus.
- Enforcing new authentication protocols is extremely easy. Say you need to authenticate users with both the username/password and duo-security (SMS based authentication) – you only need to add that capability to the identity bus and from there you pick the required set of authentication protocols against a given service provider at the time of service provider registration. Each service provider can pick how it wants to authenticate users at the identity bus.
- Claim transformations. Your service provider may read user’s email address from the http://sp1.org/claims/email attribute id – but the identity provider of the user may send it as http://idp1.org/claims/emai. Identity bus can transform the claims it receives from the identity provider to the format expected by the service provider.
- Role mapping. Your service provider needs to authorize users once they are logged in. What the user can do at the identity provider is different from what the same user can do at the service provider. User’s roles from the identity provider define what he can do at the identity provider. Service provider’s roles define the things a user can do at the service provider. Identity bus is capable of mapping identity provider’s roles to the service provider’s roles. For example a user may bring idp-admin role from his identity provider – in a SAML response – then the identity bus will find the mapped service provider role corresponding to this, say sp-admin, and will add that into the SAML response returning back to the service provider from the identity bus.
- Just-in-time provisioning. Since identity bus is at the middle of all identity transactions – it can provision all external user identities to an internal user store.
- Centralized monitoring and auditing.
- 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.
WSO2 Identity Server is an open source Identity and Entitlement management server, which supports SAML 2.0, OpenID, OAuth 2.0, OpenID Connect, XACML 3.0, SCIM, WS-Federation (passive) and many other identity federation patterns. Following diagram shows the high-level architecture of WSO2 Identity Server – which supports the Identity Bus pattern.
| Reference: | Identity Anti-patterns: Federation Silos and Spaghetti Identity from our JCG partner Prabath Siriwardena at the Facile Login blog. |
