Inside the Briefcase

Augmented Reality Analytics: Transforming Data Visualization

Augmented Reality Analytics: Transforming Data Visualization

Tweet Augmented reality is transforming how data is visualized...

ITBriefcase.net Membership!

ITBriefcase.net Membership!

Tweet Register as an ITBriefcase.net member to unlock exclusive...

Women in Tech Boston

Women in Tech Boston

Hear from an industry analyst and a Fortinet customer...

IT Briefcase Interview: Simplicity, Security, and Scale – The Future for MSPs

IT Briefcase Interview: Simplicity, Security, and Scale – The Future for MSPs

In this interview, JumpCloud’s Antoine Jebara, co-founder and GM...

Tips And Tricks On Getting The Most Out of VPN Services

Tips And Tricks On Getting The Most Out of VPN Services

In the wake of restrictions in access to certain...

The Hidden Requirement for Federation: Syncing and Provisioning to the Cloud

February 5, 2015 No Comments

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.

 

Karen image_1

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.

 

Karen Image_2

 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.

 

Karen Image_3

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.

 

Karen image_4

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.

 

Leave a Reply

(required)

(required)


ADVERTISEMENT

Gartner

WomeninTech