Child pages
  • Proxy CAS Walkthrough
Skip to end of metadata
Go to start of metadata

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


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:

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):


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:

which will produce a result like:

<cas:serviceResponse xmlns:cas=''>

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.

results in:

<cas:serviceResponse xmlns:cas=''>

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 and hunt out the request made by CAS to deliver the PGT: - - [10/Dec/2003:09:28:15 +0000] "GET
&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:

resulting in:


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:

resulting in:

<cas:serviceResponse xmlns:cas=''>

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.


As a visual aid Matthew Selwood made a animation of the whole process. Together with the description above this should really help understanding the abobe.


  • No labels


  1. Thanks! It all finally makes sense.

  2. An email comment from Fredrik Norrström:

    The otherwise excellent document,
    could do with a completion. Before the request made by the CAS server to
    deliver a proxy granting ticket (i.e, with the parameters pgtIou and
    pgtId) the server makes an addtional request without any parameters at
    all to which it exepects a 200 Ok success answer. Otherwise the GET
    request with parameters is never attempted. I've been bitten by this
    when implementing CAS proxy ticket support in django-cas.

    It would probably also be good to emphasize that the request to the
    proxy callback URL is only made if it is protected by SSL with a valid
    certificate that the server can verify, including any necessary
    certificate chain. If the server cannot verify the certificate the call
    to the proxy callback url is never attempted and this can only be
    noticed in the CAS server log files.

    I hope someone with update privileges to this document reads this.

    Best regards,

  3. This description provided me a lot of help. But I have to say that integration of CAS and Spring is making me dizzy. From the proxy application (which is CAS enabled with Spring integration) I was able to get a proxy ticket by doing (Java BTW)

    String proxyTicket = authToken.getAssertion().getPrincipal().getProxyTicketFor(testResource);

    The ticket was ST-XXXX instead of PT-XXXX (apparently this is ok for CAS3)

    I used "https://host:port/myAppB/j_spring_cas_security_check" as the testResource above - not at all sure if that is the right URL to use.

    So I have a proxy ticket and now I am stuck.

    I can do a proxyValidate with the URL shown in this writeup (changed for my env) and that returns good XML ftom CAS server.

    But I cannot use this ticket from within Java HTTPClient code (from within the proxy application) to authenticate to myAppB (the proxied app) no matter what I try.

    I am using the URL "testResourceURI + "?ticket=" + proxyTicket + "&spring-security-redirect=https://host:port/myAppB/index.html" as a HttpClient (GET) and that is not working. Most probably my Spring/CAS config is not correct  on myWebAppB (the proxied app). But cant figure out what. I think I am close thanks to this article but missing something at the end.



  4. Well, it worked. On the WebAppB side the security XML was a trial and error case along with some code reading from the spring security and jasig client. Here is what I got - only the relevant portions shown.

    Thanks again to the original poster. I dont think I would have gotten it done without the fine explanation of the moving parts he has provided.

        <bean id="casProcessingFilter">
            <sec:custom-filter after="CAS_PROCESSING_FILTER"/>
            <property name="authenticationManager" ref="authenticationManager"/>
            <property name="authenticationFailureUrl" value="/cas_failed.jsp"/>
            <property name="defaultTargetUrl" value="/"/>
            <property name="proxyGrantingTicketStorage" ref="proxyGrantingTicketStorage"/>
            <property name="proxyReceptorUrl" value="/proxy/receptor"/>

        <bean id="casProcessingFilterEntryPoint">
            <property name="loginUrl" value="https://host slash cas">
            <property name="serviceProperties" ref="serviceProperties"/>

        <bean id="casAuthenticationProvider">
            <sec:custom-authentication-provider />
            <property name="userDetailsService" ref="userService"/>
            <property name="serviceProperties" ref="serviceProperties"/>
            <property name="ticketValidator">
                <bean class="org.jasig.cas.client.validation.Cas20ProxyTicketValidator">
                    <constructor-arg index="0" value="https://host slash cas">
                    <property name="acceptAnyProxy" value="true"/>               
            <property name="key" value="WebAppB"/>

  5. Hi,

    I have written a test class that can be used to test this proxying walkthrough in an automated manner at

    Run on the command line via


    NB: you need to supply a shell script to it that digs out the proxy granting ticket from your proxy server
    since this bit is dependent on the CAS implementation on your proxy

    Typical test response is ...

    CAS Password for user :
    Test ordinary CAS login
    PASS: CAS logged in to
    PASS: logged in to restricted app at http://localhost/bling/admin

    Test proxy CAS login
    PASS: Got IOU - PGTIOU-3198922-gjeDHVt58bT8J7HXPiLakYNQUIpjsfuwtwg3IdNoght0U1OALq for
    PASS: Got PGT - PGT-4323333-Hl9mF9l7wuHnEvOKqfeg5I2arEniWg5uChTNoBetRo8CN8SsXj
    PASS: Got PT - PT-14182564-cOd66BLe0kk3tRM6JuPX
    PASS: Logged in successfully to http://localhost/bling/ via
    Ran 1 test in 4.635s



  6. In slide 5 of the attachment, shouldn’t the proxy client be calling serviceValidate, not proxyValidate? That would be in line with the wiki page. (Slide 8 also mentions ‘Response to /proxyValidate’ which I assume should be ‘Response to /serviceValidate’)

  7. Excellent document! It was very helpful to me. But be aware that the documentation is partly outdated.

    Step three:
    As mentioned in the Javadoc of, CAS 3.0 API returns a ticket granting ticket (TGT) in favor of a proxy granting ticket (PGT)

    Step four:
    A service ticket (ST) is returned in favor of a proxy ticket (PT).

  8. Yes, in hindsight I'm not sure the move to label and treat PT/PGT as ST/TGT was the right one.   Christian is right in that CAS3.x will return tickets labeled TGT/ST that actually are proxy granting tickets and proxy tickets...not just labeled as such.


  9. Great document, however I get an error in Adobe Reader IX when I open and start scrolling down in cas_proxy_protocol.pdf.

    An error exists on this page. Acrobat may not display the page correctly.

    Other than the title on page 1, all other pages appear empty.

  10. Indeed, attached PDF is broken, please fix.