CAS+: Single Sign-On With Jifty (Part 2)by Andrew Sterling Hanenkamp
In the first part of this article, I shared my implementation of the Cental Authentication Service (CAS) protocol using the Jifty framework, CAS+. That article covered the basic details of how this single sign-on (SSO) system was implemented to include basic login and how a user's credentials are passed back to another web service. This covered most aspects of the CAS 1.0 protocol.
However, the CAS protocol provides much more than robust single sign-on. CAS 2.0 provides additional features for authentication by proxy. By using this extension, a web service may pass identity credentials on to additional services allowing services that are not directly web accessible, such as IMAP, SMTP, or other applications. CAS+ implements these extensions as well and this article will share, and this article will explain how those are implemented in Jifty.
This question was the biggest obstacle for me while trying to understand how the CAS protocol works. You can login, get a service ticket, validate that ticket, and then request a new special kind of ticket, and then there are callbacks and yet another set of tickets to worry about. Why?
The answer is that a certain web service might want to grant the user access to other services, especially to those that are not web-based. For example, let's say you have an intranet portal for your employees to check on vacation time, current benefits, email, etc. Your portal provides a central interface for everyone to get this information, but the vacation time is actually stored in a performance management system, the benefits are pulled from your company's financial services partner, and your email is pulled from your IMAP server. Each of these systems aren't going to hand over any information without knowing who the information is being handed to.
By using CAS to proxy the authentication, they can all be sure of the identity of the individual requesting the information while you are still keeping the actual credentials private to the CAS system.
The process of authentication by proxy is identical up to the point of service authentication. I described the first part of this process in Part 1. Now, let's take a look at how the process is modified to handle proxy authentication. I'm going to break the process down into three parts to help simplify the explanation.
The first phase of proxy authentication in CAS is exactly the same as typical authentication, login. The steps in this phase are:
- User requests a restricted page. The client web service will redirect the browser to the CAS server for authentication. The redirect contains the service parameter giving the URL to return to upon authentication.
- User logs in or has her previous login checked and verified. The browser contacts the login form of the CAS server and the CAS server either requests login or determines the user has already logged in and skips to the end of the next step.
- The CAS server verifies the user's credentials and sends the user back to the web service with a Service Ticket. On successful login (or if the user logged in previously in this session), the CAS server redirects the user to the URL given in the original service parameter. This redirect as a Service Ticket attached in the ticket parameter.