The cloud is fueling an explosion of secure new services, but not every company is equally able to tap into this trend. While identity as a service (IDaaS) and the cloud are changing the game for small and medium businesses, the sheer scale and complexity of the Fortune 1000 enterprise makes it difficult for these long-established companies to reach beyond their borders securely and completely. Their customer bases may cover the globe, but their underlying infrastructures are so complicated -- and their need for security so paramount -- that such companies don’t have the agility to navigate into the new services stratosphere.
While smaller organizations can easily outsource their identity infrastructure, why is it so much more difficult for larger companies to reach the cloud? Today’s sizable enterprises are facing two diverging trends when it comes to applications and security. First, they are charged with securing more users who are accessing more applications from more places through more devices than ever before. Second, the number of identity data sources and the diversity of representations -- LDAP, AD, SQL, APIs -- are growing at the same rate, which is to say, exponentially.
So much heterogeneity is pushing the boundaries of traditional identity and access management (IAM) beyond the breaking point, at a time when security is becoming increasingly essential -- and difficult to ensure, given today’s complex and highly distributed identity systems. All this leads to a classic n-squared problem where companies try to make many hard-coded connections to many different sources, each with its own security protocols and data access requirements The result: costly custom deployments and even greater complexity.
Custom-coded connections between diverse data stores and applications can be very costly.
The good news is that in the domain of security and single sign-on (SSO) across Web and cloud apps, this n-to-n problem is fueling the rapid adoption of federation standards, such as Security Assertion Markup Language (SAML), OAuth, and OpenID Connect. But as many companies are discovering, deploying federation requires more than simply federating the request for access to some “abstract” identity provider.
While federation funnels access to an identity provider, identity integration is often required to feed your identity provider with cohesive views of identity that match the needs of consuming applications.
To make this solution operational requires some form of smart normalization and integration of identity data. This is a big challenge for established companies that are not in a greenfield deployment where identity information exists in a unique, clean, and validated state.
In the ideal world, an identity provider should be able to call a single normalized source of identity for validating a request of authentication. But most Fortune 1000 companies are grappling with fragmented identity infrastructures, where identities and attributes are scattered across different identity data stores. The identity provider is not designed to find users across data silos or sort out protocol differences and user overlap (although there are products that do exactly that). It requires a unified, normalized view of identity against which it can authenticate users, and to issue the appropriate tokens to connect those users to Web or cloud-based applications outside the security perimeter.
But coming up with a global view of users from across a diverse, distributed architecture is not a quick or simple task for most large organizations. What you need is some form of integration layer that can also federate your identity sources -- as SAML and the other federation protocols federate access itself. All of these sources have to be federated because each one contains attributes or pieces of identity information that need to be reconciled out of existing data. After all, no Fortune 1000 company began its business yesterday.
Integrate and orchestrate identity with a federated layer.
Instead of imposing one unique centralized system on top of all of this complexity, a federated integration of your identity sources should offer a rationalized view of the entire system, with all of the flexibility needed to respond to new demands and opportunities. By integrating identity and attributes from across data silos, this federated identity layer builds and maintains a global list of users that is curated dynamically across all enterprise systems, then maps that data to meet the unique expectations of each consuming application.
With a federated identity layer, your identity provider can authenticate against a rational, common view of identity, while each user store maintains autonomy over its own data. Of course, any changes would need to be synchronized automatically, in as close to real time as possible. By keeping track of all users and their associated identity information, including multiple or overlapping usernames, this layer should enable fast, accurate authentication and authorization for all your applications.
These are the essential steps to keep in mind when building a federated identity layer.
1. Inventory your current data sources, and extract and unify the metadata
The first step in building an identity integration layer is gaining an understanding of all of your endpoints. You need to inventory all of the user stores to which you’re extending access, as well as understand how each application interacts with these underlying stores, including how they authenticate and gather authorization information, what queries they send, and what kind of hierarchy they’re expecting. Once this is complete, your integration layer can begin to understand the relationships in the data (such as whether there are same-users across the stores, and how these duplicate accounts can be reconciled), enabling it to provide complete identity information from across the enterprise to every application in the manner it requires.
Larger organizations often store identity and attributes across an array of repositories, each using different protocols and data models. A smart federated identity system should be able to bridge these diverse systems to create a common object model. Such a system must be able to discover and extract the metadata, or identity representations, from each source and map this information to a common naming. This is critical for being able to correlate identities and represent the unique identity in a format that’s consumable by applications.
If there is no user overlap across the data sources, an aggregation of all identities is typically sufficient. If the same user is located in multiple sources, correlation logic is required to link these common accounts so that they are represented only once in the virtual view.
2. Aggregate and correlate identities to build a unique reference list
One of the main challenges large organizations face when attempting a move to the cloud is not only multiple user stores, but user overlap across those stores. This is a major roadblock to federating identity. The ideal foundation for authentication is a single global user list where each user is represented only once, not many different lists across which users might be scattered. You'll want all of a user’s attributes located in one logical location for authorization as well.
The solution is to create that single list of user profiles containing all of their information, and the best way to do that is by integrating identity from across all identity stores. Once your inventory is complete, you can start extracting the schemas from your back ends, then correlate same-users to create the global list.
For the most flexible system, it’s essential to map all identity schemas to a common naming structure, correlating same-user accounts across identity silos, so that there are no duplicate identities in the global list. In cases where the user is located in more than one source, the system should maintain the links to the local identifiers. This enables the system to function more efficiently during the credentials checking step of authentication -- key for speeding up the authentication process and enabling SSO. Instead of performing a time-consuming, round-robin search of all of the data sources, the system would check only those repositories in which the user has an account.
3. Join identities to create global profiles
Once the global list is created, you can enrich the users’ profiles with attributes from all of their local accounts through the join operation. Different applications require different aspects of a user’s identity, so it’s important to combine every aspect of that identity from across all sources into a rich global profile for authentication and authorization.By federating all of your identity sources, you can join these aspects into one global profile, easily accessed by the identity provider to package into security tokens for consuming applications.
For each user with overlapping identities, the integration layer should be able to pull all attributes from the original identity sources and include them in the global profile. Credentials should be kept in the original data source, with identity correlation ensuring that users with similar names are not given inappropriate authorization.
4. Rationalize groups
Instead of having to search across multiple sources to find groups and members, the identity provider should need only to search against the integration layer to check for group membership, speeding logins and access. If your existing groups are sufficient for enforcing your policies today, you shouldn’t have to redo any work when you deploy a federated identity layer. That layer should virtualize your existing groups, with the translation and DN (Distinguished Name) remapping happening automatically.
When basing authorization on group membership, the federated identity layer should be able to rationalize and aggregate existing groups, flatten nested groups if needed, and even compute dynamic groups with members across multiple sources. It should also allow you to compute “member of” values that define the relationship between the group and the user entry itself.
5. Cache resulting views for speed and scalability
An advanced identity integration layer sits between your current directory infrastructure and the applications that access it, isolating them from changes on the back end. This layer needs to be highly available, scalable, and fast -- sometimes even faster than the underlying back ends, in order to provide quick and reliable access to applications for all users no matter where or how they are stored.
Such a layer should also offer a choice of persistent caching options based on your deployment requirements and environment, so entries, queries, or modeled views can be cached for higher performance and availability, in real time or on a scheduled basis. The persistence of materialized hierarchical views means query performance would no longer be constrained by complex joins and searches across multiple data sources.
A proposed architecture for how a federated identity layer fits within the federation landscape.
With a federated identity layer, large enterprises can streamline their identity infrastructure while respecting existing investments, making it far easier to feed their identity provider and securely deliver on the promise of federation. But such a layer also provides a flexible infrastructure and architecture pattern that goes beyond the immediate challenge of federation, enabling many other use cases, such as authentication for Web access management, finer-grained authorization for highly secure data or apps, complete customer profiles, faster application deployment, and even easier M&A integrations. Building an identity integration layer can solve federation challenges today, while enabling companies to tackle any new challenges that arise tomorrow.
Michel Prompt is founder and CEO of Radiant Logic. Radiant Logic’s RadiantOne Federated Identity Service features an advanced virtualization engine and a “big data” driven directory store, both fine-tuned to give enterprises a global and contextual view of all users that’s scalable to hundreds of millions of queries and users.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.