Single sign-on (SSO): Concepts, Methods and Frameworks

21 July, 2008 at 17:34 3 comments

Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems.

As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication.

As IT systems proliferate to support business processes, users and system administrators are faced with an increasingly complicated interface to accomplish their job functions. Users typically have to sign-on to multiple systems, necessitating an equivalent number of sign-on dialogues, each of which may involve different usernames and authentication information. System administrators are faced with managing user accounts within each of the multiple systems to be accessed in a co-ordinated manner in order to maintain the integrity of security policy enforcement. This legacy approach to user sign-on to multiple systems is illustrated below:

Legacy Approach to User Sign-on to Multiple Systems

Historically a distributed system has been assembled from components that act as independent security domains. These components comprise individual platforms with associated operating system and applications.

These components act as independent domains in the sense that an end-user has to identify and authenticate himself independently to each of the domains with which he wishes to interact. This scenario is illustrated above. The end user interacts initially with a Primary Domain to establish a session with that primary domain. This is termed the Primary Domain Sign-On in the above diagram and requires the end user to supply a set of user credentials applicable to the primary domain, for example a username and password. The primary domain session is typically represented by an operating system session shell executed on the end user’s workstation within an environment representative of the end user (e.g., process atrributes, environment variables and home directory). From this primary domain session shell the user is able to invoke the services of the other domains, such as platforms or applications.

To invoke the services of a secondary domain an end user is required to perform a Secondary Domain Sign-on. This requires the end user to supply a further set of user credentials applicable to that secondary domain. An end user has to conduct a separate sign-on dialogue with each secondary domain that the end user requires to use. The secondary domain session is typically represented by an operating system shell or an application shell, again within an environment representative of the end user. From the management perspective the legacy approach requires independent management of each domain and the use of multiple user account management interfaces. Considerations of both usability and security give rise to a need to co-ordinate and where possible integrate user sign-on functions and user account management functions for the multitude of different domains now found within an enterprise. A service that provides such co-ordination and integration can provide real cost benefits to an enterprise through:

  • reduction in the time taken by users in sign-on operations to individual domains, including reducing the possibility of such sign-on operations failing
  • improved security through the reduced need for a user to handle and remember multiple sets of authentication information.
  • reduction in the time taken, and improved response, by system administrators in adding and removing users to the system or modifying their access rights.
  • improved security through the enhanced ability of system administrators to maintain the integrity of user account configuration including the ability to inhibit or remove an individual user’s access to all system resources in a co-ordinated and consistent manner.

Single User Sign-On To Multiple Services

Such a service has been termed Single Sign-On after the end-user perception of the impact of this service. However, both the end-user and management aspects of the service are equally important. This approach is illustrated in the diagram above. In the single sign-on approach the system is required to collect from the user as, part of the primary sign-on, all the identification and user credential information necessary to support the authentication of the user to each of the secondary domains that the user may potentially require to interact with. The information supplied by the user is then used by Single Sign-On Services within the primary domain to support the authentication of the end user to each of the secondary domains with which the user actually requests to interact.

The information supplied by the end-user as part of the Primary Domain Sign-On procedure may be used in support of secondary domain sign-on in several ways:

  • Directly, the information supplied by the user is passed to a secondary domain as part of a secondary sign-on.
  • Indirectly, the information supplied by the user is used to retrieve other user identification and user credential information stored within the a single sign-on management information base. The retrieved information is then used as the basis for a secondary domain sign-on operation.
  • Immediately, to establish a session with a secondary domain as part of the initial session establishment. This implies that application clients are automatically invoked and communications established at the time of the primary sign-on operation.
  • Temorarily stored or cached and used at the time a request for the secondary domain services is made by the end-user.

From a management perspective the single sign-on model provides a single user account management interface through which all the component domains may be managed in a coordinated and synchronised manner.

Significant security aspects of the Single Sign-On model are:

  • the secondary domains have to trust the primary domain to:
    • correctly assert the identity and authentication credentials of the end user,
    • protect the authentication credentials used to verify the end user identity to the secondary domain from unauthorised use.
  • The authentication credentials have to be protected when transfered between the primary and secondary domains against threats arising from interception or eavsdropping leading to possible masquerade attacks

Why choose single sign-on?

How many of you have had to implement your own authentication mechanism — usually some simple database lookup? How often have you stopped to think about the workflow needed for creating and managing user accounts? This is a common task in any development project. If you are lucky, your organization already possesses some common classes or libraries you can use. But it is often a task that is overlooked — seen as trivial, something that occurs only in the background.

