Identity and Access Management (IAM) has always been a complicated subject. The basics haven’t changed much: Who are you? What should you have access to? The third question—How do you prove the accuracy of your answers to the first two questions?—is a relative newcomer compared with simple account provisioning, but it has grown dramatically in importance over the past 10 years, thanks to regulatory requirements such as Sarbanes-Oxley as well as an increase in malware and cybercrime. With the advent of cloud-based identity management as a service (IDaaS) offerings, there are more ways to get these answers from both on-premises applications and the cloud services your users subscribe to. These solutions allow you to rearrange the puzzle pieces of identity management into different configurations to provide varying types of functionality. This month, I’d like to look at where different types of solutions fit into your existing identity management architecture, and examine the emerging puzzle called “from the cloud.” Collectively, Gartner has christened these solutions asidentity bridges because they bridge your on-premises identity systems with cloud systems. I wrote about this topic in more detail in “ Building Your Identity Bridge to the Cloud.”
Cloud Integration
Before I dive into the different identity management architectures you can use, single sign-on (SSO) to a cloud service clearly requires that the user attempting to use the cloud service be authenticated. This is best accomplished with federation between the identity provider (your enterprise and Active Directory—AD) and the service provider or relying party (the Software as a Service—SaaS—provider or other cloud service). What’s not immediately obvious is that, even though federation allows a user to authenticate at a cloud service with an on-premises AD password, practically all SaaS providers require you to have a local account before you can authenticate. There are a number of reasons for this requirement, but the practical result is that for every one of your users who wants to use the provider’s service, a shadow account (of his or her AD account) must exist on the SaaS provider.
Therefore, in addition to an authentication puzzle piece, there also has to be a puzzle piece that handles cloud service account provisioning and, ideally, de-provisioning. Cloud service provisioning is an active topic in itself; for the purposes of this discussion, just know that it’s something that needs to get done as part of working with a cloud service.
The new breed of cloud-based identity management solutions has varying degrees of integration into an existing on-premises identity infrastructure (e.g., AD, an HR system). Some of these solutions are designed to bolt on to your existing identity management environment with as little impact as possible to on-premises identity stores and lifecycle processes. These are IDaaS systems such as Symplified, Okta, and OneLogin. These usually have an on-premises component such as a hardware device, virtual machine (VM), or simply a service running on an existing server that performs several important functions between your company and the IDaaS provider.
First, this local IDaaS component provides some kind of account synchronization between your on-premises identity (e.g., AD) and the cloud identity service to populate the service with your company’s authorized user accounts. A typical method is to synchronize with certain OUs or security groups, populating the IDaaS provider’s account database with the OUs’ or groups’ membership. This method is known as directory synchronization. Other methods are available, such as SAML just-in-time provisioning or System for Cross-domain Identity Management (SCIM). Second, the on-premises IDaaS component also provides a federation gateway between your company and the IDaaS provider. In contrast to the next example, this is a dedicated connection just between you and the provider, and to my knowledge it can’t be extended to any other service provider. Third, these on-premises components act as reverse proxies for the identity service and might also provide auditing and reporting capabilities.
It’s worth noting that IDaaS solutions don’t necessarily require any integration with an existing on-premises identity infrastructure; from their perspective, life is much simpler if you simply create, store, and manage your identities entirely within their offering. Maintaining all these identities in the cloud rather than on premises is a big step for companies with any size of on-premises identities, but it’s very appealing to startups that have no existing infrastructure to take apart.
Going Deeper
The next type of identity bridge requires a deeper level of integration with your on-premises identity management environment. This type is a general-purpose, on-premises federation service that can provide connections to multiple service providers. It’s a traditional enterprise application that you deploy and maintain, and you must establish a federated trust to every cloud service provider you want to have SSO with. Ping Identity’s PingFederate and Microsoft’s Active Directory Federation Services (AD FS) are the better-known examples of this federation capability. This type of solution doesn’t necessarily take care of the account provisioning requirement; how this gets done depends on the cloud service that the identity provider is connecting to. For example, Office 365 requires a directory synchronization component.
Moving more deeply into on-premises identity management integration, many vendors in the traditional enterprise identity management market are adding cloud-based services to complement their existing offering. For example, Radiant Logic, a well-known virtual directory service provider, now also offers an integrated federation service. Centrify, a market leader in the on-premises AD bridge solution (which allows non-Windows systems to use AD), has expanded to offer its own cloud-based SSO to SaaS providers.
These are all what Gartner calls "to the cloud" scenarios: Identities are created, updated, and managed within the enterprise and are extended from these on-premises identity systems to relying parties in the cloud, such as Salesforce, Google Apps, and Concur. A newer breed of identity management solutions, known as "from the cloud," takes cloud involvement a step further by centralizing both on-premises identity lifecycle management and cloud identity management to in a cloud-based (rather than on-premises) management portal.
This puzzle piece arrangement is a substantial conceptual shift for IT, because not only are you managing your new cloud-based capabilities from the cloud (which the Symplifieds, Oktas, and OneLogins are already doing), you're also moving management of on-premises identity stores—one of the bedrock pieces of IT infrastructure—to the cloud. Identropy’s SCUID Lifecycle is the first product of this type I’m aware of; the company describes it as identity lifecycle management and governance in the hybrid enterprise because it manages both on-premises and cloud identity equally.
In this architecture, the on-premises component VM (which Identropy calls the identity connector for the enterprise—ICE) has elevated rights to a wide variety of on-premises identity stores such as AD or SAP and, on direction from the cloud-based Lifecycle service, performs create/read/update/delete (CRUD) operations on them. It also manages account provisioning and appropriate de-provisioning (a thornier issue than simply provisioning accounts) to other cloud services. Identity administrators—and end users if you’ve configured it—use the SCUID Lifecycle web portal to perform their management tasks.
Why might you consider such a solution? First, it would probably save you a lot of money. Traditional on-premises identity management systems are expensive to purchase, deploy, and maintain in both headcount costs and annual maintenance fees. SCUID Lifecycle charges a simple per-user fee that drops rapidly with the number of users. To keep implementation costs down, SCUID has created a set of templates that it believes describes the vast majority of on-premises identity management configurations, and it charges a one-time setup fee to create a semi-custom configuration for your identity management environment based on one of these templates. SCUID maintains it is also very straightforward in telling a potential customer whether it simply won’t fit into one of its configuration templates.
Another reason to think about a solution like this is that it should be easy to work with compared with traditional identity management systems. On-premises systems have complicated and user-unfriendly interfaces—especially for end users. The trend toward simplifying the UI is a good one, and SCUID Lifecycle’s is extremely straightforward. (I also give extra-credit points to Identropy for using “freaking suck!!” to describe traditional identity management systems’ UIs in its product’s web intro.)
A Question of Comfort
Are you instinctively uncomfortable with this “from the cloud” solution? (I know I was.) It’s because you don’t like the idea of having your identity management hosted off premises, potentially more exposed and definitely more dependent on external factors than an on-premises solution. Well, if you lose your Internet connection, you’ll lose all your SaaS applications and the ability to perform integrated identity management, but you can still manage identity through local interfaces (e.g., Active Directory Users and Computers), and the ICE VM tracks and queues up changes to integrate into the Lifecycle system when the connection becomes available again. The real choice is cost savings and time to value versus your acceptable level of risk associated with managing identity using any outside entity.
Identity management technology has been re-energized by all the possibilities the cloud computing model affords us, and a whole market of identity service providers has materialized in the past few years to take advantage of these possibilities. Whether the market will embrace all of them remains to be seen. For your part, you should be paying attention to this evolution; you might come across a variation of the puzzle pieces that fits your needs well.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
