Enterprises are moving more and more applications to cloud every day. One of the biggest challenges for cloud deployment is being able to authenticate cloud application users with existing on-premises identity sources. These identities on-premise are typically scattered across multiple different repositories, what we call “identity silos”.
In most cases, it is a two-step process to make use of these enterprise identities, which I’ll refer to as the “2C approach”. In the first step, you must consolidate identity silos. In the next step, these identities will be consumed for authentication by cloud applications. Before covering the 2C approach, let’s first review how these silos of identities are formed.
How identity silos form
Have you ever received a telemarketing call from a bank asking if you are interested in applying for a new credit car—not once but repeatedly? You are annoyed. “Why am I being contacted so often when I already have a credit card from the same bank?” you ask yourself “And why would a company waste their precious dollars on something that is not going to bring them any business?” The reason is simple. It’s not that they intend to do it that way, but it is because of their somewhat faulty identity infrastructure.
Though banks may have the same brand name for their different products such as retail banking, mortgages, credit cards and mutual funds, these are actually individual business identities. Internally their retail banking is not connected with the credit card unit and vice-versa. At the same time all these different business units have very valuable information about their customers’ identities that they can use for cross selling. As individual business units are managing these identity stores separately, telemarketers have no way to find out who are the common customers for both credit cards and retail banking. They simply take the data from retail banking customers and blindly start selling them their credit card offers without knowing whether a few of them already have the credit card from their own bank.
Why are identity silos formed?
The telemarketers’ database seeded by disparate sources is just one example of how identify silos form. Silos of identities may be formed for a variety of reasons. A large enterprise typically has their centralized LDAP or a database to manage identities or at least they may try to maintain one. If a small department wants to deploy a tiny application for their own specific use, there is a complicated bureaucratic process to get access to the central identity store. So an IT person may decide to deploy his or her own identity store for the department. Think about what would happen when all the departments pretty much do the same thing. Sometimes there are political reasons as well. An IT administrator in a department doesn’t want to give control of his identity infrastructure to the centralized corporate team. Whatever the reason, over the years, a large enterprise accumulates a significant number of silos of identities, even though it is not desirable.
Pragmatic solution to fragmented identity silos
Identity in itself is a critical and expensive resource for an organization whether it’s in silos or centralized. If one wants to deploy an application for the whole enterprise, of course it’s much easier for them to do that if the identity store is centralized. Unfortunately it’s rarely found that way. A relatively ‘easy’ but expensive operation could be to rip apart your silos and create a single authoritative centralized repository, but that requires a lot of time, political and operational changes, and a lot of investment.
Businesses want more ROI from their LDAP infrastructure and that will only happen if your investment for utilizing silos of identities is minimal and rapid. In the past, organizations may have used virtual directories to create a single access point from their silos. Virtual directories have their own limitations. Its performance depends on the weakest link in the LDAP infrastructure. In other words, if some identity silos are significantly slower than others, it’s difficult to get an optimal performance.
A pragmatic solution is consolidate and consume, otherwise known as the “2C approach”.
CONSOLIDATE: A new trend is to create a persistent data cache consisting of a very minimal set of critical identity data as an abstraction layer out of all the silos. Authentication and search requests are still sent to those individual silos so that the current LDAP infrastructure is not disturbed. Some organizations are going for a hybrid approach where part of the LDAP infrastructure is using a virtual directory and another part is using a persistent cache. There cannot be a ‘one size fits all’ approach for solving identity silo problems. The choice of technology must depend on your identity infrastructure, political environment, performance requirement and several other factors.
IBM has a product called IBM Security Directory Integrator that can be used to create a single authoritative datasource out of silos of identities. Federated Directory Server is a feature of IBM Security Directory Integrator, which has several pre-built artifacts for bringing multiple identity stores together rapidly without making any changes to underlying identity infrastructure.
Once you have resolved the problem of silos, you can move to the second step: making use of these identities for authentication.
CONSUME: A typical example is Cloud-based single sign-on service. A user has to be authenticated against the on-premise identities even when accessing Cloud applications. There are different ways to utilize enterprise identities for single sign-on to Cloud. Some single sign-on applications use SAML to connect with enterprise identities. Others bring the identity information into a Cloud directory. IBM Single Sign On for Bluemix provides both of these options. You can use a SAML based component called Identity Bridge to integrate your enterprise identities for authentication. In case you have another product that supports SAML such as Tivoli Federated Identity Manager, you can use that instead of Identity Bridge. An upcoming Cloud Directory Sync feature can also be used to migrate and synchronize enterprise directories with the Cloud Directory. Irrespective of which technology you use for authentication on Cloud, ideally behind the scenes, a single authoritative data source is very useful.
Better ROI, rapid deployment, performance, scalability and extensibility are typically the key outcomes to strive for when creating the authentication infrastructure on Cloud. By following this 2C approach “Consolidate and Consume”, you can rapidly create an authentication framework fulfilling these requirements without interrupting your on-premise IT setup.
Share this post: