Introduction to Kerberos for Managers

What is Kerberos?

It is an authentication mechanism which involves three parties (it takes its name from the mythical creature that had three heads for this reason). Kerberos is a ticket-based security protocol.

Some Key Concepts

Authentication

This is the act of verifying you are who you say you are by checking your login credentials.

Authorization

This is the act of verifying that you have sufficient rights to access the system.

REALM

A REALM is in Kerberos terms equivalent to a DOMAIN in Windows terms. By convention the realm name is the DNS domain name in uppercase. For example: mydomain.com is the DNS domain and MYDOMAIN.COM is the realm name.

Key Distribution Centre (KDC)

The KDC, in the case of windows the domain controller, is responsible for verifying a user's credentials and issuing them with Kerberos tokens.

Lightweight Directory Access Protocol (LDAP)

The LDAP server is essentially a database that contains information about users and groups in a tree structure.

How does it work?

A user logs in to their computer and a token is issued by a Key Distribution Centre transparently. Their computer receives the token which it stores for later use when accessing other systems, in a local cache associated with that user. When they then access some other system their computer uses this ticket to authenticate them. This aforementioned system then verifies the token with the KDC.

In a scenario where everything worked to perfection and the user had the sufficient access rights the interactions are those shown in the diagram below.

Kerberos Interactions

1. The user first logs in to their computer
2. The KDC returns a token to the user's computer
3. The user requests a resource from the web application server
4. The Web application server asks the user to authenticate with the Kerberos protocol
5. The user then resends their request including the Kerberos token in the headers
6. The application server ask for verification of the token from the KDC
7. The KDC sends its verification response to the application server
8. If the user's identity has been verified the application server then asks the Lightweight Directory Access Protocol (LDAP) server, in the case of Windows usually Active Directory, what roles the user has
9. The LDAP server responds with a list of the roles for that user or the empty list.
10. The Application server then responds with the resource if the users identity was verified correctly and the user has the right roles to access the resource

Obviously if at step 7 the verification is not successful the application server at this point will return an HTTP status of 401 which is an “Unauthorized” error saying that the users authentication failed.

Likewise at step 9 if the user is not in a role that has access to the resource he will receive an HTTP status of 403 which is a “Forbidden” Error.

Authentication Flow

Authentication

Steps 1 through 7 make up the process of authentication.

Authorization Flow

Authorization

Steps 8 through 10 make up the process of authorization.

A more detailed sequence diagram of the interactions can be seen below:

Kerberos Sequence Diagram

Service Principals

The application server has a user associated with it so that it can authenticate itself with both the KDC and with the LDAP server when verifying the tokens and retrieving user information. This user is known as the Service Principal and it is as this user that the application server authenticates and communicates with the KDC. To authenticate as this user the application server uses a keytab file which is in the Kerberos Keytab binary file format as described here. This file is a table of key entries and can contain multiple entries although it usually only contains one.

A service principal looks like this:
HTTP/myhost.mydomain.com@MYDOMAIN.COM

The service principal represents a union of the protocol and the hostname, which may be in its short form or fully qualified (e.g. myhost or myhost.mydomain.com) and may or may not include an @ followed by the REALM name.

There may be multiple Service Principal Names (SPNs) associated with a service principal which behave as aliases for it. You may have an SPN for both the short and the long name of a host, others because the ip is resolved to a different hostname in the reverse DNS lookup, or if using a clustered solution, SPNs for each node and for the load balancer. These are used as a means to find the server’s record in LDAP as well. As seen below:

Cluster Service Principal

A rule of thumb here is that if a reverse DNS lookup can resolve to it, it should be an alias, i.e. an SPN.

User Impersonation / Delegation

If you intend for your web application to be able to call other services on behalf of an end user, this is called either user impersonation or delegation. You may hear both terms being used but the two terms can be used interchangeably.

To allow this the Service Principal must have delegation rights activated in ldap/active directory.

The user principal of the logged in user (i.e. their session) contains something called a GSSCredential which is a container, from the low-level libraries that enables Kerberos in Java, that contains the user's Kerberos token.

The application server can request a special type of token to wrap this users token when making requests on their behalf. This special token is called a Ticket Granting Service (TGS) ticket. Once we have this special token and we have encapsulated the users token within it, we can then make a service call as this user and the service will check with the KDC the validity in much the same way as the app server did when the user requested a resource from it the first time.

The sequence diagram for this can be seen here:

User Impersonation Sequence Diagram