Java Web Apps and Single Sign-On

 

Single Sign-On:

Essentially, single sign-on (SSO) is the process where the user is required to authenticate himself only once in order to gain access to multiple related but ultimately independent software systems. The most common case is when the user belongs to a domain (internal network) and is able to login using his account credentials where he subsequently gains access to network drives etc. without the need to re-authenticate himself.
I will be looking at possible ways to achieve SSO with a Java web app where users belong to a Windows domain and where the users (and their credentials) gets stored in a Windows Active Directory (against which authentication gets performed).

SSO Advantages:

• Improved user productivity. Users are no longer bogged down by multiple logins and they are not required to remember multiple IDs and passwords. This also improves security as users find it easier to remember their credentials and do not have to write them down etc., allowing for a more efficient user login process
• It improves an administrator’s ability to manage users and user configurations to all associated systems
• It reduces administrative overhead in resetting forgotten passwords over multiple platforms and applications
• It improves the effectiveness/timeliness of disabling all network/computer accounts for terminated users

SSO Disadvantages:

• Unattended desktop. Implementing SSO reduces some security risks, but increases others. For example, a malicious user could gain access to a user’s resources if the user walks away from his machine and leaves it logged in. Although this is a problem with security in general, it is worse with SSO because all authorized resources are compromised. At least with multiple logins, the user may only be logged into one system at the time and so only one resource is compromised
• It requires continuous availability of a central server. When the AD server is down, no one can log in
• Since all authentication is controlled by a centralized AD server, compromise of this authentication infrastructure will allow an attacker to impersonate any user across all SSO supported systems
• Hence the SSO server and other host security must be hardened

In order to gain access to network resources, authentication needs to happen in the background where authentication information ultimately has to be sent over to the Active Directory (AD) server. Thus  authentication protocols had to be developed to do this securely.

Authentication Protocols:

Kerberos Protocol:
Kerberos is a standardized network authentication protocol (developed by MIT), which is designed to provide strong authentication (by using secret-key cryptography) for client/server applications, such as web applications where the browser is the client. Essentially Kerberos is an authentication protocol for trusted hosts on untrusted networks.
Kerberos is an integral part of Windows Active Directory implementations and is the preferred authentication protocol when operating in a domain environment. Essentially every Windows Active Directory domain controller is also a Kerberos Key Distribution Center or “KDC”.
The protocol is currently sitting on version 5.
NT LAN Manage (NTLM) Protocol:
NTLM is a challenge-response based protocol. In a challenge-response protocol, the client generates a response using the server challenge and a secret value that the client and server both know (like a password) and sends it back for validation. Security features were added to the protocol in version 2 to provide for stronger protection of encryption keys and challenges.
Simple and Protected GSS-API Negotiation (SPNEGO) Protocol:
The Generic Security Service Application Program Interface (GSS-API) was developed on top of the Kerberos and the NTLM authentication protocols, where its development goal was to provide security developers with a consistent high-level programming interface for authentication and security without needing to know the details of a particular security protocol.
The wiring of GSS-API authentication to a web browser occurs through the use of a message exchange standard known as Simple and Protected GSS-API Negotiation Mechanism (SPNEGO). SPNEGO is an algorithm specifying the behaviour of two GSS-API implementations in determining whether they can communicate with each other over a common security protocol.
Quick Protocol Conclusion:
As it’s a very technical manner to weigh up the advantages and disadvantages of the Kerberos and NTLM authentication protocols against each other and because Kerberos is the industry standard, there is no need to further explain that Kerberos is indeed the preferred protocol to use. At the end of the day they will both achieve SSO but Kerberos will do so in a more secure manner. One thing to note though is that neither Kerberos or NTLM protocols send the user’s password over the wire, which is obviously a good thing as the no amount of network packet sniffing would result in the malicious user being able to impersonate an authenticated user.

Other Means to Authenticate Against Active Directory:

Lightweight Directory Access Protocol (LDAP):
LDAP is an application protocol for querying and modifying items in directory service providers such as Active Directory. Thus it can’t be considered as a solution to achieve SSO as the client/browser plays a large role in SSO and LDAP is simply a way for the application to talk to the AD server. That being said LDAP can be configured to securely communicate to the AD server so theoretically it can play a part in the SPNEGO Kerberos authentication process.

Implementing SSO in a Java Web App:

As all major browsers support the SPNEGO a.k.a. Negotiate protocol to achieve SSO and because the protocol is integrated by Windows Active Directory as part of their product – it became clear that this is the way to achieve SSO in a web app.

SPNEGO/Kerberos Libraries:

