Federating Access through SAML or OpenID Connect is Not Enough—Go the Last Mile with a Federated Identity (Data) Service
With the constant growth and evolution of applications, access devices, user populations (and their identity sources), companies and organizations are facing a permanent challenge when it comes to security and Identity and Access Management (IAM).
Federation standards for Single Sign On (SSO) such as SAML 2.0 or OpenID Connect are shifting from a best practice to a business necessity. And those standards are seeing increased adoption since this approach is also becoming mainstream for access to cloud applications.
But federation standards present a challenge to the existing identity infrastructure. And here’s why. In an approach using federation standards, identities and applications are decoupled and play two different roles. Applications play the role of a “Service Providers” (SP) and identity stores play the role of an “Identity Providers” (IdP). In of the role of SP, an application will only allow access to its functions and resources after authenticating (validating the identity and credentials) a user with an external IdP. In this scenario, the existing enterprise identity infrastructure, with its silos made of heterogeneous data stores, must now act as a global IdP. This is precisely where the deployment challenges begin.
In order to effectively function as a global identity provider, the existing identity infrastructure will require some form of an “identity data integration layer.” A federated identity service based on virtualization can provide such a global view (or set of views) of the user population while keeping the directory image synchronized with each of the local identity silos. In fact, this kind of architecture is already in action in products like Microsoft ADFS. In this specific case, the identity integration layer applies only to identities stored in Microsoft domains and forests.
Federation Standards Solve Only Half of the Problem. Identity Data Integration is the Last Mile Required for an Efficient Deployment of an IdP.
When you secure your applications with SAML or OpenID Connect, this layer routes the authentication requests to a standards-based IdP when a user tries to access the application the first time. But this scenario assumes that you have one authoritative source of identity behind your IdP. In reality—for most sizeable enterprises or organizations—you have multiple silos of identity sources. Sure, in theory you could imagine “turning” each of those identity sources into a local IdP and then daisy-chaining them. But in practice, it will have a severe negative impact on both performance and maintenance by multiplication of configurations and links (see picture 2).
So, without some form of integrated identity data service working behind the scenes, functions such as providing single sign-on to cloud and web applications, password management, and provisioning, face a number of hang-ups in speed and resilience, not to mention security risks.
The Challenge of Identity Fragmentation across Multiple Data Silos
Current identity systems are the result of years of technological evolution, and feature a conglomeration of disparate data silos. Finding, identifying and authenticating users and gathering their attributes across multiple directories, data sources, and protocols (such as Active Directory, LDAP, SQL) to enable authentication, security policies, and smart authorization, constitutes a major integration task.
Beyond secure access, what is lacking is a layer that turns your enterprise into a common identity provider—a layer that integrates and funnels identity information across various silos to external applications in the format needed.
Without such a service, searching, finding, authenticating, and authorizing users across a wide range of repositories means dealing with different identity representations, authentication methods, protocols, and storage systems. In many organizations those constraints are solved in an ad hoc manner, resulting in the multiplication of hard-coded links, configurations, and script logic between applications, identity sources, and security protocols. The end result is a system that is brittle, expensive, and difficult to manage, maintain, and evolve. The lack of tools, methods, and processes to develop and manage internal identity as a common service is hampering enterprise SSO and authorization initiatives.
Federating Identity Data Using Virtualization to Deliver a Complete Enterprise IdP
A well-established solution to the problem of “links multiplication,”—the so called “n2 problem” (result of n number of different end points cross-talking to n number of applications)—is a hub structure.
The same way SAML federates access by redirecting an authentication request from multiple service providers to a common IdP, an identity hub reduces the complexity and the number of interactions between your applications and identity sources (see picture 3.) An identity hub has the ability to extend federation first inward, rationalizing and integrating identity data to support SSO and fine-grained authorization.
A complete federated identity solution should be purpose-built to tackle all of the challenges outlined above—and ready to handle more as the needs of the organization grow. To combine the strengths of technologies such as data model, identity federation, virtualization (mapping identity structures to an identity common model, routing requests, and caching results) and synchronization (“meta-directories”), the enterprise needs to adopt a federated identity service to deliver a modern IdP solution that’s fast, flexible, and cloud-friendly.
Such a service acts as a logically-central identity hub between the applications and the organization’s backend identity stores, hiding the heterogeneity of those stores and exposing a logical, coherent, and secure view of users to both internal and external applications. By shielding applications from the diversity of backend data stores, with their alphabet soup of security means and protocols, enterprises radically streamline the authentication and authorization process, while slashing the number of links to manage and subsequently decreasing IT costs.
A white paper on the subject is available here.[su_box title=”About Michel Prompt” style=”noise” box_color=”#336588″]
Michel Prompt, founder and CEO at Radiant Logic, is a successful serial entrepreneur. Prior to founding Radiant Logic, Prompt founded Matesys SA, a company that introduced the first Windows 2.4 file-manager and one of the first visual programming tools for the client/server market.[/su_box]
