Any Java examples for the proxy code?

[David Spencer]

--On 09 December 2003 14:57 -0800 "K.C. Baltz" <kc.baltz at lollimail.com> wrote:

> Is no one using the CAS 2.0 proxy code?  I'm not finding the documentation
> very helpful in terms of how to proxy credentials.  I'm looking to have the
> system the user logs into contact another system on the user's behalf using a
> proxy ticket.  I could really use an example.  K.C.

This isn't Java example code I'm afraid but I thought you might find it 
helpful. I was very confused at first with proxying about which bits of 
application were talking to which other bits, when they were talking and what 
funny tokens they were passing round amongst themselves. I found walking 
through the aquisition of proxy tickets with just a browser to make carefully 
constructed requests quite helpful.

A record of what I did is appended below.
Dave

--------------------------------------------------------------------------
Manual walkthrough to aquire CAS proxy tickets.

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

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&s
ervice=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

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&s
ervice=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-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523
Eti2td</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-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2t
d&pgtId=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS HTTP/1.1" 
200 13079

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-3
30-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 aquiring 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.


----------------------
David Spencer
Information Systems and Computing
University of Bristol