Single Sign-On
Wikipedia describes Single Sign-On (SSO) as a property of access control of multiple related, but independent software systems. With this property a user logs in with a single ID and password to gain access to a connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system. It reduces the time spent re-entering passwords for the same identity.
Thus, Single sign on (SSO) is a way to improve and simplify users life by allowing, apart from other things, to do automatic logins to other products after a first manual login. Please have a look for a deeper discussion on advantages and disadvantages of SSO.
In the following, I would like to present in the following the possible options for SSO with Java in a servlet container against a Microsoft Active Directory infrastructure. This is a quite common combination that will be often found in real-world environments. However, the setup of SSO mechanisms may be a little bit fiddly and error-prone.
Basics About SSO in Context of Java, Windows and Active Directory
The cryptographic protocols that are used for Windows and Active Directory SSO are commonly referred to as Integrated Windows Authentication. Windows Authentication is an implementation of SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism). SPNEGO tries to negotiate the best SSO protocol that is possible between client, server and active directory. Two possible protocols are available for the negotiation, namely Kerberos and NTLMv2. Kerberos is the more secure protocol for SSO. Anyhow, NTLMv2 is strong enough to be used inside a non-public corporate network (however, some side-conditions must be fulfilled). One way to use SPNEGO is SSPI which is a Win32 API and can be used with almost no configuration.
Note that I assume in the following that the users and the computers are part of a Microsoft Domain network.
The security protocols involved in SPNEGO, i.e., Kerberos or NTLMv2, work as roughly illustrated in the following figure:
Figure 1: Systems involved into SSO with Windows and Active Directory
There are three type of systems involved in SPNEGO SSO. A client with a web browser, which is usually running under Windows, and Active Directory which may consist of multiple domain controllers replicating the Active Direcotry database over several nodes (must not necessarily Microsoft Active Directory, as Samba 4+ also contains an implenentation of Active Directory). Furthermore, there is an application server running a servlet container implementation, such as Tomcat, which may run on Windows or another operating system.
SSO with SPNEGO, ie., NTLMv2 and Kerberos, work roughly as follows: the operating system of the client system containing the web browser initially authenticates at the Active Directory (1) by entering the credentials. After successful login the identity of the user on this system has been proven and is used for further automatic SSO logins, for example when an application demands its user to authenticate. The proving of identity is accomplished by exchanging messages that involve a secret (a token, a ticket, or hash of the password) that is known between Active Directory and Web Client (3 and 4). The application server itself involves active directory (2) to get a prove of identity.
Note that on the web client system, the browser takes care of the necessary steps for SSO authentication, whereas on the server, the Java web application must take care in order to do a correct SSO login. So, in the following I’m discussing this part.
Possible Libraries to Use on the Application Server Side
The following libraries help a Java servlet to do SSO login at Microsoft Active Directory:
- Waffle: Waffle uses SSPI (thus implements SPNEGO) and provides a zero configuration API to implement SSO for a Java Web Application. Waffle can only be used on Windows (Server) operating systems as it uses SSPI in the Win 32 API. Apart from SPNEGO, Waffle provides a simplified interface for accessing the Kerberos protocol in the backend.
- SPNEGO Sourceforge is a SPNEGO implementation in Java that needs a configuration of Active Directory for Kerberos. SPNEGO provides servlet filters for the authentication. It’s rather difficult to get it working with Kerberos.
- Built-in negotiation Mechanism of Java GSSAPI needs the configuration of Kerberos and has a lot of pitfalls. It’s rather difficult to get it working with Kerberos.
- JCIFS provides a way to authenticate via NTLMv1 that is in fact insecure and should not be used any more for SSO.
- IOPlex Jespa is a commercial product which allows authenticating with NTLMv2. I have not used this so far, thus, I cannot comment this solution in detail.
- Liferay 6+ contains an implementation for NTLMv2 SSO. This implementation is the basis for ntlmv2auth providing a Liferay-independent servlet filter for the NTLMv2 SSO. Note that Liferay 6 and ntlmv2auth uses the JCIFS library as a basis for their implementation.
So what fits best to your needs? This strongly depends on the target operating system of the application server where your Java servlet container runs.
If you are using Windows as server operating system, I highly recommend Waffle, as it is easy to use and there is no big deal with configuring it.
If you are running your servlet container on another operating system than Windows, e.g., Linux, the easiest solution to use is probably ntlmv2auth. In this case it’s only running NTLMv2. Nonetheless, it should be fine from security point of view if used inside a corporate network if some side-restrictions are kept into account.
If you have strong security guide lines in your company, there is no way, you should use Kerberos and threfore either the Java implementation of GSS-API or Waffle.
In the projects I have been involved, we have been also trying Sourceforge SPNEGO and GSSAPI of Java. However, the configuration of the corresponding Kerberos parts for Active Directory is error-prone and rather painful. Moreover, the Microsoft UAC does not allow to use Kerberos when the user has local administrator rights – the system simply nullifies the Kerberos ticket and SSO is not possible with Kerberos. Setting the mentioned registry entry allowtgtsessionkey for Windows 7 did not work when we tried to implement our solution, as the users had administrator rights.
Thus, in the following blog entries, I will show in more detail how to configure, the following solutions for SSO:
- Using NTLMv2auth filter in a servlet container
- Using Waffle on Windows Server providing SSO for servlet containers
- Kerberos with Active Directory and Java