Chapter 1. SSO with Kerberos Deeper Dive
1.1. What are SSO and Kerberos?
A basic background of SSO and Kerberos are provided in the Single Sign On section of the Red Hat JBoss Enterprise Application Platform Security Architecture document.
1.2. Kerberos Components
Kerberos itself is a network protocol that enables authentication for users of client/server applications through the use of secret-key cryptography. Kerberos is usually used for authenticating desktop users on networks, but through the use of some additional tools, it can be used to authenticate users to web applications and to provide SSO for a set of web applications. This essentially allows users who have already authenticated on their desktop network to seamlessly access secured resources in web applications without having to re-authenticate. This concept is known as Desktop-Based SSO since the user is being authenticated via a desktop-based authentication mechanism, and their authentication token or ticket is being used by the web application as well. This differs from other SSO mechanisms such as Browser-Based SSO, which authenticates users and issues tokens all via the browser.
The Kerberos protocol defines several components that it uses in authentication and authorization:
Ticket is a form of a security token that Kerberos uses for issuing and making authentication and authorization decisions about principals.
Authentication Service, or
AS, challenges principals to log in when they first log into the network. The authentication service is responsible for issuing a
Ticket Granting Ticket or
TGT, which is needed for authenticating against the
Ticket Granting Service and subsequent access to secured services and resources.
Ticket Granting Service
Ticket Granting Service, or
TGS, is responsible for issuing
Service Tickets and specific session information to principals and the target server they are attempting to access. This is based on the TGT and destination information provided by the principal. This service ticket and session information is then used to establish a connection to the destination and access the desired secured service or resource.
Key Distribution Center
Key Distribution Center, or
KDC, is the component that houses both the TGS and AS. The KDC, along with the client, or principal, and server, or secured service, are the three pieces required to perform Kerberos authentication.
Ticket Granting Ticket
Ticket Granting Ticket, or
TGT, is a type of ticket issued to a principal by the AS. The TGT is granted once a principal successfully authenticates against the AS using their username and password. The TGT is cached locally by the client, but is encrypted such that only the KDC can read it and is unreadable by the client. This allows the AS to securely store authorization data and other information in the TGT for use by the TGS and enabling the TGS to make authorization decisions using this data.
Service Ticket, or
ST, is a type of ticket issued to a principal by the TGS based on their TGT and the intended destination. The principal provides the TGS with their TGT and the intended destination, and the TGS verifies the principal has access to the destination based on the authorization data in the TGT. If successful, the TGS issues an ST to the client for both the client as well as the destination server which is the server containing secured service/resource. This grants the client access to the destination server. The ST, which is cached by the client and readable by both the client and server, also contains session information that allows the client and server to communicate securely.
There is a tight relationship between Kerberos and the DNS settings of the network. For instance, certain assumptions are made when clients access the KDC based on the name of the host it is running on. As a result, it is important that all DNS settings in addition to the Kerberos settings are properly configured to ensure that clients can connect.
1.3. Additional Components
In addition to the Kerberos components, several other items are needed to enable Kerberos SSO with JBoss EAP.
Simple and Protected GSSAPI Negotiation Mechanism or
SPNEGO provides a mechanism for extending a Kerberos-based Single Sign On environment for use in Web applications.
SPNEGO is an authentication method used by a client application to authenticate itself to the server. This technology is used when the client application and server are trying to communicate with each other, but neither are sure of the authentication protocol the other supports. SPNEGO determines the common GSSAPI mechanisms between the client application and the server and then dispatches all further security operations to it.
When an application on a client computer, such as a web browser, attempts to access a protected page on the web server, the server responds that authorization is required. The application then requests a service ticket from the Kerberos 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 running the deployed web application unpacks the request and attempts to authenticate the ticket. Upon successful authentication, access is granted.
SPNEGO works with all types of Kerberos providers, including the Kerberos service included in Red Hat Enterprise Linux and the Kerberos server, which is an integral part of Microsoft Active Directory.
1.3.2. JBoss Negotiation
JBoss Negotiation is a framework that ships with JBoss EAP that provides an authenticator and JAAS login module to support SPNEGO in JBoss EAP. For more information on JAAS login modules, please see the Declarative Security and JAAS and Security Domains sections of the Red Hat JBoss Enterprise Application Platform Security Architecture Guide.
When using JBoss Negotiation to secure certain applications, such as REST web services, one or more sessions may be created and left open for the timeout period, default is 30 minutes, when a client makes a request. This differs from the expected behavior of securing an application via basic authentication, which would leave no open sessions. JBoss Negotiation is implemented to use sessions to maintain the state of the negotiation/connection so the creation of these sessions is expected behavior.
1.4. Kerberos Integration
Kerberos is integrated with many operating systems including linux distributions such as Red Hat Enterprise Linux. Kerberos is also an integral part of Microsoft Active Directory and is supported by Red Hat Directory Server and Red Hat IDM.
1.5. How does Kerberos provide SSO for JBoss EAP?
Kerberos provides Desktop-based SSO by issuing tickets from a KDC for use by the client and server. JBoss EAP can integrate with this existing process by using those same tickets in its own authentication and authorization process. Before trying to understand how JBoss EAP can reuse those tickets, it is best to first understand in greater detail how these tickets are issued as well as how authentication and authorization works with Kerberos in Desktop-Based SSO without JBoss EAP.
1.5.2. Kerberos and JBoss EAP
JBoss EAP can integrate with an existing Kerberos Desktop-Based SSO environment to allow for those same tickets to provide access to web applications hosted on JBoss EAP instances. In a typical setup, an JBoss EAP instance would be configured to have Kerberos and SPNEGO security domains. An application, configured to use those security domains along with JBoss Negotiation, is deployed to that JBoss EAP instance. A user logs in to a desktop, which is governed by the Kerberos, and completes an authentication exchange with the KDC. The user then attempts to access a secured resource in the deployed application on that JBoss EAP instance directly via a web browser. JBoss EAP responds that authorization is required to access the secured resource. The web browser obtains the user’s TGT ticket and then performs the ticket granting, or authorization, exchange with the KDC to validate the user and obtain a service ticket. Once the ST is returned to the browser, it wraps the ST in a request formatted for SPNEGO, and sends it back to the Web application running on JBoss EAP. JBoss EAP then unpacks the SPNEGO request and performs the authentication using the configured security domains and JBoss Negotiation. If the authentication succeeds, the user is granted access to the secured resource.