Do you have you head in the cloud?

Let's face it, we technologists have a passion for fads and buzzwords. Just a few years ago, everybody was talking about SOA, and it seemed that every large enterprise was developing a SOA strategy. An army of SOA vendors sprang up from nowhere, offering to help companies become "SOA compliant" (whatever the heck that meant). CIOs, in many cases dazzled by slick marketing executives, issued directives to their staff about the urgent need to embrace SOA or perish. Never mind that SOA had existed in various forms since the release of CORBA in the early 1990s, and perhaps even before that. It simply hadn't had a cool acronym like SOA before.

The same is true of AJAX. Everybody wants to build AJAX applications today, as if AJAX represents a revolutionary breakthrough in web technology. Yet the underlying concept of AJAX (which, let's be honest, is nothing more than Javascript and DHTML) has been in widespread use since the Netscape/IE days. Hell, I recently unearthed an IE5 developer guide from 1999 in my basement, which contains code samples almost indistinguishable from what you can find in most AJAX applications today. We just didn't call it AJAX in those days.

My point in this. If you spend long enough in I.T., you begin to see the same architectural trends and patterns repeat themselves every few years with different marketing labels attached. Which brings me neatly to cloud computing. Perhaps I'm becoming old and cynical, but a cloud application is in most cases little more than a very sophisticated website. For instance, GMail is widely described as a cloud application, but it is ultimately just a web based email client. Hotmail was providing exactly the same service in 1996, albeit in a more primitive form. The same applies to Box.net (XDrive in the 1990s) and even Facebook (Geocities circa 1994). Admittedly, present day cloud services (see, even I'm using the term now) are often characterized by open APIs that enable integration with other systems, but exposure of an API is not mandatory to be classified as a cloud application. If you have a slick website that delivers a service to end users, nobody is going to correct you for calling it a cloud application.

The IAM community isn't immune to the lure of faddish marketing terms. We often talk about "cloud based identity" or "identity in the cloud", as if we are describing revolutionary concepts. But context is important, because cloud-based identity can mean two very distinct things. 

The first definition represents a scenario where a user has an identity in the "cloud" that needs to be managed (for instance if they have a Google Apps or Box.net account). This may imply a requirement not just to provision accounts to a remote service provider, but also to federate credentials across organizational domains.

The second definition is where an identity management service itself is hosted in the "cloud" instead of within the enterprise.

These are two very different concepts, and should not be confused with each other.

Let's begin by exploring the first definition. Managing identities within cloud applications is conceptually no different from managing identities in any other system. You need an API to perform CRUD operations and discovery on the resource. This in turn is abstracted by a provisioning connector, which is invoked by your identity management product of choice. There is no magic involved. A cloud application is nothing more than a JAR (Just Another Resource). Of course, the functionality offered by a cloud connector may be constrained by the capabilities of the public API, but that is true of any resource.

As for federated single sign-on, well, that has been a standard use case since long before anybody began using the term "cloud computing". SAML 1.0 was first published in 2002, and even before there were standards such as SAML, architects such as myself were designing solutions that enabled federated single sign-on to external service providers using proprietary techniques for identity assertion.

The second definition of cloud-based identity is an entirely different matter. I may be wrong, but I'm still not convinced that most organizations are ready to surrender their identity management processes to an external provider. It could be argued that many companies have already gone down the path of outsourcing core HR services, so why should identity management be any different? That's a legitimate proposition, but misses the point of identity management.

Much of the cost of implementing an identity solution exists not in infrastructure, licenses or even support staff, but in the decomposition and automation of frequently convoluted business processes, which require initial and ongoing configuration of even the most sophisticated identity suites. Such costs cannot be avoided simply by moving to a cloud-based identity management offering, as customer-specific configurations will still be necessary, the only difference being that implementers would use an externally hosted web interface as opposed to one hosted on the internal network.

Then there is the issue of how a remote identity service pushes changes to secure systems inside the corporate network. System owners are typically nervous enough about allowing an internal identity management solution to touch their user data, never mind a solution that is hosted externally. 

From an architectural standpoint, a cloud-based identity management solution typically requires deployment of a "gateway" or "interceptor" in the DMZ, which handles inbound CRUD requests and pushes them to the appropriate resource. This introduces a potential point of failure and requires the procurement of additional hardware, which offsets some of the savings realized by outsourcing the identity solution itself.

I'm not completely dismissing the notion of managed identity solutions. Cloud based identity management makes perfect sense for SMBs, who are more likely to have simpler use cases, fewer business processes and perhaps cannot justify the investment in a commercial identity suite. But for a large enterprise, the case for cloud based identity management is somewhat less compelling.

Nevertheless, there is a compromise approach that has much greater potential. I expect to see widespread adoption of identity management appliances over the coming years. Appliances are preconfigured and optimized to run a specific IAM suite, and simply need to be plugged into the network. There are several advantages to an appliance. First, there is less likelihood of instability or performance degradation, as the hardware has already been optimized to run an enterprise IAM solution. Second, both the hardware and software is often supported by the same vendor, so there is less chance of finger pointing should issues arise. Third, customers may realize cost avoidances from not having to procure separate database, application server and IAM product licenses. And finally, streamlined upgrade and patch management can reduce operational burden.

In the meantime, cloud computing is here to stay. At least until the next bright shiny buzzword.