Cybersecurity, Software Engineering
Single Sign On with Kerberos
Browser based authentication with Spnego and Keberos
You can check my video course on Udemy: How to Identify, Diagnose, and Fix Memory Leaks in Web Apps.
In Greek mythology, Kerberos (or Cerberus, the dog of Hades), is a three-headed dog that guards the gates of the Underworld to prevent the dead from leaving. In our story today we are not going to speak about Kerberos the hound of Hades but about Kerberos the protocol used in the single sign on (SSO) authentication.
What is Single Sign On?
Currently, many web applications require users to register for a new account. With the proliferation of web applications, it has become impractical to expect users to remember different usernames and passwords for each application. Single Sign-On (SSO) protocols (Kerberos, SAML, OpenID, …) allow users to use a single ID and password to access different applications. A user logs in to gain access to a connected system or accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers.
Since SSO shares centralized authentication servers, users do not have to actively enter their credentials more than once. An authentication server provides a network service that applications use to authenticate the credentials (usually account names and passwords) of their users. When a client submits valid credentials, it receives a cryptographic ticket that it can subsequently use to access various services.
If the user logs out of a resource, or a resource invalidates the session programmatically, all persisted authorization data are removed, and the process starts over. In the case of a resource session timeout, the SSO session is not invalidated if there are other valid resource sessions associated with that user.
Kerberos
Kerberos is a network authentication protocol that works on the basis of tickets (security tokens) to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.
To use a secured service, users need to obtain a ticket from the Ticket Granting Service (TGS), which is a service running on a server on their network. After obtaining the ticket, users request a Service Ticket (ST) from an Authentication Service (AS), which is another service running on the same network. Users then use the ST to authenticate to the desired service. The TGS and the AS both run inside an enclosing service called the Key Distribution Center (KDC).

The steps in the process are:
- The client sends the principal name and a request for a TGT to the KDC.
- The KDC generates a session key and a TGT that contains a copy of the session key and uses the Ticket Granting Service (TGS) key to encrypt the TGT. It then uses the principal’s key to encrypt both the already encrypted TGT and another copy of the session key.
- The KDC sends the encrypted combination of the session key and the encrypted TGT (Ticket Granting Ticket) to the client.
- The client uses the principal’s key to extract the session key and the encrypted TGT. When the client wants to use a service, usually to obtain access to a local or remote host system, it uses the session key to encrypt a copy of the encrypted TGT, the client’s IP address, a time stamp, and a service ticket request, and it sends this item to the KDC.
- The KDC uses its copies of the session key and the TGS key to extract the TGT, IP address, and time stamp, which allow it to validate the client. Provided that both the client and its service request are valid, the KDC generates a service session key and a Service Ticket that contains the client’s IP address, a time stamp, and a copy of the service session key, and it uses the service key to encrypt the Service Ticket. It then uses the session key to encrypt both the Service Ticket and another copy of the service session key. The service key is usually the host principal’s key for the system on which the service provider runs.
- The KDC sends the encrypted combination of the service session key and the encrypted Service Ticket to the client.
- The client uses its copy of the session key to extract the encrypted Service Ticket and the service session key. The client sends the encrypted Service Ticket to the service provider together with the principal name and a timestamp encrypted with the service session key.
- The service provider uses the service key to extract the data in the Service Ticket, including the service session key. The service provider enables the service for the client, which is usually to grant access to its host system.
If the client and service provider are hosted on different systems, they can each use their own copy of the service session key to secure network communication for the service session.
Note the following points about the authentication handshake:
- Keys are never sent in the clear over any communications channel between the client, the KDC, and the service provider.
- At the start of the authentication process, the client and the KDC share the principal’s key, and the KDC and the service provider share the service key. Neither the principal nor the service provider knows the TGS key.
- At the end of the process, both the client and the service provider share a service session key that they can use to secure the service session. The client does not know the service key and the service provider does not know the principal’s key.
- The client can use the TGT to request access to other service providers for the lifetime of the ticket, which is usually one day. The session manager renews the TGT if it expires while the session is active.
Spnego
Since Kerberos is not the only authentication protocol, we need to step back and introduce another player in our authentication process: Spnego. SPNEGO stands for Simple and Protected GSS_API Negotiation Mechanism for extending a Kerberos-based SSO environment for use in web applications since it is designed to be used in a client-server desktop environment, and is not usually used in web applications or thin client environments.
Spnego is a mechanism to negotiate with the authenticator what security protocol to use. For example Kerberos, NTLM, Digest, or Basic.5t6.

- An application on a client computer, such as a web browser, attempts to access a protected page on a web server.
- The server responds that authorization is required.
- The application then requests a service ticket from the Kerberos Key Distribution Center (KDC).
- After the ticket is obtained, the application wraps it in a request formatted for SPNEGO, and sends it back to the web application, via the browser.
- The web container (Tomcat, JBoss EAP, …) running the deployed web application unpacks the request and authenticates the ticket. Upon successful authentication, access is granted.
So, as you can see we have just introduced our next player in the game: it’s the web container, tomcat in our case. So it’s time to have a look at the scenario with more details :)
Tomcat
Tomcat provides a low-level HTTP request interception mode much more general than servlet filters: valves. However, simply using a valve does not allows you to check for roles. This is why we provide a custom realm.
SSO in Tomcat is handled like a 2 steps process:
- First, authentication is handled by a valve component which allows working on a HTTP request before it reaches the servlet container. The valve takes care of the authentication.
- then the authorization is handled by the Real which works with Active Directory to obtain group information (usernames, groups, roles) associated with the user authenticated by the valve. The realm takes care of the authorization.
The sequence diagram below shows the interactions that take place in more detail:

- The user logs into Windows, he is authenticated with the Key Distribution Centre (KDC). In the case of Windows, the KDC would be the Primary Domain Controller.
- The OS receives a TGT token for the user.
- When the user tries to connect to the Tomcat server, the authentication mechanism is negotiated
- The user’s token is passed to Tomcat who then verifies it with the KDC.
- Once the user has been authenticated, Tomcat then retrieves his roles from the LDAP server (Active Directory in the case of Windows, it is a kind of database that specializes in identity information like usernames and passwords)
- and decides if he has access (200 OK) to the resource he has requested on the server.
References
[1] OVERVIEW OF GENERAL SECURITY CONCEPTS
[2] About Kerberos Authentication
[3] Generic Security Services API authentication support for the Session Initiation Protocol
[4] Configuring Kerberos/SPNEGO single sign-on authentication
Want more?
I write about engineering, technology, and leadership for a community of smart, curious people 🧠💡. Join my free email newsletter for exclusive access or sign up for Medium here.
You can check my video course on Udemy: How to Identify, Diagnose, and Fix Memory Leaks in Web Apps.