I’ve got good news for you. The best technology for implementing SSO — Kerberos — is something that your organization probably already owns.
If you want to understand why Kerberos is a great technology on which to build your Single Sign-On (SSO) solution, though, we first have to agree on what most organizations hope to achieve through SSO.
SSO Objective
I assert that the ultimate business objective of SSO is to reduce the cost of authentication throughout the enterprise.
Many people argue that the objective of SSO is to eliminate userID and password prompts. It turns out, however, that responding to a prompt for a userID and password takes virtually no time – at least not when the user knows and provides the right information. Therefore, SSO solutions that focus on eliminating userID and password prompts (but not passwords) don’t necessarily meet the business objective for SSO very well.
The most important thing I’ve learned over more than 15 years focusing on SSO is that the majority of the cost associated with managing userIDs and authentication is the cost of managing passwords. The time required to change passwords — and the time and resources required to address problems encountered while attempting to use and change passwords — constitute the vast majority of the cost.
Therefore, SSO solutions that focus on eliminating passwords, rather than password prompts, provide the best business solution.
Non-Kerberos Approaches to SSO
Kerberos is not the only game in town. There are many ways to implement an SSO scheme.
One popular way is to automate the management of userIDs and passwords. Products in this category try to synchronize passwords across multiple accounts. You change your password once and the product changes it everywhere. These products aren’t bad, but they are difficult to use if you have varying password composition rule requirements. If something breaks during synchronization, users still require help desk support.
Another popular approach is to store all of a user’s userIDs and passwords in various places in the network and perhaps even on the internet. The products then try to identify attempts to connect to other systems or websites, retrieve the captured userID and password and pass them under the covers so the end users don’t have to.
The problem with this approach is that you also need some kind of support for password management. These products also pose a security risk. By definition they have a repository of userIDs and passwords that can be read by the product code. It means that this information must be stored in a decryptable manner that the product code can use with no intervention. This creates a pretty tempting target for bad guys.
Both of these approaches have another disadvantage. They require third-party products. This means they have on-going licensing (or perhaps subscription) costs and they require at least one person in the IT organization to manage and support the application. As such, some of the cost savings for end users are shifted to the IT department rather than being eliminated.
The disadvantages of other approaches plus the advantages of Kerberos provide convincing evidence that Kerberos provides the best SSO solution for most organizations. In fact, I base most of my SSO stat! recommendations on Kerberos.
Kerberos Protocol Advantages
Kerberos was designed at the Massachusetts Institute of Technology (MIT) in the early 1980’s to specifically address distributed computing environments. Distributed computing environments are precisely the world we now live in. Windows domains alone are heterogeneous distributed computing environments. Add to that non-Windows platforms like AIX, Linux, IBM i etc. and you have a homogeneous distributed computing environment. Kerberos was designed for the precise computing environments nearly all organizations have today.
Open Source Advantages
MIT put the Kerberos source code in the public domain. This leads to several advantages.
First, the protocol is highly available across all commercial computing platforms including IBM i, IBM z, Apple Mac, iOS, and Android. It is also supported by major Web server implementations including Apache and IIS and also supported by most of the major browsers.
Second, the protocol being in the public domain has allowed it to be highly scrutinized by security experts, who have found it to be much more secure than userID/password protocols.
Finally, being freely available to all vendors, the Kerberos protocol has become part of the base OS for nearly all systems; that is, you don’t pay anything extra to use it.
Security Advantages
There are a couple of security advantages for the Kerberos protocol. One is that passwords never flow across the network during authentication. This is a big advantage. Passwords cannot be stolen via network sniffers.
Another security advantage of the protocol is that stealing a Kerberos ticket does not allow you to impersonate the user represented by the ticket.
Password Elimination Advantages
The Kerberos protocol does not require a prompt for the end user to enter any information. While the user is authenticated, they don’t need to provide any additional information. In other words, the Kerberos protocol eliminates prompts. And as mentioned above, it doesn’t require the user to have a password stored on the systems to which they connect to via Kerberos authentication. This provides the ability for administrators to remove passwords for userIDs on those distributed systems.
Technology You Already Use
Probably the most important reason that Kerberos is a great protocol on which to base SSO solutions is the fact that if you sign into a Windows domain as the first step in accessing your network, then you are already using and managing Kerberos authentication! This means there is very little overhead to begin using Kerberos authentication to access non-Windows systems and applications.
Disadvantage of Kerberos
The major disadvantage for Kerberos is that it requires both the client system and the application server to accept Kerberos tickets for authentication.
From a system access perspective, this usually isn’t a problem as most Telnet servers and Telnet clients and emulators already have the optional to use Kerberos. This is more likely to be an issue for some third-party and/or home-grown applications.
I’ve had quite a bit of success working with ISVs and in-house developers to add support for Kerberos authentication to their applications. However, if your vendors or development team won’t make those code changes, you may not be able to eliminate passwords on the system hosting the server application.
There are alternatives that developers could implement that don’t use Kerberos but would still allow you to eliminate+ passwords from the server application’s host system, but code changes are still required.
Kerberos Meets the SSO Objective
Kerberos meets the primary objective for an SSO solution. It reduces the cost of managing authentication by letting you eliminate passwords for very little additional administrative overhead. It is more secure than using userIDs and passwords.
Kerberos is a viable alternative for the vast majority of customers even if they have a client/server application that cannot be enabled for Kerberos. In those cases, I recommend low-cost password synchronization to support only those systems where passwords cannot be eliminated.
The evidence is clear. Kerberos is a great SSO solution!
