Authenticating users and securely communicating authorization information with a cloud application – or any Web-based portal – requires a common endpoint acting as the enterprise IdP. We know you’ll need to be able to access multiple cloud applications, such as Salesforce, Workday and Google Apps, as your enterprise moves toward this model. We have seen that you’ll need many token translations on a per-application basis. But this is only one part of the requirement.

Another key function to support is being able to authenticate an incoming user against multiple internal authentication sources. Think about all the legacy applications and identity stores deployed across your infrastructure, with their various authentication methods and protocols. They’re all over the map, right? First, you encounter the Active Directory domains, and get lost in all those forests. The authentication method here could be name/UPN and password, or based on Kerberos and Windows-integrated authentication. But the user could also be stored in some SQL database with a proprietary hard-coded password encryption.

Chasing the user across diverse forests and data stores and knowing which authentication method is appropriate for presenting and checking credentials is a full-time job – one that predates the challenge of cloud applications. In fact, the search for a common identity structure has been a primary headache for Identity and Access Management (IAM) for as nearly long as the category has existed. Multiple attempts have been made to solve these issues, from in-house script-and-sync to metadirectories to virtual directories. These new requirements for supporting the cloud have just made it more acute.

No matter what you call it (or how it works) – Whether it’s an enterprise directory, metadirectory, or virtual directory, the logical mechanism, you need is a federated form of identity. Why federated? Because you don’t want to reinvent this layer, which already exists in a highly distributed, heterogeneous way across your identity silos. Better to tap into what already exists, while giving your underlying data more scope and flexibility by bringing it (or a flexible representation of it) into an identity hub. Now, you could implement this hub in many different ways, but a virtualization layer, based on a global data model that rationalizes and reconciles the different local views, is the most effective way to do it. In a world where you will connect to multiple applications using “federation” standards, you need to do more than just federate access via the SaML or OpenID Connect layer. You need to federate your identity layer, as well. And the way to get to a federated identity is through virtualization.

All Roads Lead to the Hub: The Need for a Common Attribute Server and Better Provisioning

But authentication is only the first challenge for bridging your identity infrastructure to the cloud. Beyond providing secure internal authentication, you must also deliver attributes that are required for groups, access rights, and authorization. So as an identity provider, you will need to act as (or be coupled to) an attribute server, and then there is the huge challenge of accounts and attribute provisioning. Despite significant progress in terms of user interface, connectors, workflow, business logic, transaction support and standards (anyone remember SPML?), provisioning on the internal, legacy side of applications has only encountered limited success and remains a stop-and-go process. You need all the features mentioned, but unless you want to go through endless iterations of manual workflow definition, you need an automated system that can normalize the different versions of the truth for your identity, before pushing it through your provisioning and logic engine.

Fast forward and think about the n different applications in the cloud you need to provision to, and it’s like déjà vu all over again…with even more complications. So again, as both a final authoritative source of your identity and as an attribute server, you will need a rationalized view of your identity – a federated identity system.

How such a federated identity service would enable authorization and provisioning to cloud-based applications, using attributes from across your heterogeneous stores. Graphic provided by Michel Prompt, Radiant Logic.