Authentication to several related but independent software systems by logging in with a single user ID and password is called single sign-on. It is an access control property, whereby the user can seamlessly gain access to multiple connected systems without separately signing in with different user names and passwords.
Web application development is one of the most popular areas in IT software development. With clients becoming smarter, design architects and solutions providers are spending most of their time in the research and development of quicker, cheaper, more flexible and comprehensive solutions to suit any complex need of the user.
Of the many aspects of Web application development (or Web apps in a techie’s language), the most challenging and interesting sub-section is the authorisation and sign-on facility for a Web app.
The most accepted and common way of authorisation is the log in/password, which the user has to supply. This is counter-matched with the records in the store (a database, usually) and permission is granted based on criteria like roles and permissions.
As customer demands grow more complex, the situation becomes challenging when the development community is given more than one Web app interlinked for different purposes, and is asked to provide a sign-on for them.
This is when a single sign-on (SSO) makes sense. This article looks at its exact meaning, why it is required and how it got its current shape. We will also briefly discuss the various facilities/technologies available nowadays for the single sign-on.
SSO: In the early phase of adoption
To handle authentication for different Web apps using single sign-on information, certain features were proposed earlier. Two of these are listed below.
Bypass login: A bypass login is a crude workaround to handle logins for multiple related Web apps. It handles a login to the second application with a flag as a cookie set during the first Web app login. If this flag is set, then the second Web app will log in automatically. There is a huge problem in this method as the second Web app will not be role or policy based and hence will have the same amount of access/facilities for any login.
Moreover, the security of the second Web app’s login is not guaranteed. To overcome this, there was a minor change done in the bypass login, whereby there is an extra parameter passed from the first Web app to the second one, which is the key to access the second Web app. The drawback in this process is that there is always the dependency of the key parameter, and the second Web app has to be always called from the first one (scheduled or automated tasks cannot be run).
Web service call: This is generally used when the second and subsequent Web apps expose certain Web services, and the first Web app invokes calls to these Web apps through these Web service calls. The problem in this feature is that the developer is more dependent on the structure of the input/output of the Web service and is bound to handle all requests through them only.
What is single sign-on?
Though a bypass login and Web service call provide facilities to skip subsequent logins to different Web apps, there are some drawbacks in their overall architecture, as seen earlier. If we first understand the need for using multiple Web apps, we can easily grasp why a single sign-on is required.
Consider a complex enterprise Web app for a textile firm which involves various operations like ordering, samples, mailing, designing, etc. If we develop a single Web app to cater to all these needs, then maintaining it will be highly complex.
A service provider company that designs software for different industries will be always interested in developing individual modules and integrating the required pieces when desired. This will help in the sizing of the module and its maintenance. The process and benefits of this approach are as follows:
- Usage of different technologies in different modules, depending on what the module is required to do.
- Easy usage and faster work due to the delegation of several actions in parallel across different modules.
- Allows for the reuse of the modules for different Web solutions, as and when required.
Now when we think of a single sign-on facility for the above case, it’s very obvious that a bypass login or a Web service call cannot be advantageous in such real-time situations; in fact, they may further complicate the solution as it grows bigger in order to integrate more and more modules.
In short, single sign-on is a facility to skip or use the login information used in the first Web app for all subsequent Web apps without popping out the login screen for each one. There are many standard technologies and techniques used for SSO in the industry, and many of them are open source or freeware. We will discuss some of the most popular and robust technologies here.
But before delving further into the topic, let me share the terms that are going to be used hereafter, along with their meaning and usage.
LDAP – Lightweight Directory Access Protocol: This is a protocol used commonly in Web apps for looking up certain information from the servers; it is widely used in mail servers.
Datastore: This is the store in LDAP that keeps authentication and other access related data.
Directory server: This provides the datastore for LDAP and supports many protocols internally.
Authentication: This is a piece of information that is verified to certify or deny access, like the user name/password.
Realms: This is a kind of group or system to provide facilities for authentication. It offers a lot of features for configuration like policy setting, access control, privileges for realms, etc, which can be easily configured for role based access for different groups and logins. There are two configurations in OpenSSO — Default and New Config. The Default configuration is easy. The advantage is that it can be customised later and hence is meant for basic or first-time users. New Config, however, is meant for advanced users, and there may be some problems with getting the directory service port or cookie domain if the user doesn’t know each configuration setting and doesn’t provide them.
OAuth
One of the most popular and commonly used single sign-on solutions for Java Web apps is OAuth or OAuth 2.0, as the API library provided has a comprehensive facility for easy configuration, and it can be used with different application servers and a complex Web component architecture. But there are many other open source SSO frameworks available, too, which are listed below.
OpenSSO
This is more flexible in configuration as it has its own Web app and comes with a GUI based sophisticated configuration screen, which can be used to configure settings for a Web container using different Web apps for a single sign-on.
It also needs an LDAP (we will discuss this later) and a directory service for handling SSO authentication and a data store. It has a default configuration, which uses generic LDAPv3. We can configure it using the Sun Java System Directory Server for the data store.
JOSSO
JOSSO is another facility for SSO which is purely Java based and is also called Java Open SSO. The new version of JOSSO (1.6) supports all the latest Web servers like JBoss 4.2. This is a widely used solution, and the configuration is comparatively easier than OpenSSO.
There are some problems that can arise in JOSSO (as discussed a lot in JOSSO forums), particularly in relation to JaasSecurityManager in JBoss 4.x, which was not the case with JBoss 3.x. Also, with some proxy settings, JOSSO can be difficult to configure.
JOSSO can also be configured with LDAP, and it uses internal JAAS from JBoss for authentication.
Open LDAP
OpenLDAP is an open source provider of the SSO facility. It is complex to use but has a lot of features for authentication and configuration. OpenLDAP cannot be used alone, as it also requires an SSO application (like OpenSSO) for handling logins. We can use a combination of OpenSSO with OpenLDAP configuration. The main drawback in this open source application is that there is no good documentation for configuring and setting it up.
Apache Directory Studio
This is sophisticated technology which can be used as a custom authentication facility to the level that the user wants. The drawback, if any, is that Apache Directory server is supported only in Mac OS X, Linux and Windows.
SpringLDAP
SpringLDAP is a comprehensive LDAP feature from the Spring framework but it doesn’t work for SSO. It is meant for LDAP provisioning for directory services. Hence, it can be used with an SSO application for handling directory services.
There is a sub-module in the Spring framework called Acegi security, which can be used for SSO with LDAP. It has an easy-to-use approach called ‘persistent login cookie’ to bypass login. This is also called RememberMe.
The RememberMe facility has two types of approaches:
- It stores login information (base64 encrypted) in a cookie.
- It stores login information (base64 encrypted) in a database.
For the second approach, we need a table called ‘persistent logins’ with user details (which needs migration if your current Web app uses a different table/database for user information). The first approach can be simple and easy-to-use, but depends on the client facility to enable cookies.
Liferay
Liferay is a ready-to-use portal service provider that has a lot of technologies embedded in it to address the various requirements of a Web solution. Liferay supports SSO using CAS (Central Authentication Service) from Yale. This is an open source SSO solution. Please note that CAS requires certificate authentication created using a key tool. Also, CAS supports the RememberMe feature like the one explained above (Spring Acegi RememberMe).
Liferay supports many other SSO applications like NTLM (not freeware) and OpenSSO; it also supports LDAP and JAAS. The technical specifications of Liferay are given at https://www.liferay.com/product/tech-specs.
The Liferay admin guide (liferay-administration-guide-5.1.pdf) gives details on CAS, OpenID and other SSO solutions supported by Liferay, as well as on using Liferay with different application servers. [It has details on configuring JAAS and configuring SSO in all the latest Web servers for Liferay.]
This article just helps in giving readers a feel of the different technologies that can be used and doesn’t intend to be a user guide. It is up to the architect and designer to evaluate and analyse these technologies based on their actual requirements and bandwidth of usage.
