We’re on the edge of an explosion in what we can do with cloud identity. As I mentioned in “Reflections on RSA Conference 2013,” the most interesting session I attended at RSA was called “Emerging Conflicts In Identity Space,” a panel discussion moderated by Todd Inskeep, senior associate at Booz Allen Hamilton. On the panel were some of the best-known thought leaders in cloud identity: Michael Barrett, PayPal’s chief information security officer; Andre Durand, Ping Identity’s founder and CEO; Chuck Mortimore, Salesforce.com’s vice president of product management, identity and security; and Eric Sachs, Google’s group product manager for identity. Across the session and all four panelists, several major themes emerged.
Passwords Aren’t a Sustainable or Scalable Model
Although the identity community has been preaching for years that passwords aren’t sustainable, it’s become cliché to hear it. The problems with passwords have now become painfully apparent to everyone: Whether you’re an identity expert or retired elementary schoolteacher, passwords are a woefully inadequate authentication solution today. Sure, we have to remember many passwords to log on to cloud service providers (CSPs) such as Facebook or Amazon. But the password problem is worse than that, because it’s not a one-to-many (one desktop to many CSPs) relationship any more. It’s a many-to-many relationship in which the user might be authenticating to these CSPs from a desktop, tablet, or mobile phone. And it gets worse! If you choose to use multifactor authentication (e.g., Gmail, Facebook), every app that accesses these CSPs requires its own, unique password—or at the very least requires that you input a PIN that has been sent to your cell phone. I can tell you from personal experience that using Gmail multifactor authentication across only Internet Explorer (IE) and Google Chrome browsers on my five separate clients (work notebook, desktop, Apple iPad, Microsoft Surface RT, Windows Phone 8) is a real pain. And good luck getting your PIN via text if you’re using Wi-Fi on an airplane!
Eric Sachs told a story about how his mother once described him as the “Internet Password Guy.” Over the past couple of years, though, she stopped introducing him this way. Mystified, he asked his mom why she stopped. She replied, "Do you really want to be known as that guy?" The anecdote received a good amount of laughter. But it was painful, knowing laughter, because the question resonates with us. When a relative or friend gets frustrated because of a forgotten password, I sometimes chime in and say, “I write about ways to fix that problem!”
Identity federation between identity providers (IdPs) and relying parties (RPs) is the accepted way to minimize the use of passwords, and most large CSPs support it. Sachs had some interesting experiences to relate about what Google was seeing in federation adoption. First, CSPs—for example, Software as a Service (SaaS) vendors—were coming to him in increasing numbers, inquiring about how to convert their authentication infrastructure from a local user ID/password store to federating with an identity provider such as Google. Why such a rise in federation interest? No business wants to find itself on the front page of the New York Times as the latest company to have its user IDs and passwords published on the Internet.
However, Sachs said, it turns out that converting a CSP from an identity provider to a federation RP isn’t easy, and there are relatively few tools available to make the job easier. (Ping Identity’s PingOne Application Provider Service is the only tool I’m aware of, and it is itself a cloud service. Did I mention that identity is a confusing topic?) Sachs also said a surprisingly high percentage of enterprises were reverting back from federation. He attributed it to knee-jerk reactions from executives who couldn’t access their SaaS apps due to failures in their on-premises federation service that might not have been designed with high availability in mind. To me, this is a strong selling point of IDaaS solutions, which are strongly designed for high availability and scalability.
Identity Needs to Move From the Perimeter to the Transaction
Mortimore focused on the need to change the way we think about the concept of the perimeter. “The perimeter only works when everyone is sitting at a desktop,” he said. Traditional Identity and Access Management (IAM) systems are built around this notion, but they’re being completely bypassed by mobile devices and cloud services. Not only are these devices working outside IAM systems; they aren’t even the company’s devices.
Mortimore stated that the new perimeter—and perhaps it should be called an authentication point—is identity plus context. Instead of a clear, one-time challenge of user ID and password, it become a much more fluid process. Where are the users? What device are they on? Have they previously authenticated on this device? How many factors did they authentication with? What type of access is being requested in this transaction? This is the next step in authentication, variously called transactional authentication or risk-based authentication. It really is a radical departure from the old way of looking at authentication; Barrett said one reason he enjoys working at PayPal is that the company employs some degree of this method already.
The Identity World's Inflection Point
Durand described identity today as a collection of Lego building blocks. I’ve long used the idea of puzzle pieces to describe the complexity of this market, but I prefer the building blocks analogy, because unlike puzzle pieces, building blocks can be combined in many ways to construct many different things.
And so it is with the web of identity (see “The Strands of Your Identity Web”): All the moving parts—authentication, authorization, account provisioning, auditing and governance—can happen in many places, in many ways, with different protocols, at many different times. It all depends on how and where you’re able to put the blocks together to support the use case.
Durand also used biology to describe the identity environment. Today, he said, it’s mostly like a collection of single-cell organisms, in one-to-one relationships with each other. (A popular example is that of one enterprise IdP to a single RP/SaaS vendor.) You might have a number of these relationships, but they’re all one-to-one.
Identity in the near future, however, will be more like a multi-cell organism in which the relationships won’t be just one-to-one but many-to-many. It will include transactional authentication, biometrics, and a degree of portability that we just don’t have today. An example might be a user authenticating to an enterprise with his or her Google or Facebook credentials, but also presenting other identity attributes to that enterprise that are associated with the user’s bank (e.g., a bank account number for the payroll department to use).
We're close to an inflection point, the knee of a curve at which all this identity flexibility will be available to secure a variety of use cases that the panel hadn’t even thought of a few years ago. Almost all the building blocks—identity standards—are in place for this to happen, if they’re supported and implemented. (Barrett emphasized the value of FIDO Alliance, a narrowly targeted open-standards consortium on interoperable strong authentication that's also easy to use.) But this dramatically more complex identity infrastructure must be transparent to users, especially consumers, because they’ll always opt for the easiest method regardless of its security. Barrett offered a great security design principle: “Consumers go for convenience over all else, and they simply expect security to come with it.”
3 Steps to Identity’s Future
Durand put forth a clear three-step vision of identity’s future. The first is where we are today: extending your corporate identity to the cloud via on-premises federation. The second step is gaining momentum: using an IDaaS provider to do the heavy lifting of this identity extension by simplifying the trust connection between the enterprise and the rest of the world, handling the web of federated trusts to CSPs, providing high availability, and (in the short term) providing password vaulting to create single sign-on (SSO) to CSPs that still require direct accounts. The third step, which might not be realized for years, is portable identity. In this phase, “you have a cloud identity provider that is affiliated with you the individual,” Durand said. “Your affiliation with corporations is temporary and is viewed as credentials being added to your base identity. When you have these corporate credentials, you can get into the corporation. And they’re taken away when you terminate.”
And we’ll have eliminated all but a few passwords. Can I get an “Amen!” from everyone?
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.
