IT consumerization is an emerging topic or trend for last few years. It talks about reorientation of product and service designs around the individual end-user.This important trend is not just about new devices; it is about the entire relationship between IT and its user population. This trend also introduces significant security issues because critical IT assets need to be available — securely — to an increasingly distributed and diverse user base that is using consumer devices of their own choice.
While the initial consumerization hype was focused on the bring your own device (BYOD) trend, we are now seeing the emergence of bring your own identity (BYOID) concept.
The rise of BYOID is being driven by users' "identity fatigue."
Users have too many accounts, too many usernames and too many passwords. When the competition is literally a click away, organizations must enable the easiest user experience possible or users migrate to sites that offer the simplest registration and login process. Many web sites have moved quickly to accept identities from popular online identity providers like Facebook, Google and LinkedIn.
A 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. BYOID (Bring Your Own IDentity) is not just about bridging social identity with enterprise identity - it is also about bridging different heterogeneous identities between different corporates or enterprises.
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. You are not able to talk between silos.
SAML was mostly used to facilitate web single sign on. It can be just within the same domain or between domains. SAML V2.0 - in 2005 - was built on that success. It unified the building blocks of federated identity in V1.1 with the inputs from Shibboleth initiative and the Liberty Alliance's Identity Federation Framework. It was a very critical step towards the full convergence for federated identity standards.
OpenID, in 2005 - followed the footsteps of SAML. It was initiated by the founder of LiveJournal - Brad Fitzpatrick. The basic principle behind both OpenID and SAML, is the same. Both can be used to facilitate web single on and cross-domain Identity Federation. OpenID is more community friendly, user centric and decentralized.
In mid-January 2008 - Yahoo added OpenID support - late July MySpace announced its support for OpenID - and late October Google joined the party. By December 2009 - there were more than 1 billion OpenID enabled accounts.
It was a huge success in web single sign on - but started to fade - after OAuth 2.0 and OpenID Connect. One of the very popular and very first OpenID Provider - MyOpenID - was shut down on 1st of February 2014. But SAML - still stable as it was ten years back.
OpenID Connect - has some history. It has its roots in OAuth 2.0 - although its been developed outside IETF - under the OpenID Foundation.
OAuth 2.0 is a framework for delegated authorization. Its a misconception to think it does authentication. OpenID Connect is the one built on top of OAuth 2.0 to do authentication. As in the case of SAML and OpenID, both OAuth and OpenID Connect can be used for web single sign on and cross domain identity federation.
Building a setup from scratch to fit into these standards is not hard. Say you’ve got Liferay - which supports OpenID. You can enable federated login to Liferay, to a partner - who is having an OpenID Provider, deployed over its own user store. Similarly, if you have a SAML 2 Identity Provider deployed in your environment - you can federate that identity to cloud service providers like Salesforce or Google Apps. Basically, that means - the users from your domain will be able to login into Salesforce or Google Apps using their corporate LDAP credentials. That’s the easy part of BYOID. How do you handle a situation where you have a partnership, and the applications running in your domain - secured with SAML 2.0 - should be accessible to your partner, who is only having an OpenID Connect Identity Provider.If you support true BYOID - with no code changes - you should be able to let a user from the partner domain with an OpenID Connect token - to log into your application which is secured with SAML 2.0.
Internet Identity always - has an unsolved problem. Very frequently you will see new standards and profiles are popping up.
SAML was dominating the last decade and still to some extent - OpenID Connect and JWT could be dominating the next. As we go on - as we move one - there will be lot of legacy around us.
We need to find a way to get rid of these federation silos and build a way to facilitate communication between different heterogeneous protocols. In addition to federation silos, another anti-pattern we see in large-scale federation deployments, is the spaghetti identity. You create many point-to-point trust relationships between multiple identity providers and service providers.
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.
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.
While the initial consumerization hype was focused on the bring your own device (BYOD) trend, we are now seeing the emergence of bring your own identity (BYOID) concept.
The rise of BYOID is being driven by users' "identity fatigue."
Users have too many accounts, too many usernames and too many passwords. When the competition is literally a click away, organizations must enable the easiest user experience possible or users migrate to sites that offer the simplest registration and login process. Many web sites have moved quickly to accept identities from popular online identity providers like Facebook, Google and LinkedIn.
A 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. BYOID (Bring Your Own IDentity) is not just about bridging social identity with enterprise identity - it is also about bridging different heterogeneous identities between different corporates or enterprises.
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. You are not able to talk between silos.
SAML was mostly used to facilitate web single sign on. It can be just within the same domain or between domains. SAML V2.0 - in 2005 - was built on that success. It unified the building blocks of federated identity in V1.1 with the inputs from Shibboleth initiative and the Liberty Alliance's Identity Federation Framework. It was a very critical step towards the full convergence for federated identity standards.
OpenID, in 2005 - followed the footsteps of SAML. It was initiated by the founder of LiveJournal - Brad Fitzpatrick. The basic principle behind both OpenID and SAML, is the same. Both can be used to facilitate web single on and cross-domain Identity Federation. OpenID is more community friendly, user centric and decentralized.
In mid-January 2008 - Yahoo added OpenID support - late July MySpace announced its support for OpenID - and late October Google joined the party. By December 2009 - there were more than 1 billion OpenID enabled accounts.
It was a huge success in web single sign on - but started to fade - after OAuth 2.0 and OpenID Connect. One of the very popular and very first OpenID Provider - MyOpenID - was shut down on 1st of February 2014. But SAML - still stable as it was ten years back.
OpenID Connect - has some history. It has its roots in OAuth 2.0 - although its been developed outside IETF - under the OpenID Foundation.
OAuth 2.0 is a framework for delegated authorization. Its a misconception to think it does authentication. OpenID Connect is the one built on top of OAuth 2.0 to do authentication. As in the case of SAML and OpenID, both OAuth and OpenID Connect can be used for web single sign on and cross domain identity federation.
Building a setup from scratch to fit into these standards is not hard. Say you’ve got Liferay - which supports OpenID. You can enable federated login to Liferay, to a partner - who is having an OpenID Provider, deployed over its own user store. Similarly, if you have a SAML 2 Identity Provider deployed in your environment - you can federate that identity to cloud service providers like Salesforce or Google Apps. Basically, that means - the users from your domain will be able to login into Salesforce or Google Apps using their corporate LDAP credentials. That’s the easy part of BYOID. How do you handle a situation where you have a partnership, and the applications running in your domain - secured with SAML 2.0 - should be accessible to your partner, who is only having an OpenID Connect Identity Provider.If you support true BYOID - with no code changes - you should be able to let a user from the partner domain with an OpenID Connect token - to log into your application which is secured with SAML 2.0.
Internet Identity always - has an unsolved problem. Very frequently you will see new standards and profiles are popping up.
SAML was dominating the last decade and still to some extent - OpenID Connect and JWT could be dominating the next. As we go on - as we move one - there will be lot of legacy around us.
We need to find a way to get rid of these federation silos and build a way to facilitate communication between different heterogeneous protocols. In addition to federation silos, another anti-pattern we see in large-scale federation deployments, is the spaghetti identity. You create many point-to-point trust relationships between multiple identity providers and service providers.
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.
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 frictionless. 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 frictionless. 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 a new identity provider is frictionless. 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 frictionless. 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.
- Centralized access control.
- 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.