This vendor-written tech primer has been edited to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
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.
Figure 2: While federation organizes access, identity integration is often required to give your IdP cohesive views of identity that match the needs of consuming applications. Click on image to enlarge.
Sign up for CIO Asia eNewsletters.