Single Sign-On Implementation Flaws

By balaji

September 7, 2011

In today's world of complex distributed systems, we see a lot of applications being used by organizations. Due to the increasing number of applications, management of user information has become a nightmare. Hence, a terminology called Single Sign-On (SSO) was introduced. As the term suggests, it is a single sign-on for all the applications in an organization. A sign in to one is considered the same as a sign in to all. Logging in to one would mean a login to all.

In today's world of complex distributed systems, we see a lot of applications being used by organizations. Due to the increasing number of applications, management of user information has become a nightmare. Hence, a terminology called Single Sign-On (SSO) was introduced. As the term suggests, it is a single sign-on for all the applications in an organization. A sign in to one is considered the same as a sign in to all. Logging in to one would mean a login to all.

For SSO to be implemented, there needs to be a centralized authentication scheme. This scheme authenticates the user according to its own data store (which may be a database, LDAP, or any kind of password repository). It is responsible for signing in the users to all their associated applications/systems after authentication so that the user need not log in to each application individually. This centralized authentication scheme should also logout the user from all the applications on a single user logout.

Here is a pictorial representation of an SSO implementation:


SSO systems may also be used to implement access controls. Systems using access controls with SSO will also comprise a repository of user access profiles [i.e. information regarding which user has access to which application(s)]. After authenticating the user, such systems check user access profiles and give them SSO access to the listed application in their respective profiles. The users are not given access to SSO system-integrated applications that are not in their respective access profiles.

A pictorial representation of SSO implementation on user access profiles (the illustration considers that the user logging in has access to the applications A, B and D only, and not to C):


SSO authentication is often clubbed with 2 factor or multifactor authentication, using passwords, hardware or software tokens, smart cards or biometrics or a combination of these.

SSO systems have a major disadvantage in that if the single password is lost, all the applications are at risk. (Discussion of SSO disadvantages is out of scope of this white-paper. So, we stop here.)

SSO Implementation: Common Mistakes

Weak authentication mechanisms

The authentication mechanism is the biggest intellectual property of SSO systems as the entire game revolves around it. If it allows a user to bypass the authentication process, it loses every application. A sound authentication scheme is a must.

User session does not expire

The user session does not expire in all the applications on user logout. Just as logging in once allows access to all, logging out once should also terminate the sessions on all the applications. The user logout information should be transmitted to all the applications by the SSO system.

Weak authorization scheme

The SSO authorization scheme is supposed to allow access to user-profiled applications only. It should be resilient to application-level flaws that allow the faking of authorization tokens for obtaining access to non-profiled SSO-integrated applications.

Session killed in one domain but not in the other

This is the flaw observed in multidomain SSO-integrated applications, wherein the session is killed in a few domains and not in the others.

Domain whitelist or application whitelist is not created

A whitelist is an allowed list of applications in an SSO implementation. This defines access to integrated applications only. Lack of a whitelist may allow access to a new application (i.e. never intended by the SSO system), redirect the user to a few fake pages, or can be used to send authorization tokens (at least).

Weak domain whitelisting or application whitelisting

This is a slight variation of the above point. Here, a whitelist is defined but because of the flawed application logic, a user is not screened through the entire whitelist. This allows the existence of flaws similar to those stated above.

Open Source SSO Solutions

There are a few open source SSO solutions available. People or enterprises can use these solutions directly or improvise them to suit their needs.

It is quite important to understand the open source SSO solution before customizing it. It is equally important to understand how the required functionality can be incorporated by customizing the open source SSO solution. Otherwise, the implementation would end up having an SSO flaw as discussed in the previous section.

We shall further discuss one of the open source SSO solutions and its flawed implementation. The product is Central Authentication Service (CAS) from Jasig.

Central Authentication Service (CAS)

Central Authentication Service (CAS) is an open source framework available at It is built on a spring framework. It provides centralized user authentication for various integrated applications and thus acts as a single sign-on platform.

As listed in Jasig's website, CAS provides an enterprise single sign-on service with the following features:

  • An open and well-documented protocol.
  • An open-source Java server component.
  • A library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others.
  • Integrates with uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle and others.
  • Community documentation and implementation support.
  • An extensive community of adapters.

This article does not discuss vulnerabilities in the CAS SSO solution, but discusses how the default implementation of CAS might lead to certain vulnerabilities in the SSO architecture. It also emphasizes that before using an open source SSO solution, it is important to customize and harden it according to the application's environment.

CAS Basic Architecture

