oreilly.comSafari Books Online.Conferences.


CAS+: Single Sign-On With Jifty (Part 2)
Pages: 1, 2, 3, 4


Now, the user has identified herself with the CAS server. The CAS server has passed credential information to the original web service by way of the browser and validated it directly for the web service. The web service has requested a Proxy Granting Ticket and received one via callback and linked that PGT to the user's identity. Now, the web service needs to securely pass the identity of the user on to the proxied application.

  1. The user requests a page that includes data pulled from a proxied application. As far as the user is aware, she's just clicked on a link to get information. The web service, upon receiving the request, knows that the user is now logging into an external application and proceeds to authenticate using the Proxy Granting Ticket it acquired previously.
  2. The web service requests a Proxy Ticket from CAS. To proxy authentication, the web service must first request a Proxy Ticket from CAS. It does so by contacting the CAS server and passing the name of the application that will be authenticating (the targetService) and the Proxy Granting Ticket the web service acquired earlier (the pgt). CAS responds with a Proxy Ticket, which is more or less the same thing as a Service Ticket.
  3. The web service passes this Proxy Ticket to the proxied application. The only credentials the application must provide to the proxied application is the Proxy Ticket.
  4. The proxied application validates the Proxy Ticket with CAS. The proxied application now performs a validation request that is nearly identical to the service validation performed for Service Tickets. The application passes it's service name (which must match the targetService used to request the Proxy Ticket) and the ticket. If the Proxy Ticket is valid, the CAS server returns the username.
  5. The proxied application is now authenticated and is able to return data accessible by the validated user. The web service and proxied application may continue communicating to retrieve and modify data according to their shared knowledge of the user's identity.
  6. The client web service may now return any data retrieved from the proxied application. The process is now complete. The user has accessed data from the proxied application through the web service.

In the description of this process, I've separated the request for a restricted page from the request for a proxied application. I've done this to simplify the description of this complex process, but both actions could occur within the same request.

I've also performed the request of fetching a Proxy Granting Ticket during initial service validation. However, this could wait until later as well by invoking the login process a second time to get a new service ticket and performing a new service validation request. When such actions are performed is dependent upon the needs and implementation of the client web service.

Also, I've left out the fact that a proxied application can request its own PGT using its callback URL. Then, that application can proxy the authentication of another application. Proxied authentication may be arbitrarily nested.

CAS+: Requesting a proxy ticket

How does CAS+ handle creating and returning a Proxy Ticket? Here's the rule in the CASPlus::Dispatcher that shows this:

on 'proxy' => run {
    my $proxy = Jifty->web->new_action(
        class     => 'Proxy',
        arguments => {
           pgt           => get 'pgt',
           targetService => get 'targetService',

    set result => $proxy->result;
    show '/proxy';

Here the dispatcher sends the request to the Proxy action (CASPlus::Action::Proxy) and then response with the "/proxy" template. As with the other actions, the Proxy action spends most of the code dealing with error cases. The king work that it does is to load the proxy grant session associated with the given Proxy Granting Ticket and then creates a new proxy session record for the given targetService.

On success, the "/proxy" template will render something that looks like:

<?xml version="1.0"?>
<cas:serviceResponse xmlns:cas="">

CAS+: Validating a proxy ticket

The only other new step in this process is that of validating the Proxy Ticket. However, the nature of this validation is practically identical to that of Service Ticket validation. In fact, the CAS protocol species that the Proxy Ticket validator also be capable of validating Service Tickets. Because of this, the ProxyValidation action is a subclass of the Validation action introduced in Part 1 of this article.

If the incoming ticket starts with "ST-", it is identified as a Service Ticket and the superclass is used directly:

if ($ticket =~ /^ST-/) {

Otherwise, the much of the same process for validating a Service Ticket is applied tot he Proxy Ticket instead. Much of the code used by the Validation action has been extracted into inherited subroutines to prevent a lot of code from being duplicated.

Most of the code that remains in the ProxyValidation action is related to the error handling messages that are specialized for use with Proxy Ticket validation.

There is, however, one major distinction between Proxy Ticket validation and Service Ticket validation in the output template, "/proxyValidate": it includes a list of proxies, which isn't part of the "/serviceValidate" template. As such, a typical Proxy Ticket validation response will look something like this:

<?xml version="1.0"?>
<cas:serviceResponse xmlns:cas="">

That summarizes most of the major code additions required to make proxy authentication work.

Pages: 1, 2, 3, 4

Next Pagearrow

Sponsored by: