Authenticating yourself in the cloud

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 workgroup 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 website, 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 realise 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).