Outsourcing Your Identity with IDaaS

Identity professionals are becoming familiar with federation technology as a secure way to manage Internet single sign-on (SSO) to cloud service providers, but there’s another way to handle Internet identity management that’s gaining popularity: essentially outsourcing identity itself.

Ironically, installing federation services to simplify your Internet identity management increases your on-premises IT environment and skill requirements. It usually requires one—or more, for suggested high availability—server instances in your IT infrastructure, as Figure 1 shows. Some federation products are simple to install, some are complex and require consulting services, but all require some local expertise to install and maintain. A relatively new but growing sector in the identity business applies a cloud-computing service model to this need.

At its core, cloud identity is about securely extending your company’s identity to cloud-computing service providers, and federation is a key component to achieve that. But the federation service doesn’t necessarily need to reside on your company’s premises. Identity as a service (IDaaS) moves the federation service point from within your IT infrastructure to the SaaS provider: Instead of hosting, configuring, and maintaining the federation servers yourself, the service provider hosts the servers, as Figure 2 shows.

How Does IDaaS Work?

Because your identities are still required for federated single sign-on, an agent or server is installed inside your company’s firewall that can perform LDAP queries against your Active Directory (AD) domains to obtain user and group objects. The agent has an LDAP over HTTPS (LDAPS) connection established with the IDaaS provider, which mirrors the desired AD objects to a local LDAP store such as AD Lightweight Directory Service (AD LDS). Generally, the user’s password isn’t mirrored to the IDaaS provider’s data store. Because the agent-to-provider connection uses HTTPS, no extra ports need be opened in the firewall to allow the traffic.

To access SaaS applications, the user authenticates to the IDaaS provider (for example, to http://usercompany.idaasprovider.com) with his or her enterprise account and password. Because the IDaaS provider doesn’t store the user’s password, the authentication request is passed back to the on-premises agent, which actually performs the authentication against the local AD implementation. The successful logon is passed back to the IDaaS provider. A portal then allows the user to choose from a range of SaaS applications that he or she can access without entering any other user IDs or passwords. This is known—in a slightly different context—as a “NASCAR screen” because it resembles an array of sponsor logos on a NASCAR race car.

The scope of AD objects that are mirrored to the IDaaS provider can generally be restricted on a per-OU or per-group basis. Implementations vary depending on the product, but this seems to be the most popular architecture.

IDaaS Benefits

Using IDaaS instead of on-premises federation solutions provides a number of benefits. IDaaS solutions require a very small on-premises footprint—generally, a single server or multiple agents (though a fault-tolerant or high-availability configuration would be desirable for companies that heavily depend on SaaS applications). They’re generally simple to set up and don’t require a highly trained identity staff. They scale well because as you use more and more SaaS applications you don’t need to add more and more federated trusts between your company and the SaaS provider; the IDaaS provider has already established trusts with hundreds of SaaS providers, and you simply access the IDaaS provider. The pricing structure reflects service orientation also, because you’re generally charged based on the number of users who access the service and how many SaaS applications they have access to.

But one of the biggest benefits that IDaaS providers have to offer over on-premises federation solutions is their "one stop shopping" approach to identity management. Depending on the provider you choose, they can offer not only SSO but also access management, account provisioning and de-provisioning, identity management, and auditing as part of the same solution.

Also, because of the service model architecture, the moving parts of identity management are hidden from its users. Users don’t care whether federation, duplicate accounts, or smoke signals are used to provide SSO, as long as it works. IDaaS providers take advantage of this abstraction layer to add technology that makes SSO available for SaaS applications that wouldn’t otherwise support it. For example, many smaller SaaS providers don't yet support federation. In on-premises federation architecture, if the SaaS provider your users want (e.g., a specialized service that caters to a narrow market) doesn't support federation, you're out of luck and must manage duplicate accounts. IDaaS providers use various techniques behind the scenes to automate authentication with these providers, so their users have seamless access to them just as if they were federated.

IDaaS Drawbacks

Every service architecture has its drawbacks, of course, and IDaaS is not without its share. First, as a long-time IT infrastructure guy I'm more than a little uncomfortable with this configuration because I always look for the worst-case scenario. This architecture means you must always pay a service provider—a third party—to maintain and operate the gateway to essentially all your cloud applications. Do you want that kind of vulnerability? What happens if you're tight for cash, or your account clerk misses a payment or two? Are all your accounts suddenly suspended? Do your company’s cloud-related operations come to a screeching halt? And what if you’re a cutting-edge new company that doesn’t maintain any local identity store at all? What happens when you don’t pay the bill? Can you operate at all?

To be fair, the counter argument that small companies and startups generally do a lousy job of maintaining their computing infrastructure also has merit; the IDaaS provider may well increase the customer’s stability. I've seen enough small businesses to know this is an unfortunate reality.

Next, the IDaaS method of user authentication to the service provider is arguably less secure than claims-based authentication because passwords do travel outside the company’s firewall (even though they’re encrypted via SSL) to and from the provider. The security of the session is therefore paramount. The connection should use server-side SSL certificates, and the agent authentication process should be very secure. Claims-based authentication, in contrast, contains no passwords. A counter-argument to this potential vulnerability is that, at a corporate level, IDaaS is more secure than an on-premises federation-only configuration because its comprehensive SSO capability means there will be little to no need to manage duplicate accounts at SaaS providers that don’t support federation.

Another concern is that the IDaaS architecture requires a subset of your identities to be stored off premises. It might be only a subset of your total corporate identities, without passwords, and it’s only a mirror of them (i.e., changes are made to your AD and mirrored to the IDaaS identity database; no changes are initiated at that database), but it’s still a copy of your identity information given to a third party.

Well, federation works in much the same way. It provides identities with some attributes (not passwords), presented as claims, to a service provider. The service provider automatically manages these identities as a mirror of their original status in AD. If an account authorized for federation has its authorization revoked, or is disabled in AD, this revocation is immediately mirrored to the service provider.

Because of its reliance on a single LDAPS session between identity provider and service provider, another potential drawback is that the IDaaS architecture is susceptible to Denial of Service (DoS) attacks. If someone hammers port 443, no one in your company can use SaaS apps or—if you’ve outsourced your identity store to the IDaaS provider—any identity information at all. Of course, this kind of DoS attack would disrupt many other off-premises services as well.

The IDaaS model is popular with small-to-midsized businesses (SMBs) or startups because they have little to no identity infrastructure. If you were starting from scratch today, would you even want to host your own identities locally? If you accept the risks I’ve presented, IdaaS might be very appealing. But interest in IDaaS doesn’t seem to be limited to small companies; some very large enterprises are using it (though I don’t know how broadly it’s used in those companies).

The IDaaS Market

The IDaaS market is small but growing. Much of the work that needs to be done is customer awareness and education; most companies are still in the process of first understanding federation to support cloud computing services, and IDaaS is one layer of abstraction beyond that. Products such as Okta, PasswordBank, Ping Identity's PingConnect, and Symplified are the early and dominant players in this market. An indication of the expected growth of the market, however, is that large companies such as Intel (with its Expressway Cloud Access 360) have recently launched their own IDaaS products.

As cloud computing services continue to expand and grow in popularity, cloud identity solutions are also evolving to deal with these services. IDaaS takes a core piece of the traditional enterprise infrastructure and makes it into a service itself, which allows you to manage access to SaaS applications with minimal effort. As you examine the different ways that you can securely manage your company’s Internet identity, you should give the IDaaS model a close look.

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.