Windows Authentication Functional Framework Light Edition (WAFFLE):
Provides various ways to achieve SSO (via the Negotiate protocol) in a web application but is restricted to web applications sitting on web servers running on a Windows machine. Thus a no go as our web server runs on a Linux machine.
spnego.sourceforge.net:
The library is aimed at Java based web servers looking to handle SPNEGO/“Negotiate” (with preference to Kerberos over NTLM) as the authentication protocol, where SSO is ultimately achieved by configuring a Java Servlet Filter with all the necessary information to perform the authentication against the Active Directory (Key Distribution Centre).
Advantages:
Once the Kerberos environment has been correctly setup on the AD server with regards to the web server in question – SSO is relatively straightforward to achieve. It is also pretty lightweight as we’re essentially dealing with one filter. The project has got an active community/forum where the developer of the project is very actively taking part in discussions and troubleshooting.
Disadvantages:
It is not very configurable. For example in the Spring Security framework you can declare various “intercept-urls” which specifies what level of authentication the user needs to access the URL in question. It gives precedence to the top-most declaration thus if you specify that the “/login.jsp” URL requires no authentication to access and then specify that “/*” (all permutations of URLs) needs full authentication to access, it effectively excludes “/login.jsp” URL from the list of URLs that need full authentication. This behaviour is crucial as we obviously can’t expect a user to be authenticated before he had a chance to authenticate himself. Effort would be required to place this library (which is designed to sit on the web server) in the application as the web app also needs to confirm that the user exists in the web app (it’s not enough to know that the user merely exists on the domain). The web app also needs to know when negotiation/authentication fails as to provide a fallback method to authenticate the user, which this library doesn’t quite support (it provides basic authentication as a fallback but this protocol is unsecure).
Spring Security Kerberos/SPNEGO Extension:
The Spring team brought out an extension to their latest version of the Spring Security framework (version 3) that provides the security developer with a solution to achieve SSO via the SPNEGO/Kerberos protocol. The solution has been implemented in alignment with their existing security framework, thus a developer that is familiar with Spring Security would have no trouble in understanding the flow of the solution and would effectively be able to use it out of the box. To use this solution the web app would need to upgrade it’s core Spring framework to version 3 and it’s Spring Security framework to version 3. Version 3 of the Spring Security framework has significantly changed its package structure from version 2 which has enabled them to make the functionality that the framework provides much more modular.
Advantages:
The solution sits in the application and thus can easily confirm if the user exists in the web app upon successful authentication. As with the spnego.sourcefourge.net solution – SSO is relatively straightforward to achieve once the Kerberos environment has been correctly setup on the AD server with regards to the web server in question. As it is in alignment with the existing security framework – the solution is highly configurable. The extension to the Spring Security framework also provides a way to combine form-based authentication with the Kerberos protocol to securely authenticate the user against the Active Directory. Furthermore as the framework is so highly configurable, it is possible to use this as the fallback. Thus upon SSO authentication failure (ex if the user tries to access the web app from outside of the domain), the user can effectively be redirected to the login screen to enter his domain account credentials. Which is first prize.
Lastly the Spring Security framework has been widely adopted and has a very active community.
Disadvantages:
This extension library needs the latest Spring libraries, thus if an upgrade is necessary, then the package structure changes (and inevitable deprecations) would need to be catered for in existing security classes. Furthermore, a fair amount of systems testing would be required which is obviously not ideal.

Integrating a “Kerbeized” Web Application With an Openfire Chat Server:

Built in (Home Made) Java Chat Client:
Integration can be achieved once the user has been authenticated in the web app. All that would be required is an authenticated request from the web app to the Openfire server to login the user in question.  The whole concept of SSO is around the web app not storing the domain user’s password as the Kerberos/SPNEGO protocol doesn’t send the password across the wire when authenticating against the AD server.
My proposed solution to send the authenticated login request is as follows:

• The web app and the Openfire server shares a private key and salt
• The Openfire server stores a timestamp (upon server startup the timestamp gets created)
• The web app upon making the login request (which requires a username and password), creates a timestamp (which would effectively be later on than the one stored by the Openfire server)
• The web app then encrypts the timestamp with the private key and subsequently encrypts it again with the salt (thus double encrypted) and uses this result as the password (RSA encryption is probably a good bet)
• The Openfire server then receives the request with the username and the double encrypted timestamp which it then decrypts as it knows the key and salt used to encrypt it
• The Openfire server then compares the decrypted timestamp with its stored timestamp
• Only if the decrypted timestamp is later on than the stored timestamp does the user get logged in
• If successful, the stored timestamp subsequently gets set to the decrypted timestamp

This solution would effectively be secure against replay attacks (where a malicious user sniffs the request and uses it again to try and login) and relatively secure against brute force attacks (due to the double encryption). Note that the timestamp is accurate to the closest millisecond where it would be sent as a long. This solution assumes that the machines which host the web app and Openfire, to be closely synchronised in time.
External Chat Clients:
At this stage there isn’t a clear solution to achieve SSO with external chat clients as the SPNEGO/Kerberos authentication protocol essentially requires the client (in this case the external chat client) to speak this language/implement the protocol. It is also not recommended to let the external chat client send the user’s domain password over the wire as we don’t have any control over how the credentials gets sent, making it a high security risk. A potential work around could be to have the user specify a chat password in the web app (which would effectively be stored in the database) which the user could use to authenticate himself. At least if these credentials are obtained by a malicious user, it can’t be used to login to the web app or any system other than Openfire.

Conclusion:

In my opinion the Spring Security solution is the clear winner for achieving SSO in a Java web app. Its drawbacks are in actual fact a bit irrelevant as you would need to upgrade the Spring framework at some stage. At the time of writing I am unable to setup a Kerberos environment in the domain to test this SSO solution, thus at this stage the POC is riding on some assumptions:

• That the main SSO solution does in fact work as expected (i.e. the user gets authenticated securely without the need to enter credentials). This assumption is quite solid as Spring has been widely adopted and the active Spring forum suggest that this functionality works as expected
• That the fallback configuration works (upon authentication failure). This assumption is not really solid at this stage as it wasn’t provided by a recognised Spring developer, thus I will only be happy once I have confirmed it. This fallback solution was posted on the Spring forums: http://forum.springsource.org/showthread.php?p=326151#post326151

More Here

Courtesy:http://bsgdev.wordpress.com/2011/01/04/java-web-apps-and-single-sign-on/