Featured article by Michel Prompt, Founder and CEO of Radiant Logic
Federating access does not mean the battle is over or the war is won; today’s large enterprises are still fighting an identity skirmish behind the scenes. Although federation divides the work between an identity provider (IdP) and a service provider/relying party (SP/RP), this decoupling has not eliminated the need for some form of identity syncing and remapping between the two. While it sounds counterintuitive, the act of externalizing identity from applications to reduce dependencies still requires some form of coordination and identity management between an identity provider and its relying parties. Toreally deploy federation, organizations will need to do some identity syncing and provisioning.
For most companies, it’s difficult to synchronize enterprise identity data with their SPs
Because this operation has to happen for each identity source and target, medium-to-large organizations acting as IdPs—or organizations hosting such IdP functions as a service—are rediscovering a practical requirement: the need for a complete identityhub to simplify the identity orchestration required by the different cloud service. The tasks of such a hub include authentication and authorization, along with the “p” word: provisioning.
Beyond connectors and syncing capabilities, this requirement for a common hub—think of it as a staging engine for identities, whether hosted on-premises or in the cloud—suggests a second coming of the metadirectory, back from the (near) dead, or at least a similarly centralized structure that drives an organization’s cloud provisioning and access efforts.
Federation Provisioning: Seed the Infrastructure, Keep it in Sync, and Remap on the Fly
Basically, the IdP converts an internal identity representation into a token, then the SP converts that token and checks it against the internal identity representation. The result in the authentication operation is the creation of a token through a remapping/conversion operation on the sender’s side and the finalizing of the authentication through a remapping/conversion operation on the receiver’s end. There is a large amount of remapping and conversion required. Even at the level of authentication, it becomes apparent that the systemonly works if enough parts of the infrastructure have been seeded with some form ofidentity list, along with a way to look up identities and map them to the proper format.
Provision customized user information from a central identity hub to different SPs
Dynamics CRM
Shadow IDs: Why the SP Needs a Corresponding Image of Identity
When the IdP is authenticating a user against some internal store, the user must first exist in such a store. Although such a requirement for the “identity provider” is deemed reasonable, it may seem less obvious why an SP should also have some form of corresponding image of this identity. Good engineering designs are developed in a manner in which redundancies are reduced, so federation divides the work between an IdP and SP in order to keep the concerns separated. However, the need to assign an SP with a corresponding image of the IdP identity cannot be avoided. Even if the IdP is the initiator and owner of the identity information, the SP still needs to replicate part of this information for its own internal management. After all, any object requires at least an identity, and in a distributed system, organizations need a way to remap between internal and external “namespaces.” To identify a user of its service, at a the base level, the SP needs some kind of identifier or “handle” for a given user that matches or correlates with the name it’s receiving from the IdP.
A federated identity hub provides the remapping, translation, and synchronization tools needed to keep the SP up to date
In order for the operation to start, organizations must first provision the SP with the list of the identities that will access the services. One bulk upload of those identifiers for a given service might be fine in rare cases, but identities are never static: they go through alifecycle. If a new user is added, deleted or changed, the federation that began at access management is now forced to rediscover the world of identity synchronization and provisioning.
Such services are not described within the federation standards, but they’re essential for securing access to SaaS apps. Although “just-in-time provisioning” has been suggested as an alternative to synchronization and provisioning, the reality and requirements of today’s large enterprise systems are far too complex to be accommodated by improvised and intermittent solutions.
The federated identity hub builds a complete user profile, while delegating the management of identity to each back-end store
Think About How Well Provisioning Went Within Your Perimeter…
Repeating this operation for every underlying identity source in the infrastructure—and for each of the targeted cloud apps—is a challenge. Provisioninghas never been easy, and as organizations extend to the cloud it will only become more involved and complicated. This complexity calls for the establishment of some sort of logical center—a hub where identities can befederated, rationalized, and transformed according to the unique requirements ofeach SP. Think of this hub as a “virtual metadirectory,” combining the best of both worlds so that companies can federate identity across diverse, distributed data silos and provision their SPs without all the pain.
About Radiant Logic
As the market-leading provider of a federated identity service based on virtualization, Radiant Logic delivers simple, logical, and standards-based access to all identity within an organization. The RadiantOne federated identity service enables customizable identity views built from disparate data silos, driving critical authentication and authorization decisions for WAM, federation, and cloud deployments. Fortune 1000 companies rely on RadiantOne to deliver quick ROI by reducing administrative effort, simplifying integration, and building a flexible infrastructure to meet changing business demands. For more information, visit www.radiantlogic.com.
