DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Ultimate Guide to FaceIO
  • Identifying, Exploiting, and Preventing Host Header Attacks on Web Servers
  • Authentication With Remote LDAP Server in Spring Web MVC
  • 7 Microservices Best Practices for Developers

Trending

  • Comparing SaaS vs. PaaS for Kafka and Flink Data Streaming
  • Mastering Advanced Traffic Management in Multi-Cloud Kubernetes: Scaling With Multiple Istio Ingress Gateways
  • How to Format Articles for DZone
  • Develop a Reverse Proxy With Caching in Go
  1. DZone
  2. Software Design and Architecture
  3. Performance
  4. Introduction to Kerberos for Managers

Introduction to Kerberos for Managers

Kerberos is a ticket-based security protocol involving three parties. Learn more about how it works in this introduction.

By 
Brett Crawley user avatar
Brett Crawley
·
Apr. 18, 16 · Tutorial
Likes (5)
Comment
Save
Tweet
Share
10.5K Views

Join the DZone community and get the full member experience.

Join For Free

Image title

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

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

Authentication

Steps 1 through 7 make up the process of authentication.

Authorization Flow


Authorization

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

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

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

User Impersonation Sequence Diagram


Kerberos (protocol) Application server application Web Service authentication Principal (computer security) Web application

Opinions expressed by DZone contributors are their own.

Related

  • Ultimate Guide to FaceIO
  • Identifying, Exploiting, and Preventing Host Header Attacks on Web Servers
  • Authentication With Remote LDAP Server in Spring Web MVC
  • 7 Microservices Best Practices for Developers

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!