I just finished reading Mike Vizard’s excellent post, “Authentication in the Cloud” and I thought it would be worthwhile to go into more depth about the issues regarding authentication and cloud computing. While the topic seems pretty straightforward (“validate my username/password”), it gets incredibly messy very quickly.
Before I talk about authentication in the cloud, let me review something more mundane: authentication on your private network. What happens when you login to your machine and then try to access some resource, say a file server or database, on your network? Yes, of course, when you login to your computer, something needs to assure that your username and password are valid.
If you’re logging into a Windows machine, this authentication is performed by a component called the “Local Security Authority Subsystem Service”. If you run Windows Task Manager and list the running processes for all users, you will see a program called “lsass.exe” – that’s the one. By the way, if you run Likewise on a Linux/UNIX/Mac machine, you will notice that we add a daemon called “lsassd” – guess what that does?
LSASS (Microsoft’s or ours) can authenticate a user one of two ways: using “local” credentials or using Active Directory credentials. If your machine is “joined” to Active Directory, you will typically login to your machine with your AD account (including the appropriate “domain” name). If your machine is not joined to Active Directory (it’s in “workgroup” mode), you will login to the machine using local credentials. In the local case, your username and password are validated against account information stored on your own machine. In the AD case, however, something more significant happens: LSASS authenticates your credentials using the Kerberos protocol to talk to an AD domain controller.
Kerberos is a wonderful thing. It can authenticate credentials without ever transmitting a password in either clear or hashed form. This is important because it makes it impossible to perform offline password cracking (i.e. trying millions of passwords until the cracking code matches your hashed password). Kerberos is also great because it supports single sign-on. Once you are logged in to your machine, you have a special “ticket” that can be used to acquire additional tickets for other services. Once you are logged on to your machine, if you go and access a Windows file server, the file server will not prompt you for credentials if your logon credentials are sufficient. Under the cover, the authentication code automatically acquires a “service” ticket for the file server based on your logon ticket. If you access a SQL Server database or a Microsoft IIS-protected web site, again, you don’t need to enter additional credentials because the necessary service tickets are automatically acquired. Nifty.
If you logged in using local credentials, you don’t get any of this goodness. When you try to access a file server, it will perform older “NTLM” authentication and realize that it doesn’t know anything about your local account – if the files on the server are protected, you will be prompted for credentials in order to access them. With SQL Server and with IIS you’ll need to use more primitive authentication techniques (“SQL authentication” or basic authentication, for example).
Challenges of Authentication in the Cloud
Consider now “the cloud.” Or, rather, clouds, because you’ll find several offerings that fit under the cloud umbrella.
Well, first consider that the initial cloud that any of us will encounter is really “the local VMware datacenter” or as it’s now being called, “the Private Cloud.” No problems with the Private Cloud – it’s connected to our network and can fully participate in the goodness of Active Directory and Kerberos.
The second cloud we’ll encounter is “the Hybrid Cloud” – an external cloud of computing resources that serves as an extension of the internal datacenter allowing workloads to be offloaded as needed. How authentication takes place in the Hybrid Cloud depends on exactly how its implemented. Many in the cloud business, however, suggest that it should be connected to the Private Cloud via virtual private network (VPN). If this is the case, the external cloud resources are effectively part of the internal network and we’re back to the simple Private Cloud scenario.
So, finally, let’s consider the “Public Cloud.” This is where things get messy.
The Public Cloud is generally defined as being external to the companies that use it. It is where SaaS-type applications (typically web-based) will run. Microsoft’s Azure platform, for example, defines a very compelling set of libraries and software architecture that simplify the creation of massively scalable apps. “Let a hundred [web app] flowers bloom”, to misquote Mao Zedong. How does authentication work in this context? When you login to a web application, how are your credentials validated? The answer is, unfortunately, “all kinds of ways” – LDAP, database lookups, file lookups, even Kerberos, sometimes.
Tower of Babel in the Clouds
The problem with this lack of cohesive authentication strategy is that it makes it difficult to effect things that we take for granted in the Private Cloud. When somebody leaves the company, how do we disable his/her user accounts on outside SaaS apps? How do I keep track of my passwords for all my various applications, since they don’t support single sign-on? How can we enforce password policies when no two systems use the same authentication mechanism?
We are just beginning to solve some of these problems. SAML (Security Assertion Markup Language) and ADFS (Active Directory Federation Services) are protocols, for example, that allow “identity federation.” They enable apps that run on the Public Cloud to authenticate users with their own corporate credentials. SalesForce, for example, allows you to login with your own corporate username and password if you set up a federation agreement with them. Unfortunately, identity federation is well defined only for some simple web application use-cases. There’s no easy way for me to back up my local disk to a Public Cloud service automatically using my corporate credentials to authenticate me to the service. I can’t write a local application that accesses a SQL database on a Public Cloud that enforces security using my federated corporate identity.
Ultimately, we need to remove the distinction between corporate and web authentication – all authentication should be based on Internet-routable protocols and the nature of identity federation should become simpler (there should be no need for internal/external identity federation servers).
This will take a long time – Microsoft’s version of LSASS knows nothing about web-based authentication protocols. When we do figure this out, however, we should make sure that we do not lose the many benefits of our current mechanisms. Kerberos is a great security protocol, offering the user much convenience. Let’s figure out how to more broadly apply it in the Public Cloud context.