Proxy CAS Walkthrough

Proxy CAS Walkthrough

Added by Andrew Petro
, last edited by Peter Chung Yan Thung
on Feb 25, 2009
 (view change
)
show comment
hide comment

Comment:
add a return next to some of the urls as it wasn't showing in my browser.

A manual walkthrough of CAS proxy tickets.
This walkthrough was provided by David Spencer on the CAS Mailman list.

Introduction

When I was trying to understand the mechanisms involved in writing
proxying applications using CAS, I found it very helpful to manually
walkthrough the aquisition of a proxy ticket. The CAS server played
itself in this exercise and I played all the other roles - user,
proxying application and proxied application - simply by constructing
URLs and feeding them into a web browser.

The only part of the exercise that can't be done with just a web
browser and careful URL construction is the part where CAS makes it's
own callback to the proxying application. For this, I chose a proxy
callback url on a machine for which I had access to the log files and
scanned through the HTTP requests to find the information I wanted.

Step One: login

To start with, log in to CAS with some invented service:

https://foo.bar.com/is/cas/login?service=http://localhost/bling

On successful login, CAS will redirect you to the service with a
ticket appended (it doesn't matter that the service is made up as the
ticket you're after is part of the url and will appear in the location
bar even if your browser can't find the resource):

http://localhost/bling?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS

Step Two
(a): verify the ticket and be done

So, playing the role of the first application (not a proxying
application at this stage - lets just see if we can get our application
authenticated without proxying for now), you need to take the ticket
and turn it into a username:

https://foo.bar.com/is/cas/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS&service=http://localhost/bling

which will produce a result like:

<cas:serviceResponse xmlns:cas

='http://www.yale.edu/tp/cas'>




<cas:authenticationSuccess>




<cas:user>

endjs</cas:user>




</cas:authenticationSuccess>




</cas:serviceResponse>

This is the end of the road for normal applications that don't need to proxy other applications.

Step Two (b): verify the ticket and enable further proxying

If instead you do want to be able to proxy other applications you
need to also supply a pgtUrl to your validation request so that CAS can
callback with the Proxy Granting Ticket. This is where life gets
complicated, especially if you forget that service tickets are
one-time-only tickets and that once you've used them with
serviceValidate, you have to go back to CAS and get a new one (so if
you've done Step One and Step Two (a) you'll need to do Step One again
before you can do Step Two (b)).

The choice of pgtUrl here is fairly arbitrary except that it needs
to be an https url and it needs to be on a server on which you can
access the log files.

https://foo.bar.com/is/cas/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS

&service=http://localhost/bling&pgtUrl=https://foo.bar.com/pgtCallback


 

results in:

<cas:serviceResponse xmlns:cas

='http://www.yale.edu/tp/cas'>




<cas:authenticationSuccess>




<cas:user>

endjs</cas:user>




<cas:proxyGrantingTicket>

PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td</cas:proxyGrantingTicket>




</cas:authenticationSuccess>




</cas:serviceResponse>

Step Three: dig out the PGT

Now our first application knows who the user is and has a Proxy
Granting Ticket IOU. To find the real PGT we look in the apache access
log for foo.bar.com and hunt out the request made by CAS to deliver the
PGT:

foo.bar.com - - [10/Dec/2003:09:28:15 +0000] "GET


/pgtCallback?pgtIou=PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td


&pgtId=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS HTTP/1.1" 200 13079

(Editor's note: linebreaks introduced for page formatting.)

Step Four: get a proxy ticket

With the PGT in our grasp we can make a call on CAS to give us a proxy ticket for some other service we wish to proxy:

https://foo.bar.com/is/cas/proxy?targetService=http://localhost/bongo&pgt=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS

resulting in:

<cas:serviceResponse>




<cas:proxySuccess>




<cas:proxyTicket>

PT-957-ZuucXqTZ1YcJw81T3dxf</cas:proxyTicket>




</cas:proxySuccess>




</cas:serviceResponse>

Step Five: verify the proxy ticket

Now we take on our final role for the exercise - the proxied
application. The proxying application has invoked our service url and
has passed in the proxy ticket it's got. We take that ticket and
validate it to find out both who the user is and which applications are
in the proxy chain:

https://foo.bar.com/is/cas/proxyValidate?service=http://localhost/bongo&ticket=PT-957-ZuucXqTZ1YcJw81T3dxf

resulting in:

<cas:serviceResponse xmlns:cas

='http://www.yale.edu/tp/cas'>




<cas:authenticationSuccess>




<cas:user>

endjs</cas:user>




<cas:proxies>




<cas:proxy>

https://foo.bar.com/pgtCallback</cas:proxy>




</cas:proxies>




</cas:authenticationSuccess>




</cas:serviceResponse>

Obviously, this walkthrough doesn't help with acquiring and plugging
in good proxying code for your application but it does help to see what
the proxying code needs to be doing and makes it easier to write your
own.

Originally provided by: David Spencer on the CAS mailing list.

Useful links:

Cas installation:

http://www.ja-sig.org/wiki/display/CASUM/Demo

Java Client:

http://www.ja-sig.org/wiki/display/CASC/Using+the+basic+Java+CAS+Client+objects