ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


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

Validation

Once the user has logged in and the user is redirected back to the restricted page with the Service Ticket, the client web service has to validate the service ticket. This is similar to non-proxy authentication, but an extra step is involved.



  1. The user requests the original page with the Service Ticket. The browser passes the ticket parameter. Until the web client returns the response, the browser no longer takes part in the transactions that occur.
  2. The web service contacts the CAS server directly to validate the Service Ticket. The web service passes the service URL, the Service Ticket, and a callback URL to the CAS server. To implement proxy authentication, the web service must provide a special URL just for the CAS server to contact. The CAS specification also states that this URL must be secured with SSL.
  3. The CAS server contacts the PGT URL as a callback with a new Proxy Granting Ticket (PGT) and PGT IOU. The CAS server passes the Proxy Granting Ticket, which is used later to request a special kind of service ticket, called a Proxy Ticket. CAS also sends a Proxy Granting Ticket IOU, which is used to link the PGT to the username. If everything is received correctly, the callback returns success to CAS.
  4. CAS completes the validation request by returning a response containing the username and PGT IOU. This response informs the web service the identity of the logged user as well as giving the PGT IOU, which allows the web service to associate the PGT given separately with the username.
  5. The web service now responds with the contents of the requested page now that the identity has been confirmed. This assumes that the user identified by CAS has authorization to view the requested page. It's still possible that the user doesn't have the required privileges, but CAS is only concerned with authentication. Authorization is not handled by CAS.

Why the extra callback? Why couldn't CAS just pass the Proxy Granting Ticket back with the username? I presume this is for additional security. A malicious attacker must snoop two different request/response pairs going in opposite directions (and crack the encryption on both) to get a complete picture of what is happening.

However, if a malicious user can snoop just the callback communication and gain just the PGT, the attacker has all that's required to spoof access to an account, which is why the CAS protocol requires this communication be encrypted. It is very important that the client web service not betray the PGT for this reason. (And perhaps a reason for a CAS server implementation to refuse to perform proxies unless the service is pre-approved for such access.)

CAS+: The PGT callback

To perform this additional callback step, the System uses LWP::UserAgent to pass the PGT and PGT IOU in an HTTP GET request. This happens in the middle of the CASPlus::Action::Validate action:

$pgt->create(
    service_session => $service_ticket,
    callback_url    => $pgt_url,
    proxy_session   => $proxy_ticket,
);

# Contact the callback URL with pgt and pgtIou
my $response = $ua->get(
    $pgt_url 
        .'?pgt='.$pgt->proxy_granting_ticket
        .'&pgtIou='.$pgt->proxy_granting_iou
);

Here the $pgt_url holds the value passed in the pgtUrl parameter. The Validate request creates a new proxy grant session and then passes the identifiers. If the callback returns success (i.e., $response->is_success is true), the Validate action adds the PGT IOU to the XML response with the username. The response to the client web service will look something like this:

<?xml version="1.0"?>
<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
    <cas:authenticationSuccess>
        <cas:user>sterling</cas:user>
        <cas:proxyGrantingTicket>PGTIOU-DH8TJ1...</cas:proxyGrantingTicket>
    </cas:authenticationSuccess>
</cas:serviceResponse>

figure 3

Pages: 1, 2, 3, 4

Next Pagearrow





Sponsored by: