Imagine the following scenario: you are the operator of a small website that has a private user’s area which requires visitors to login to view. A few months later, you want to add a gallery application which also requires users to login and, finally, you want users to be able to edit a community wiki, but not allow non-members to make changes.

We can see that we have two choices: force the users to login to each separate application separately, or somehow combine all the applications under a single login.

A Central Authentication Service

Central Authentication Services allow a user to share a single login across multiple applications and even websites. OpenID and Yahoo are examples of large CAS hybrids that are becoming increasingly popular amongst social networking sites. However, CAS does not have to be so global in scope, many universities and companies use CAS when their services are best provided by several applications.

How it works

The series of events that occur during a CAS authentication session are as follows:

1. User attempts to gain access to the secure area of a photo gallery
2. The gallery detects that this user is not authenticated to view this content
3. The user is re-directed to the login page of the Central Authentication Service. A callback URL is passed to the CAS by means of a GET variable
4. The user enters their login information and it is verified. A cookie is set to identify this user as authenticated in the future
5. The CAS redirects the user to the callback passed by the photo gallery. A ticket is passed to the photo gallery callback page by means of a GET variable
6. The photo gallery establishes a secure connection to the CAS and checks to ensure the ticket is valid, if it is, the user has been successfully authenticated

Depending on the CAS setup, when the user enters another secure area of the website, say the wiki, they will be redirected to CAS, then transparently redirected back to the wiki callback page. This occurs because the user has already authenticated themselves with CAS, so there is no need to re-enter login credentials. To the user, it appears as if they were immediately authenticated by the wiki.

A Central Authentication Service also reduces some aspects of user information management as, if the user wishes to update their password; they need only do it once. However, CAS does not solve the problem of propagating other types of user information, such as the users name and contact information to the various applications. Furthermore, the authentication routines of the participating applications much be refactored to authenticate the user via CAS, then load the user information out of the local application database.

In Conclusion:

Central Authentication is a good way to improve the user experience if you are currently forcing users to authenticate multiple times. Furthermore, from a developers standpoint, it is a clean and safe way to pass authentication tokens between applications, especially if these applications may reside on separate domains.

For more information on CAS, including a JAVA server implementation, protocol descriptions and clients in multiple languages visit http://www.ja-sig.org/products/cas/index.html