In general, a coherent authentication strategy or a solid authentication framework is missing. Over time this leads to a proliferation of applications, each of which comes with their own authentication needs and user repositories. At one time or another, everyone needs to remember multiple usernames and passwords to access different applications on a network. This poses a huge cost for the administration and support departments — accounts must be set up in each application for each employee, users forget their passwords, and so on.

Authentication is a horizontal requirement across multiple applications, platforms, and infrastructures. In general, there’s no reason why user Mary should need multiple usernames. Ideally she should only need to identify herself once and then be provided with access to all authorized network resources.

The objective of SSO is to allow users access to all applications from one logon. It provides a unified mechanism to manage the authentication of users and implement business rules determining user access to applications and data.

Before I get into the technical details of single sign-on, take a quick look at some of the benefits and some of the risks. Benefits include the following:

  • Improved user productivity. Users are no longer bogged down by multiple logins and they are not required to remember multiple IDs and passwords. Also, support personnel answer fewer requests to reset forgotten passwords.
  • Improved developer productivity. SSO provides developers with a common authentication framework. In fact, if the SSO mechanism is independent, then developers don’t have to worry about authentication at all. They can assume that once a request for an application is accompanied by a username, then authentication has already taken place.
  • Simplified administration. When applications participate in a single sign-on protocol, the administration burden of managing user accounts is simplified. The degree of simplification depends on the applications since SSO only deals with authentication. So, applications may still require user-specific attributes (such as access privileges) to be set up.

Some of the more frequently mentioned problems with single sign-on include the following:

  • Difficult to retrofit. An SSO solution can be difficult, time-consuming, and expensive to retrofit to existing applications.
  • 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 logons, the user may only be logged into one system at the time and so only one resource is compromised.
  • Single point of attack. With single sign-on, a single, central authentication service is used by all applications. This is an attractive target for hackers who may decide to carry out a denial of service attack.

So, SSO is not without its disadvantages, but I believe the advantages from a viewpoint of users, administrators, and developers can outweigh those disadvantages.

Some Frameworks


The Open Web SSO project (OpenSSO) provides core identity services to simplify the implementation of transparent single sign-on (SSO) as a security component in a network infrastructure. OpenSSO provides the foundation for integrating diverse web applications that might typically operate against a disparate set of identity repositories and are hosted on a variety of platforms such as web and application servers. This project is based on the code base of Sun JavaTM System Access Manager, a core identity infrastructure product offered by Sun Microsystems. (more)


JOSSO – Java Open Single Sign-On Project Home

JOSSO, or Java Open Single Sign-On, is an open source J2EE-based SSO infrastructure aimed to provide a solution for centralized, platform neutral, user authentication and authorization.

The framework allows multiple web server/applications such as the Apache HTTP Server, Apache Tomcat, JBOSS, ASP, PHP etc to authenticate users with credential store. JOSSO communicates with credential stores over the Lightweight Directory Access Protocol (LDAP) or a JDBC connection.

JOSSO exposes Single Sign On services using SOAP over HTTP protocol allowing it to easily integrate with non-Java applications. JOSSO implements JAAS (Java Authentication and Authorization Service) to authenticate and enforce access controls upon users. (more)

SAML Single Sign-On (SSO) Service for Google Apps

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.

Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar. Using the SAML model, Google acts as the service provider and provides services such as Gmail and Partner Start Pages (PSP). Google partners act as identity providers and control usernames, passwords and other information used to identify, authenticate and authorize users for web applications that Google hosts. (more)


Bookmark and Share


Entry filed under: Java, JEE, Security, Single sign-on, SSO. Tags: , , , .

Amazon Web Services: Overview and Example with Java and PHP JSON (JavaScript Object Notation): Concepts, Methods, Examples and Security Threats

3 Comments Add your own

  • 1. Recent Faves Tagged With "sso" : MyNetFaves  |  27 October, 2008 at 10:50

    […] public links >> sso Single sign-on (SSO): Concepts, Methods and Frameworks First saved by dradicke | 1 days ago Thank you, SiteMinder First saved by tles | 9 days ago […]

  • 2. Vivek  |  11 October, 2012 at 04:00

    Thanks for sharing this article. It really is cool for first timer.

  • 3. Kaminomoto  |  1 July, 2013 at 12:53

    Hi, after reading this amazing post i am as well cheerful
    to share my knowledge here with mates.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

IT Passion’s Store



Get the Source
OSGi supporter
JUG Milano

Upcoming Events


Blog Stats

  • 387,886 hits

My PageRank

What's My Google PageRank?

%d bloggers like this: