Turning Identity-as-a-Service Inside Out

Simple question with a surprisingly complex answer: who owns your identity? Our first instinct is to insist that we each own our own identities. After all, we are our identities, right?

Not so fast. There are myriad players who own a piece of your identity, from the credit bureaus to your bank to Facebook to your doctor to your employer. Every single one has some kind of identity management system that keeps track of information about you. In fact, this personally identifiable information (PII) is so powerful that when someone steals it, we call that crime identity theft – as though stealing your PII was the equivalent of stealing your very soul.

The reason PII has such power, of course, is because we give it power. Knowing a username and password gives you the power to access a system. Knowing your Social Security Number and birth date may give you the power to get bank account information from a call center rep. Add a bit more knowledge and you have the power to apply for a loan or a job or a security clearance. The old adage states that knowledge is power, but information only has power if we choose to empower it.

From the perspective of IT, managing user identities has long been in our wheelhouse. The Identity and Access Management (IAM) market matured years ago, and all enterprises have a broad set of robust IAM alternatives to choose from. But hey, it’s almost 2013, right? Why buy some IAM product I have to install and maintain. Why don’t I just get it in the Cloud?

The Problem with Identity-as-a-Service

No brainer, right? Sign up for Identity-as-a-Service (IDaaS), or perhaps call it Identity Management as a Service (IDMaaS) or IAM as a Service (IAMaaS) – the marketplace still hasn’t settled on the term – and you can throw away your Active Directory or LDAP. If all your users want to do is access the Software-as-a-Service (SaaS) offerings you provide, then placing your user directory in the Cloud is an obvious choice. Even when you want to control access to on-premise applications, IDaaS might make sense. After all, your current IAM solution connects to the apps in question over the network as it is. What does it matter whether IAM is running in the Cloud or not? Just put your user directory in the Cloud, configure it to control access to all your apps, and call it a day.

The problem is, this “put all the users in a directory” approach to IAM is increasingly inadequate to cover the kinds of identity management scenarios that we’re facing in our maddeningly complex, interconnected world. But this story isn’t new, either; after all, federated identity standards and technologies have been around for a decade or more. With federated identity, two separate security domains (that is, different departments or organizations with their own IAM systems) can exchange identity information with each other securely. Think of one of the travel aggregators, like Orbitz or Travelocity. Log into the aggregator Web site and you can purchase tickets and hotel rooms and the like, without ever contacting the airline or hotel directly. Behind the scenes the aggregator and the service provider are exchanging secure tokens that contain a bit of your identity, along with the appropriate instructions.

Federated identity is an essential enabler of Cloud security as well, particularly when the enterprise isn’t comfortable moving their IAM to the Cloud. In fact, federating on-premise identity to the Cloud is a central technique we discuss in our Cloud Computing for Architects course. But it’s not the same as IDaaS, where an organization actually moves its user directory to the Cloud. And federated identity breaks down when there are too many participants in a complex interaction, like the types of interactions that are becoming increasingly common in the Cloud.

So far so good: IDaaS isn’t right for every organization today, but it could easily belong somewhere on your Cloud roadmap. But even when you reach a level of maturity where you’re comfortable moving your IAM to the Cloud, IDaaS still falls short, because it doesn’t take into account how we as individuals would like to think about our identities. From the perspective of the user, IDaaS moves the control over our own identities even further away from the user – and that’s not the way we consumers view the Cloud. From the perspective of the user, the Cloud should empower us. IDaaS does the opposite.

Identity as a Cloud Resource

The reason so many vendors fell into this trap with IDaaS is essentially the horseless carriage problem: we have IAM, we want to move to the Cloud, so let’s put IAM in the Cloud – instead of rethinking the problem from the perspective of what the Cloud actually means. So, let’s think about this problem in an entirely different way. Instead of beginning with the user directory at the heart of every IAM offering, let’s begin with the user identity itself.

Essentially, we’d like to have some kind of avatar: a digital representation of our identity that the user controls for themselves. In other words, something like a digital wallet or key ring that manages PII on behalf of the user. Such technologies have been around for a few decades, of course; in fact, the whole idea of a digital wallet dates from the dot.com era in the 1990s. But such technologies didn’t take off, for two reasons. First, big companies didn’t like the idea of giving their customers control of their own identities. Second, we didn’t have the Cloud.

Let’s put off the discussion of control for a moment, because putting the Cloud piece into the puzzle will help us deal with the control issue. We need to consider the Cloud, however, because it changes everything. What the Cloud brings to the table is not just the ability to treat identity management as a service. It also enables us to treat identities themselves as Cloud resources.

As we discussed in an earlier ZapFlash, there are many different types of Cloud resources, including servers, storage, networks, queues, etc. Furthermore, the list isn’t fixed. As Cloud Computing matures, we expect and encourage new types of resources. What makes them Cloud resources is that the user is able to dynamically provision and deprovision them with minimal management effort or service provider interaction.

So, let’s take the notion of a user identity – or to be more precise, the user’s avatar – and consider it to be a Cloud resource. The user, that is, we can provision such avatars as we see fit. And because they’re in the Cloud, they’re location independent. Facebook could use our avatar. Assign it privileges or other properties. Or our bank. Or our employer. But we control it.

Furthermore, we can choose how we control our Avatar. We may wish to log into its Web interface, but that’s only one option. We could also use a hardware device like a flash drive or a USB dongle. We could add biometrics to the device, say via a fingerprint reader. Or we could install software on our computers that would enable us to control the avatar.

Treating identities as Cloud resources can also provide privacy boundaries. For example, I might instruct my avatar to provide my Social Security Number to my bank and the IRS, but not to Facebook. And of course, one of the primary benefits of this approach is that I can maintain my personal information in a single place. If I move, I notify my avatar, and everyone I’ve authorized to see my address automatically gets the update.

The ZapThink Take

In fact, treating identity as a provisionable Cloud resource – an avatar in the Cloud – makes so much sense that you might wonder why nobody has already made a billion dollars on this idea. The answer, of course, is control. Remember all the hullabaloo when Microsoft tried to position Passport as a general purpose identity store? Customers rebelled and Microsoft ended up in court – several times, in fact. Fundamentally, nobody wanted Microsoft to be in control of our identities.

Today we’re going through a similar situation with Facebook, Twitter, and the like. Why bother creating yet another login with yet another password to forget, when we can simply log into that new site with our Facebook ID? Yes, we all go along, until we eventually realize we really don’t want to give Facebook so much control over our online identity.

The Cloud, at least in theory, shifts this control to the user. The user should be responsible for provisioning Cloud resources. Yes, there needs to be software behind the scenes that makes provisionable avatars work and keeps them secure, but if they are truly Cloud resources, the Cloud service providers won’t control them. Their customers will.

Image source: Sundaram Ramaswamy