Learn Kerberos v5 with Spring Security: IAM

Kerberos v5: SSO authentication in Windows 10 Home using Apache directory studio

Seamless SPNEGO HTTP Authentication

3 components in Kerberos
3 components in Kerberos
3 components in Kerberos network authentication protocol
Kerberos v5 Single Sign-On Security

Scope

This article explains how security can be implemented using Kerberos network protocol single sign on authentication in Windows 10 Home. It enables Kerberos in Apache directory studio which is a LDAP server and Key distribution center(KDC).
Kerberos v5 Single Sign-On(SSO) is explained using 2 Spring boot applications running in different ports.

Prerequisite

If you like to execute this in your local environment, the minimum software installation and application requirement is;
a. Windows 10 Home
b. Apache Directory studio v2.0.0
c. MIT Kerberos client - kfw-4.0.1
d. Develop two Spring boot applications in Java SE platform v1.8 to test Kerberos v5 SSO
e. Browser Configuration. Firefox/Edge/Chrome [will be shown below]
f. Spring Boot Application Code can be seen at GitHub . You require to use both projects given in the link to test Kerberos v5 SSO.

Security Configuration

Windows 10 Home

DNS Host name setting: C:\Windows\System32\drivers\etc\hosts
127.0.0.1 example.net

System Environment variable setting
KRB5CCNAME = C:\Users\{username}\AppData\Local\Temp\krb5cache

Apache Directory studio

a. Apache DS connection configuration

Overview tab
SASL settings
Kerberos server settings

b. Import the below LDIF files into Apache DS to create Hierarchy, Services and Users

hierarchy.ldif
services.ldif
users.ldif

MIT Kerberos client

Create krb5.ini file using notepad with the below contents and the file should be stored under C:\ProgramData\MIT\Kerberos5\krb5.ini

krb5.ini

The above screen shot shows krb5cache location stores tickets that are created using service principal name encrypted using service principal password. This way the password is not sent through the network which is crux of Kerberos.

When the user tries to access a /protected endpoint through browser and if krb5cache is empty, MIT Kerberos Ticket Manager will pop up and you provide Service principal credentials to create Ticket Granting Ticket(TGT). The Ticket Granting Server(TGS) of KDC creates TGT.
MIT Kerberos Ticket Manager will look the krb5.ini file for the Realm name and KDC location to get TGT.

Service Principal names used for web applications start with HTTP/HOSTNAME@REALM which is HTTP/example.net/EXAMPLE.COM in this example. You can find the service principal name entry in the services.ldif file we created above in Apache DS.

What is SPNEGO and GSS-API ? Why do we need ?

Kerberos is a secure Network Authentication Protocol operating primarily in the transport layer (TCP/UDP). This is where we require SPNEGO. SPNEGO(Simple and Protected GSS_API Negotiation Mechanism) extends Kerberos SSO for web applications.

Web application communication primarily happens between a web browser and a web server hosting the web application over HTTP. Enable the application to negotiate Kerberos as a security mechanism through SPNEGO and exchange tickets as SPNEGO tokens over HTTP.

GSS-API is Generic Security Service API

It provides a common interface for accessing different security services. SPNEGO is a part of the GSS-API for client and server to negotiate the choice of security mechanism to use, for instance, Kerberos or NTLM.

SPNEGO is a mechanism to negotiate with the authenticator to decide on what protocol to use namely GSS/SPNEGO -> Digest -> NTLM -> Basic. Notice that Kerberos does not appear in this list, since whenever Negotiate is supported, GSS/SPNEGO is always chosen. “SPNEGO” means you prefer to response the Negotiate scheme using the GSS/SPNEGO mechanism.

Once you have the TGT in krb5cache, the client encapsulates the Ticket in a request formatted for SPNEGO. The client sends the request containing the SPNEGO token in the HTTP Authorization header. SPNEGO authentication policy authenticates the request against the specified Kerberos Service Authentication provider.

The server side application needs a way to connect to KDC to verify the SPNEGO tokens sent by the browser to perform authentication. To do that, we create krb5.conf which has the same contents as krb5.ini and place it in the below location.
C:\Program Files\Java\jdk1.8.0_281\jre\lib\security\krb5.conf.

User Agent Configuration to send SPNEGO Tokens

Firefox settings

Firefox settings
Firefox settings

How Kerberos v5 SSO authentication works ?

Lets start 2 spring boot applications running REST services to see how tickets are getting generated and how Kerberos SSO authentication works.

Lets first create the key tab files for the service principal and place them in C:\keytabs
Java ktab utility can be used to create keytab files and they are stored in file named webapp.keytab for this example.

keytab files creation

The location of key-tab and service principal name must be given in the below configuration in Spring boot application to validate authentication.

keytab and service principal in spring boot

a. Running KerberosAuthApplication Spring boot Application in port 8080
Add VM argument -Djava.security.krb5.conf=”C:/Program Files/Java/jdk1.8.0_281/jre/lib/security/krb5.conf”

Run configuration using Java
Spring boot application started in port 8080

b. Running KerberosAuthApplication1 Spring boot Application in port 8081
Add VM argument -Djava.security.krb5.conf=”C:/Program Files/Java/jdk1.8.0_281/jre/lib/security/krb5.conf”

Run configuration using Java
Spring boot application started in port 8081

As the 2 Spring boot applications are running, we hit the /protected endpoint to see what happens.

user hits /protected endpoint

As you can see from the below screen shot, we get the MIT Kerberos Ticket Manager pop up. This is because, the krb5cache is EMPTY and we have to generate a TGT. To generate TGT, we have to provide the service principal name and password.

MIT Kerberos UI login

If the service principal name entered is wrong, then the server prompts with WWW-Authenticate: Negotiate in the response.

invalid service principal credentials
WWW-Authenticate: Negotiate in the response

Now we authenticate with correct service principal credentials to get TGT and seamless Kerberos authentication. On success it returns HTTP 200 status.

service principal credentials to get TGT

The below screen shot shows TGT has been generated for the service principal. There is one more way to generate TGT through command line. Navigate to
C:\Program Files\MIT\Kerberos\bin>kinit -k -t c:\keytabs\webapp.keytab HTTP/example.net@EXAMPLE.COM
This command will generate key-tab files exactly as how the above MIT Kerberos Ticket Manager generated.

TGT generated

You can see the last entry in the below screen shot shows, krb5cache created with TGT. This is the path given in krb5.ini, and krb5.conf.

krb5cache

Once TGT generated with correct service principal credentials, hit /protected endpoint and you will see KerberosAuthApplication running in port 8080 and response from server is received.

KerberosAuthApplication

Click on the SSO Login link, and you will be able to access KerberosAuthApplication1 running in port 8081 as shown below.

KerberosAuthApplication1

Conclusion

So we have finally accomplished Kerberos v5 SSO in Windows 10 Home by integrating with REST API using Apache Directory Studio. The GitHub link given above has source code which are tested and you can make use of it to further understand the nuance and crux of Kerberos.

published on 5th April 2021

Get the Medium app