CAS 1.0 and 2.0 are basic web applications that implement JSPs and Java Servlets. They need to run on HTTPS and they have 3 URLs that form an important part of the Authentication Control Flow:

  1. The Login URL: http://CAS.EDU/CAS/servlet/login
    • It should implement the authentication logic. Ideally, it should have some custom Java code or call an authentication API.
    • It may send a cookie for the single sign-on. This is optional.
  2. The Validation URL: http://CAS.EDU/CAS/servlet/validate
    • It validates a token sent by the web application or front end (that wants to establish the identity of a user).
    • It checks the internal database to confirm whether the URL that passed the token is a valid URL.
  3. The Logout URL: http://CAS.EDU/CAS/servlet/logout
    • It destroys the single sign-on cookie. This is optional.

The important components of the CAS architecture include:





Web Browser

Any browser that supports JavaScript and cookies.


CAS - Central Authentication Server

A trusted arbiter of authenticity -

  • Performs authentication.
  • Grants cookies.
  • Keeps mapping of the user to the application/service.



Any web application that authenticates users via CAS.



A service that wants to access other services on behalf of a particular user -

  • Introduced in CAS 2.0 architecture.



A back-end service that functions behind the web application and accepts proxied credentials -

  • Enables multitiered CAS implementation.
  • The web application may function as a front-end for many targets.
  • The proxy impersonates users for all targets.

The important parameters are:





Service ticket (ST)

A ticket sent by CAS, through the user's browser, to a service. Each ST can be used only once and must be combined with the unique identifier for one specific service in order to be useful.


Ticket-granting cookie (TGC)

A ticket encapsulated by a cookie that is sent to the user's web browser and returned only to CAS over a secured channel only. This ticket establishes the user's identity with CAS and allows CAS to act as a single sign-on system for the web.


Proxy-granting ticket (PGT)

A ticket sent by CAS to a service having a valid ST. This ticket (associated with an individual service and an individual user) confers the ability to produce proxy tickets.


Proxy-granting ticket IOU

A ticket sent by CAS in a service validation response and with a PGT to the callback URL. It is the web application's responsibility to maintain a table to correlate PGTIOUs and PGTs (see the flow chart below).


Proxy ticket (PT)

A ticket usable by a proxy to access a target by impersonating a single user. The PT carries information about the proxy or proxies attempting to gain access to the target. For targets that are also second- or higher-level proxies, a PT may be used to obtain a PGT but this PGT will preserve information about the linear series of proxies that lie between the user and the ultimate target.


Control Flow in Brief (does not include a Proxy)

  1. A user accesses the Home page of the web application.
  2. The web application redirects the user to the CAS Login page.
  3. The user submits login credentials to CAS. CAS verifies the user’s credentials successfully.
  4. CAS sends a Ticket Granting Cookie in response and stores it in the user's browser. The cookie has a set path with the Secure attribute set. It also sets a Service Ticket (a sort of token) and appends it as a URL query string to the web application URL.
  5. The user is redirected to the web application with the Service Ticket in the URL query string.
  6. The web application reads the Service Ticket and constructs an SSL request to verify this Service Ticket or token sent by the user's browser with the CAS server.
  7. The CAS server extracts the Service Ticket and validates the application's URL internally.
  8. The CAS server sends the identity of the user corresponding to the Service Ticket issued.

The web application is free to use this user identity, store it as a session object, and maintain a unique identity with the user from here-on as a session token. Alternatively, it can keep querying the CAS server every time the user requests for a new service within its domain.

There are also two key XML files:

  1. cas-servlet.xml
    This maintains the mapping of the URI to its respective controllers. This in-turn ensures that the user is directed to the correct controller class for validation. Reference to the login flow is also present here.
  2. login-webflow.xml
    This defines how the login flow has to proceed. This is done via a number of decision and action states. This is a key file and understanding the flow is very important for a secure implementation.

Now, we have a fair understanding of the basic architecture of CAS.

Remember that the default behavior of CAS is to generate service tickets for any service request that is received. We will further discuss how this default behavior may lead to a flawed SSO implementation.

Case Study: A flawed CAS SSO Implementation

Consider a CAS SSO implementation designed to provide access to 3 applications. (Let's assume those applications to be A, B and C.) These applications use a numeric parameter, (e.g. Client_access) which indicates the user access profile. This numeric parameter can have a predefined set of files, which can be interpreted as the access granted to applications like -

  • Client_access = 111111 means that the user has access to application A only.
  • Client_access = 222222 means that the user has access to application B only.
  • Client_access = 333333 means that the user has access to application C only.
  • Client_access = 121212 means that the user has access to applications A and B only.
  • Client_access = 131313 means that the user has access to applications A and C only.
  • Client_access = 232323 means that the user has access to applications B and C only.
  • Client_access = 123123 means that the user has access to all the three applications.
  • Client_access = 000000 means that the user has access to none of the applications (ideally, there should be no such user, who has login credentials but no access).

The normal flow of this application is that if a user is authenticated successfully, he/she is transferred to the SSO Home page, which shows the list of applications mapped to the user. The mapped application links are displayed on the basis of the Client_access parameter (stored in the data store) for the logged-in user. Normally, the user clicks on one of these links and is directed to the corresponding web application.

Behind the scene

The user accesses the URL of one of the applications, which redirects him/her to the CAS SSO Login page. On providing login credentials and after successful authentication, the server sends the respective Client_access parameter in HTML code, which dynamically enables/disables the links to the applications – A, B and C. At the time of authentication, the server also sets the Ticket Granting Cookie (TGC) and sends it to the browser. The user then clicks on the link of one of the allowed applications. This action generates a service request, which contains a Service Ticket (ST), in the URL. The CAS server validates the ST and grants access to the user.

Exploitation of this SSO implementation

  • To gain access to non-mapped applications
    Let us see how this implementation can be exploited in order to gain access to non-mapped applications. In case a user logs in with the Client_access parameter as 131313, it means that the user has access to applications A and C only. Given below are the steps for obtaining access to application B:
    • Log in to the CAS SSO portal and authenticate successfully.
    • The above step provides the user with the Home page of application B as disabled. Now, the user also has the TGC.
    • Type the URL of application B in the browser. (The URL can be stolen from the HTML code, browser history of any user or from the local memory.)
    • Note that the ST is appended to application B's URL as a query string (e.g.
    • The CAS server allows the user to access to application B.
  • To conduct phishing attacks
    A variation of the exploitation explained above can be used to conduct phishing attacks. The steps for this are as follows:

    This way, phishing can be conducted or users can be redirected to malicious sites adversely affecting the brand name of the organization.

  • To steal Service Tickets
    Since the STs are generated for any application that is requested, the fake services can steal STs. As mentioned above, the "" URL contains STs. Once lots of STs are stolen, an attempt can be made to reverse-engineer the logic of the generation of STs.

What went wrong with this SSO implementation?

The answer is in the article itself. "The default behavior of CAS is to generate Service Tickets for any service request that it receives". Since STs are generated for any service, the tickets can be stolen and redirected to malicious sites. Clubbed with the flaws in your customization, it may lead to something similar to providing access to non-mapped applications (case 1 in the above page).

What does JASIG recommend?

The Service Management console can be used to control which services should authenticate via CAS. More details are available at

It is used to create a "Whitelist" of applications that are allowed to authenticate to CAS.

Here are some of the salient aspects of the Service Management console:

  • Administered using a Web UI (CAS-enabled)
  • Requires a database
  • Allows the control of which attributes will be released to which services
  • Must add the service registry URL as the first service in order to avoid locking out the access to the service registry management interface.
  • Deleting all Registered Services places CAS in its default mode, which is to accept all incoming authentication requests.

This will ensure that the Service Ticket is not generated for any unknown service.

How can organizations customize?

Organizations can prevent these vulnerabilities by customizing the CAS implementation.

The workaround lies in customizing the login-webflow.xml (discussed earlier) properly. There are various decision states in this XML file. The Write decision state checks the requested service parameter in the URL. Each decision state can check the service parameter for a valid service. If at any decision state, it matches with the valid service, the flow should be directed toward granting access normally. Also, if the flow passes through all the decision states and its service parameter does not match with any, then the user session should be terminated.

A sample code is shown below:

<decision-state id="checkservice">
<if test="$(externalContext.requestParameterMap['service']
== '')"
then="generateServiceTicket" else="failure" />
<action-state id="generateServiceTicket">
<action bean="generateServiceTicketAction" />
<transition on="success" to="home" />
<transition on="error" to="login" />
<action-state id="failure">
<action bean="failure" />
<transition on="success" to="login" />
<transition on="error" to="login" />


Understand any open source product thoroughly before customizing it. Clearly define what has to be customized. Customize it but keep in mind the flaws related to SSO. Remember the points discussed in this article. Last but not the least, your application should not just be secure against SSO-related flaws, but also protected from web application attacks.


Tags: Features