Wednesday, June 2, 2010

Single Sign-On for the Cloud

Jon Stokes from Ars Technica has an interesting interview today with Ping Li of Accel Partners - excerpt: (JS = Jon Stokes, PL = Ping Li)
JS: When you say "the new cloud stack," give me some perspective on how you've seen the evolution of the stack in the past two years.

PL: The evolution of the stack starts with the mainframe, and everyone is always trying to recreate the mainframe by taking advantage of new technologies. So client-server was taking advantage of processing technology. Web services enabled applications to be networked more efficiently. A lot of cloud innovation has been at the data layer—a lot of the interesting things have been with data processing but also with data storage and data transaction. So there's all the movement between, say, the NoSQL crowd and the new cloud-type Oracle databases. So there's been a lot of innovation in that area of the stack.

But even going up the stack, you can see people wanting to recreate the functionalities of a mainframe but in a new world. So, security: what does "cloud security" mean? A lot of interesting companies are doing stuff around single sign-on. You have 15 cloud apps, so how do you manage that in the enterprise—who gets access to what and when? We've seen cloud logging companies—these are all different services that were part of the traditional stack that are now being decomponentized and rebuilt in a cloud framework.

http://arstechnica.com/business/news/2010/05/investing-in-the-cloud-not-revolution-but-evolution.ars
He hits a key question: "You have 15 cloud apps, so how do you manage that in the enterprise—who gets access to what and when?". The problem is that the different cloud apps have different authentication models, which in turn differ from the models used by older enterprise systems. So the Single-Sign On problem for the Cloud is all about alleviating the problem whereby an organization has their internal own identity silos and infrastructure such as SiteMinder and Active Directory / Kerberos, but they wish to connect to Cloud APIs. Local identity tokens such as Kerberos and SiteMinder smsession tokens are no good for fine-grained authentication to Cloud APIs which use OAuth and OpenID. What is needed is a kind of "Identity Router" which understands that "to connect to this Cloud API, we need OAuth, but in this local domain we have a SiteMinder smsession token".




The broker here is providing the "Identity Router" functionality. The dynamic mapping of identity tokens allows for messages to traverse domains, just like a network router allows packets to traverse different networks. The key value of the broker is the breadth of identity infrastructure which it supports. It is no good to support only OAuth and OpenID if you don't support older technologies such as Kerberos and SiteMinder.