Single Sign On

In the last few weeks I was asked to help to integrate a set of built-in-house web applications with a Single Sign On (SSO) solution. After working with people from different teams, I realized that it would be a good idea to write a brief description of how the SSO solutions work in general. Perhaps this might help you to get started if you have to do something like this at some point.

SSO is by no means a new technology. It has been in use for a long time. Even before the Web Applications were available.

The most primitive of SSO systems is a piece of paper per user with a small table listing systems with the user names and passwords. This list can be generally stamped on the user monitor. Later on it can evolve, instead any simple piece of paper, it can be a post-it.


(for those of you interested in how I created this picture, I did it using the napkin look and feel)

Yes, you might be thinking that I am kidding here. And to some extent I am. However, this has been a big concern in the corporate world. That's the way it used to be, not by design, and it still is in some companies. Lots of applications, managed by different teams in the famous "silos", not integrated, each requiring the user to authenticate with its own username/password... you know the picture.

I think that that's how the need of SSO got started.

Early SSO systems worked as the post-it that the users where sticking to their monitors.

They were repositories of users/passwords pairs protected by a password. In that way before the user would authenticate to the destination system, they would first access the SSO repository, fetch their passwords, and continue authenticating with the system they were intending to work on the first place.

Lately, In a web based environment, this can be extremely simplified with a well know device: cookies.

Example

We will go over an SSO implementation with an example. Let's have 3 major components: The SSO server, Application A, Application B.

Here is how the system would work:

1) The user tries to access the application A.

2) Application A realizes that the user has not been authenticated. (See "user has been authenticated" for details).

3) Application A sends an HTTP redirect to the SSO server.

4) The SSO server sees that the user is not authenticated (again, See "user has been authenticated" for details).

5) The SSO server requires the user to authenticate.

6) The user submits username/password

7) SSO Server validates username/password. If they are valid, the user is "granted permission".

8) The user is redirected to Application A.

9) Application A sees that the user has been authenticated, and proceeds.

Granting permission:

When the username and password are validated by the SSO server, a unique large token is generated for the user. The token is going to have a unique identifier for the user's session. The SSO server keeps a list of the tokens associated with the credentials of the user that owns it. This token is set by the SSO server in the user's browser as a cookie.

User has been authenticated:

For an application to validate that a user has been authenticated it has to follow this steps:

1) Check for the token in the cookies.

2) Query the SSO server for the credentials associated with the token. If the token is valid, the SSO returns the credentials of the user for the application to continue. If the token is not present, or is invalid, the application knows that the user has not been authenticated, and is redirected to the SSO server.

This makes it look like there is a lot of work to get this type of setup. Luckily, it is not complicated at all. Most SSO servers come with a plug-in that is installed in the application/web server that intercepts all the requests, and performs the logic just described. Any application deployed in such a server will automatically get the user credentials, populated by the plug-in, just as if the user was authenticated locally using the JAAS framework.

A Note on Cookies

As most of you know the capabilities of setting and reading cookies are restricted by the domains. A web server that does not belong to the domain where the cookie was set will not be able to read the cookie.

For that reason the applications and the SSO server have to belong to the same domain. Indeed, if they are not to be part of the same domain the cookies would not work. For that case the URL rewriting technique can be used.

Development TIP:

When you are developing your app, no need to authenticate with the SSO. Just have each developer to work with a simple JAAS authentication within a local flat file (most of the IDEs have this by default). Get them to complete the development, and when you are ready to test, deploy it in your testing environment using the SSO plugin.