Chat now with support
Chat with Support

Single Sign-On for Java 3.3.2 - Administration Guide

About this guide Introducing Single Sign-on for Java Preparing for Single Sign-on for Java Deploying Single Sign-on for Java
Getting started with Single Sign-on for Java Single Sign-on for Java and your web applications Setting up logging Controlling access to resources
Security Issues Maintenance and Troubleshooting Appendix: Configuration Parameters Appendix: Using the JKTools

About Kerberos

Kerberos is the underlying network authentication protocol that Single Sign-on for Java and Active Directory use to provide secure communications.

Kerberos is designed to provide authentication for client-server applications across insecure network connections, using strong secret-key cryptography. It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. Kerberos also provides checks for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptographic ciphers such as DES, RC4 and AES.

Kerberos works by providing “principals” (users or services) with tickets that they can use to identify themselves, and secret cryptographic keys for secure communication with other principals. A ticket is a sequence of a few hundred bytes. Each ticket can then be used to secure virtually any other network protocol, thereby allowing the processes implementing that protocol to be sure about the identity of the principals involved.

Kerberos provides for mutual authentication and secure communication between principals on an open network by manufacturing secret keys for any requester, then providing a mechanism for these secret keys to be safely propagated through the network.

Kerberos does not, strictly speaking, provide for authorization or accounting, although applications may use their secret keys to perform those functions securely. The Kerberos emphasis is on authentication and opening of communication channels. Once a principal is authenticated, its details can be checked to see if it is authorized to access the resource requested.

The following diagram shows how the Kerberos protocol works.

A principal authenticates itself in Kerberos by using a principal name of the form principal-name@realm and a password. This is typically used to send an encrypted message to the Authentication Service (AS).

The Authentication Service can then authenticate the principal (in Windows, it can check its details in Active Directory) and send back a session key and Ticket Granting Ticket (TGT).

Figure 1: Kerberos Protocol

The TGT is like a certificate of identity which allows the principal to gain later access to one or more services. Once the user has supplied a password and obtained the TGT from the AS, authentication to any other service can proceed automatically without the user having to resupply the password. For this reason, Kerberos is sometimes called a Single Sign-on (SSO) service.

A ticket is a credential that enables a principal to gain access to a service. A principal obtains tickets from the Ticket Granting Service (TGS) using the TGT obtained from the AS as described above. The ticket is used to create an authenticator, which is then sent to the service being requested to authenticate the user.

The authenticator is used to establish a session key for secure communication. Optionally, the user can also request to authenticate the server. If this happens, the server uses information in the user's authenticator to send back a server authenticator, which the user can use to verify the server's authenticity.

The Kerberos protocol has been widely analyzed and is supported by many vendors including Microsoft and Oracle.

About Active Directory

The Active Directory service is a core component of the Microsoft Windows operating system. It provides a directory service supporting the Lightweight Directory Access Protocol (LDAP), and has an integrated Kerberos key distribution center to authenticate users.

It allows organizations to share and manage information about network resources and users and provides an SSO environment that integrates with the standard Windows desktop login. In addition, it acts as a single point of management for Windows-based user accounts, clients, servers and applications.

The directory is arranged hierarchically, allowing the division of enterprise resources into different domains. Each resource (that is, user, application), is represented as an object with a number of attributes (for example, the organizational group to which the resource belongs).

The directory may be browsed hierarchically for resources, or each resource can be individually addressed by providing its Distinguished Name. The Distinguished Name is simply a group of attributes that uniquely identify an object within the Active Directory hierarchy (for example, “Conjoin Doe, DC=example, DC=com”).

The directory also provides fine-grained security mechanisms to allow administrators to determine exactly what information may be accessed. Users can be restricted to specific objects, or even specific attributes within the directory.

The main benefits of using Active Directory are that it simplifies the management of user accounts, and provides an SSO infrastructure to users. Its support for standard protocols such as LDAP and Kerberos means that it can be used as, or with, a cross-platform solution.

The Kerberos support in Active Directory has been tested to ensure interoperability with the MIT Kerberos implementation used by many UNIX vendors. However, it is worth noting some differences between the Microsoft and MIT implementations:

  • Support for Privilege Attribute Certificates (PACs)

    Microsoft's Kerberos implementation uses the AuthorizationData field of the Kerberos ticket to pass Privilege Attribute Certificates (PACs) to Kerberized applications. Applications that support Microsoft's PAC format can use this information to provide fine-grained access control to services.

  • Integration with LDAP

    Active Directory's Kerberos features are tightly integrated with its LDAP server. This means that user information, such as groups, can be retrieved using standard tools and APIs.

  • Windows Native Credential Cache

    Unlike the MIT implementation, the Windows Kerberos implementation uses an in-memory credential cache to store Kerberos tickets and TGTs (the MIT implementation uses a disk file). The implementation is stored in non-paged memory so it is never written to disk. Microsoft provides routines to obtain credentials from this cache through their Local Security Authority API (LSA API).

  • Smartcard / PKI Support

    Microsoft supports a version of the PKINIT protocol which allows the initial authentication to the directory to be performed using a private key or smartcard.

Active Directory groups

In large organizations, managing the authorization permissions of hundreds or even thousands of users creates a significant problem. One way that Active Directory addresses this issue is through the use of groups. These groups provide a way to classify users according to their roles or activities, and can be used as the basis for authorization permissions.

Group types

Active Directory defines two types of groups: security groups and distribution groups. Distribution groups are mainly used for activities such as sending bulk email, and do not allow permissions and audit settings to be associated with them. Security groups on the other hand are primarily designed for authorization, so are most interesting for Single Sign-on for Java. Microsoft Windows does not use distribution groups internally, although they are available for use by other directory-enabled applications.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating