Of all that has been written about cloud computing, precious little attention has been paid to authentication in the cloud.
Before we get to that, let's review how authentication works on a private network.
When you log on to your machine and then try to access a resource, say a file server or database, something needs to assure that your username and password are valid. If you're logging onto 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". If you run Likewise on a Linux/UNIX/Mac machine, you'll see it is called "lsassd".
Either one can authenticate a user in one of two ways: using local credentials or using Active Directory credentials. If your machine is "joined" to Active Directory, you will typically log on with your AD account (including the appropriate domain name). If your machine is not joined to AD it is in work group mode and you log on using local credentials. With the latter, 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 on to your machine, you have a special "ticket" that can be used to acquire additional tickets for other services. If you access a Windows file server, for example, 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 on using local credentials, you don't get any of these advantages. When you try to access a file server, it will perform older NTLM authentication and realize 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
Now consider the cloud. Or, rather, clouds, because you'll find several offerings that fit under the cloud umbrella.
While VMware-powered private clouds can fully participate in the goodness of Active Directory and Kerberos, hybrid clouds involving external computing resources are a different story. How authentication takes place in a hybrid environment depends on how it is implemented. If the external cloud resources are connected to the private cloud via a VPN, the two are effectively part of the internal network and everything should work OK.
Things get messy with pure public cloud options.
Public cloud are generally defined as being external to the companies that use it. It is where software-as-a-service (SaaS)-type applications (typically Web-based) run. How does authentication work in this context? When you log on 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.
The problem with this lack of cohesion is it makes it difficult to affect things that we take for granted in the private cloud. When somebody leaves the company, how do we disable his user accounts on outside SaaS apps? How do users keep track of passwords for all their 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. For example, the Security Assertion Markup Language and Active Directory Federation Services protocols allow identity federation. That makes it possible for apps that run in public clouds to authenticate users using corporate credentials.
SalesForce, for example, allows you to log on 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 you to back up your local disk to a public cloud service automatically using your corporate credentials to authenticate you to the service. You can't write a local application that accesses a SQL database on a public cloud that enforces security using your 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.
Read more about data center in Network World's Data Center section.
This story, "Authentication in the Cloud" was originally published by Network World.