The secret to a successful identity provider deployment: federate your identity data with a hub
Companies are securing more users who are accessing more applications from more places through more devices than ever before, and all this diversity is stretching the current landscape of identity and access management (IAM) into places it was never designed to reach. At the same time, security has never been more paramount—or difficult to ensure, given today’s outdated and overly complex legacy identity systems. I call this the “n-squared problem,” where we’re trying to make too many hard-coded connections to too many sources, each with its own protocols and requirements.
This n-to-n problem is fueling the rapid adoption of federation standards, such as Security Assertion Markup Language (SAML), OAuth, and OpenID Connect—and that’s good news for large enterprises looking to achieve Single Sign-On (SSO) across web and cloud applications. As many companies are discovering, however, deploying federation requires more than the acquisition of a federation security component. To make this solution operational often requires some level of identity data integration.
Let’s analyze the real world deployment of a key component—the identity provider (IdP)—that you need to achieve SSO to federated web or cloud applications. Federation standards only provide a layer to funnel authentication requests from an application, such as a SaaS application like Salesforce, to an identity provider. Upon receiving the authentication request, the IdP needs to carry out the authentication operation—and that’s where things get tricky.
In the ideal world, an IdP should be able to call a single identity source. But in real life, we have a fragmented identity infrastructure, where identities and attributes are scattered across different data stores, including Active Directory domains and forests, Lightweight Directory Access Protocol (LDAP) directories, databases, and APIs, as we see in the picture below.
TheIdP layer is not designed to find users across diverse data silos or sort out protocol differences and user overlap. It requires a unified view of identity against which it can authenticate users, and issue the appropriate tokens to connect those users to web or cloud-based applications outside the security perimeter.
To federate access to external applications, the IdP relies on a single “normalized” source of identity—and coming up with such a global view of users from across a diverse, distributed architecture is no easy task for most large organizations. What you need is some type of integration layer that can also federate your identity sources. This integration layer—really, a smart hub for all your identity stores—feeds your IdP with exactly the right information it needs to enable SSO and secure access across your entire application portfolio, from enterprise to web, cloud, and even mobile or social.
Integrate and orchestrate identity with a federated hub
Why a federated architecture for the hub instead of a simpler centralized repository for identity data Because centralization is part of what got us into trouble in the first place, adding to the fragmentation of today’s typical identity infrastructure. Most sizable organizations have complex identity systems for a reason, so rather than trying to impose one unique centralized system on top of all this diversity, it’s better to think about a smart integration of all your sources that gives you a rationalized view of the system.
Essentially, we need to “Manage Globally, Act Locally,” creating an intelligent hub with a logical center that respects the periphery. By integrating identity and attributes from across data siloes, the federated identity hub 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 such a hub, your IdP 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, so you’re not authorizing access to the disgruntled employee you just fired or blocking executive access when a title changes. By keeping track of all users and their associated identity information, including multiple or overlapping usernames, the hub enables fast, accurate authentication and authorization for all your applications.
Let’s dig a deeper into the essential capabilities of a federated identity hub:
Step 1: Inventory your current data sources and extract and unify the metadata
The process of creating an identity hub begins with an inventory of your current data sources. Larger organizations often store identity and attributes across an array of repositories, each using different protocols and data models. A smart federated identity system can bridge these diverse systems, extracting the metadata from each source to create a common object model.
Step 2: Aggregate and correlate identities to build a unique reference list
Once the existing schemas have been extracted, you can see how each data source defines identities and determine the best way to aggregate and correlate your identity data, in order to build a reference list where every user is represented only once. Using the schema information and the knowledge about any overlapping attribute values, you can create the correlation rules needed to create a unique global profile for each user.
Step 3: Join identities to create global profiles
Different applications require different aspects of a user’s identity. Identity federation gives you the ability to join these aspects into one global profile, easily accessed by the IdP to package into security tokens for consuming applications. Credentials are kept in the original data source, and identity correlation ensures that users with similar names are not given inappropriate access.
Step 4: Rationalize Groups
The hub should also be able to leverage and remap existing groups. In such a scenario, the IdP would only need to search the hub to check for group memberships to package into tokens for consuming applications. If you have existing groups that are sufficient for enforcing your policies today, you shouldn’t have to redo any work—the federated identity hub would simply virtualize your existing groups and the translation and Distinguished Name (DN) remapping would happen automatically.
Step 5: Cache resulting views for speed and scalability
A hub would also offer a choice of persistent caching options based on your deployment requirements and environment, so entries, queries, or modeled views could 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.
The federated identity hub: a flexible infrastructure for the future
A federated identity hub can streamline your identity infrastructure, while respecting existing investments, making it far easier to feed your IdP and deliver on the promise of federation. But it 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 a hub can solve your federation challenges today, while enabling you to tackle any new challenges that arise tomorrow, so consider transforming your diverse, distributed legacy identity system with a modern federated identity hub.
Radiant Logic’s RadiantOne Federated Identity Service features an advanced virtualization engine and a “big data”-driven directory store, both fine-tuned to give your enterprise a global and contextual view of all your users that’s scalable to hundreds of millions of queries and users. To learn more about Radiant Logic and RadiantOne, please visit www.radiantlogic.com.