Single Sign-On for Java 3.3.2 - Administration Guide

Lifetime of authentication

Because SPNEGO requires two round trips to authenticate requests, it would be too expensive to perform an authentication for each request. Instead, applications supporting SPNEGO bind the authentication to a session or a connection. Note that authentication and re-authentication is performed transparently by Internet Explorer, and the user is not required to reenter a password.

When Windows Integrated Authentication is done to IIS using Internet Explorer, the authentication is done once per connection (HTTP 1.1 allows multiple requests to be performed over the same connection). As long as a connection is kept open, the user does not have to re-authenticate.

For Single Sign-on for Java, authentication is bound to a Java EE session. That is, once authenticated for a particular session, the user is not required to authenticate for the lifetime of that session, or until their service ticket expires. The session has a lifetime defined by the Java EE configuration. While this means that a user has to re-authenticate for each application (and each new session), the lifetime of these authentications may be potentially longer.

In practice, this makes little difference, as the connections should be protected by SSL, meaning that there is little opportunity for an attacker to obtain a session ID or hijack a TCP connection. However, the distinction needs to be considered when thinking about the appropriate lifetime of Java EE Session IDs.

Session IDs

Single Sign-on for Java binds the authentication of a user to a Java EE session ID. It does this by authenticating the user via SPNEGO (or the basic fallback mechanism) and then storing the user's Kerberos ticket and other associated information in the Java EE session information. For subsequent requests that use this session ID, Single Sign-on for Java checks that the information is still valid and lets the request through without requesting re-authentication.

This means that an attacker who is able to sniff the session ID, or obtain it by “guessing” can subvert the security of Single Sign-on for Java. For this reason, SSL should always be used to protect the session, and you should ensure that the session IDs used by your application server are random and large enough to ensure that they cannot be guessed by brute force.

In addition, you should ensure that the mechanism that your application server uses to ensure persistence of session information does not involve sending the session ID in the clear over the network. This could be the case, for example, if JDBC to a database on another machine or a network file system is being used for persistence.

Lastly, because of the sensitivity of session ID information, Single Sign-on for Java ensures that it does not log session IDs, but instead logs the MD5 hash of the ID. This allows events to be correlated across sessions, without the risk of the session ID being leaked (for example, if you are logging over a network, or to a network volume). See Auditing for more details on logging.

Active Directory permissions

Single Sign-on for Java requires read access to a number of attributes in Active Directory. This section details which attributes and permissions are required.

The following containers are examined:

• RootDSE
• Configuration
• Partitions
• User/Group

The RootDSE container is examined for the following attributes:

• rootDomainNamingContext
• defaultNamingContext
• configurationNamingContext
• supportedSaslMechanisms

The Configuration container is examined for the following attributes:

• objectClass=crossRefContainer

The Partitions container is examined for the following attributes:

• nETBIOSName=${DOMAIN}
• dnsRoot

The top-level domain container is examined for the following attributes:

• ntMixedDomain

User/Group Accounts are examined for the following attributes:

• userAccountControl
• groupType
• userPrincipalName
• servicePrincipalName
• distinguishedName
• objectClass
• cn
• sAMAccountName
• name
• lastLogon
• badPwdCount
• objectSid
• sIDHistory
• primaryGroupID

The property sets for the attributes listed above are as follows.

For the normative reference on Active Directory property sets, see:

http://msdn2.microsoft.com/en-us/library/ms683990.aspx

Basic fallback

The basic fallback mechanism is provided to allow support for non-Kerberized browser clients. It allows a simple username and password to be entered and a Kerberos login to be performed on the server. Some issues to do with caching of passwords on clients are described in Caching of passwords for basic fallback.

The basic challenge uses the Active Directory domain in the realm part of the request, meaning that for browsers that cache passwords, the user will not have to reenter the password for the lifetime of the cached password for any application that is using that Active Directory domain.

However, unless the browser is running a password manager, the cached password disappears when the user closes the browser. This means they have to reenter their password the next time they connect to an application.

Once Single Sign-on for Java has used the password to obtain the Kerberos ticket on the server, the password is disposed of. This limits the risk of a server compromise compromising a large number of passwords.

It should be noted that the basic fallback mechanism provides an opportunity for an attacker to try to guess passwords for Kerberos users. Single Sign-on for Java does not do any checking for a number of bad logins (although it is possible to obtain the number of bad logins since the last login if a request is successful programmatically).

For this reason you should consider configuring Active Directory to lock out users after a number of bad login attempts. See Denial of service for risks associated with this approach.