What Is Single Sign-On
In spite of its perfectly descriptive nature, "single sign-on" is a frequently
misused term. SSO means, literally, that you only need to provide a
username and password once and that, subsequently, software will
recognize your established credentials and not prompt for them again.
The "single" part of SSO is typically satisfied when a user first logs in to a
computer. The user types his/her username and password and
establishes a set of credentials that are then respected by software that
is aware of the SSO mechanism.
"Single username/password" is not SSO. Having a single username
name and password that is synchronized across multiple systems but
have to be, occasionally, re-entered is not SSO. Similarly, password
caches or password key rings are also not examples of SSO. Key rings
are essentially "typing aids" that automatically enter passwords for you;
they do not reflect an authentication infrastructure that understands SSO.
When SSO is provided across an entire network of computers and
applications, it is often referred to as enterprise single sign-on. This is the
most valuable form of SSO and the one that this document explores.
References to "SSO" should be understood to apply across the
enterprise.
What Is Kerberos
Kerberos is an authentication protocol that facilitates the implementation
of SSO. It was developed at MIT in the late 1980's as part of the Athena
project. It was originally described in RFC 1510 but its modern
incarnation is described by RFC 4120.
Kerberos is an accepted standard for SSO. It is considered a secure
authentication mechanism, having been designed to withstand common
network attacks (for example, man-in-the-middle and replay attacks). It is
available on all modern operating systems and supported by many
software applications. Microsoft has supported Kerberos since the
advent of Microsoft WindowsÔ 2000.
Kerberos uses encrypted tickets to represent credentials.
• The encryption technique relies on a shared secret (a key) known
to the Kerberos client and the Kerberos key distribution center
(KDC). This secret is based on an account password. When a
user account is created at the KDC, Kerberos stores the shared
secret and uses it to encrypt tickets sent to a client on behalf of
the user. When the user logs into the client machine, he/she
provides a username and password, establishing the shared
secret on the client as well. This allows the KDC and client
machines to communicate in a safe, encrypted, fashion.
• Applications that want to use Kerberos will need to be associated
with service accounts that establish shared secrets on the KDC.
This allows the KDC to encrypt tickets in a form that can only be
understood by relevant applications.
• User and applications keys (shared secrets) are usually stored in
a key table (keytab) for subsequent use. These keytabs need to
be available to software that needs them to decrypt Kerberos
data. A user's keytab should be established when the user logs
into to a computer. Application keytabs are longer-lived and are
only created when passwords are changed on service accounts.
• When a user needs to access a Kerberized application, he/she
(indirectly, via a client application) asks the KDC for a service
ticket for that application. A portion of this ticket is encrypted with
the user's shared secret and another portion is encrypted with the
application's shared secret. This allows both the user's client
computer and the application's client computer to verify that the
incoming ticket is valid.
• Kerberized applications frequently support other forms of
authentication and make it necessary for application clients to
negotiate what type of authentication they're going to perform.
Operating systems typically provide software to facilitate this
negotiation. Windows systems provide SSPI whereas Linux/UNIX
provide GSSAPI. These two systems are, mostly, interoperable.
Although Kerberos facilitates the implementation of SSO, it can be
extremely difficult and frustrating to get it to work properly. Many
individual steps are involved and mistakes anywhere along the way
typical only manifest themselves by a failure of authentication (SSO
doesn't SO!). It can be difficult to diagnose where errors might have crept
into the process.
