Skip to end of metadata
Go to start of metadata
Table of Contents

New CAS documentation site


CAS documentation has moved over to, starting with CAS version 4.x. The wiki will no longer be maintained. For the most recent version of the documentation, please refer to the aforementioned link.

Applications are users?


Roughly, the useful intent of this capability is to model applications themselves as users, programmatically acquiring service tickets to authenticate to other applications, because those other applications found it expedient to use a CAS client library to accept Service Tickets rather than to rely upon some other technology for application-to-application authentication of requests (such as SSL certificates).

Of course, technically, this feature can be used to present end-user username and password pairs to CAS. There are some serious issues to consider in enabling that, not least of which is that naively implemented the REST endpoint becomes a tremendously convenient target for brute force dictionary attacks on your CAS server.  (Note that the threat of brute-force attacks can be somewhat mitigated by throttling login attempts in your underlying authentication mechanism.  Spring interceptor-based throttling (Throttling Login Attempts) is not applicable to restlets. -is this correct? )

Implement the RESTful CAS API only soberly and with due consideration of what you are doing. (That invitation to sobriety really applies across all things security and authentication.)


Applications need to programmatically access CAS. Generally, proxying works for this. However, there are cases where an application needs to access a resource as itself, in which case proxying doesn't make any sense.

At Rutgers, we've implemented a relatively "heavyweight" SOAP based service via Axis. We're now looking at complementing that with a lightweight resource-driven architecture. This page details that proposed work.

This API works to expose a way to RESTfully obtain a Ticket Granting Ticket resource and then use that to obtain a Service Ticket.


The RESTful API follows the same basic protocol as the original CAS2 protocol, augmented with some additional well-defined resource urls (though the protocol doesn't change so it should be just as secure).

Ticket Granting Ticket

The Ticket Granting Ticket is an exposed resource. It has a unique URI.

Request for a Ticket Granting Ticket Resource

Response for a Ticket Granting Ticket Resource

Successful Response

Unsuccessful Responses

If incorrect credentials are sent, CAS will respond with a 400 Bad Request error (will also respond for missing parameters, etc.). If you send a media type it does not understand, it will send the 415 Unsupported Media Type

Request for a Service Ticket

Response for Service Ticket

Successful Response

Unsuccessful Responses

If parameters are missing, etc. CAS will send a 400 Bad Request. If you send a media type it does not understand, it will send the 415 Unsupported Media Type.

Logout of the Service

To log out, you merely need to delete the ticket.


By default the CAS RESTful API is configured in the restlet-servlet.xml, which contains the routing for the tickets. It also defines the resources that will resolve the URLs. The TicketResource defined by default (which can be extended) accepts username/password.

To turn on the RESTful API, add the following to the web.xml:

Note, that in the above configuration example, we are explicitly versioning the RESTful API, so things would be accessed via /cas/v1/tickets/*, etc.

In the pom.xml file include the following:

Please take note that there might be dependencies on Spring 2.x. Make sure to exclude them.

NOTE: In the 3.5.1  version these are the dependencies for integrating RESTful API cas-server-integration-restlet-3.5.1  (you can find them at this url:

  • cas-server-integration-restlet-3.5.1
  • cglib-nodep 2.1_3
  • com.noelios.restlet.ext.servlet 1.1.1
  • com.noelios.restlet.ext.spring 1.1.1
  • cas.server.core 3.5.1
  • org.restlet 1.1.1
  • org.restlet.ext.spring 1.1.1
  • spring-beans ${spring.version}

An issue caught while integrating all these jar in the the cas-server-webapp 3.5.1 is that the presence of cglib-full-2.0.2.jar ( deployed with cas-server-webapp 3.5.1.war) rises the following error on Tomcat server:

GRAVE: StandardWrapper.Throwable
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'root' defined in ServletContext resource [/WEB-INF/restlet-servlet.xml]: Cannot create inner bean 'org.restlet.ext.spring.SpringFinder#906704' of type [org.restlet.ext.spring.SpringFinder] while setting bean property 'attachments' with key [TypedStringValue: value [/tickets], target type [null]]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.restlet.ext.spring.SpringFinder#906704' defined in ServletContext resource [/WEB-INF/restlet-servlet.xml]: Instantiation of bean failed; nested exception is java.lang.StackOverflowError

Removing this jar from /WEB-INF/lib folder, solves the error.

Python REST Client Example

Python REST Client Example - Spring Security Server


Java REST Client Example

We need a real, working, example, the previous one is useless. Many people are emailing me that it is not working, and I confirm it does not work.

Bash Example

Groovy Example



  • No labels