@@ -12,7 +12,8 @@ There are two core configurable ticketing components:
## Ticket Registry
The deployment environment and technology expertise generally determine the particular `TicketRegistry` component.
A cache-backed implementation is recommended for HA deployments, while the default `DefaultTicketRegistry` in-memory component may be suitable for small deployments.
A cache-backed implementation is recommended for HA deployments, while the default
`DefaultTicketRegistry` in-memory component may be suitable for small deployments.
### Default (In-Memory) Ticket Registry
...
...
@@ -39,7 +40,6 @@ deployments. Components for the following caching technologies are provided:
*[Hazelcast](Hazelcast-Ticket-Registry.html)
*[Ehcache](Ehcache-Ticket-Registry.html)
*[Memcached](Memcached-Ticket-Registry.html)
*[JBoss Cache](JBoss-Cache-Ticket-Registry.html)
#### Secure Cache Replication
A number of cache-based ticket registries support secure replication of ticket data across the wire,
<divclass="alert alert-danger"><strong>Deprecated Module!</strong><p>The JBoss Cache Ticket Registry module is deprecated and will no longer be maintained. Furthermore, the module may be removed in subsequent CAS releases. Please try to use other options provided by the CAS server for your distributed ticket registry needs.</p></div>
JBoss integration is enabled by including the following dependency in the Maven WAR overlay:
The REST protocol allows one to model applications as users, programmatically acquiring service tickets to authenticate to other applications. This means that other applications would be able to use a CAS client to accept Service Tickets rather than to rely upon another technology such as client SSL certificates for application-to-application authentication of requests. This is achieved by exposing a way to RESTfully obtain a Ticket Granting Ticket and then use that to obtain a Service Ticket.
<divclass="alert alert-danger"><strong>Deprecated Module!</strong><p>Note that the instructions in this document refer to a deprecated REST module. Please <ahref='REST-Protocol.html'>use this document instead</a> if you plan to turn on the CAS server's REST API.</p></div>
<divclass="alert alert-warning"><strong>Usage Warning!</strong><p>The REST endpoint may become a tremendously convenient target for brute force dictionary attacks on CAS server. Enable support only soberly and with due consideration of security aspects.</p></div>
#Components
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.
Support is enabled by including the following in your `pom.xml` file:
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 a Service Ticket
###Sample Request
{% highlight bash %}
POST /cas/v1/tickets/{TGT id} HTTP/1.0
service={form encoded parameter for the service url}
{% endhighlight %}
###Sample Response
####Successful Response
{% highlight bash %}
200 OK
ST-1-FFDFHDSJKHSDFJKSDHFJKRUEYREWUIFSD2132
{% endhighlight %}
####Unsuccessful Response
CAS will send a 400 Bad Request. If an incorrect media type is sent, it will send the 415 Unsupported Media Type.
The REST protocol allows one to model applications as users, programmatically acquiring service tickets to authenticate to other applications. This means that other applications would be able to use a CAS client to accept Service Tickets rather than to rely upon another technology such as client SSL certificates for application-to-application authentication of requests. This is achieved by exposing a way to RESTfully obtain a Ticket Granting Ticket and then use that to obtain a Service Ticket.
The REST protocol allows one to model applications as users, programmatically acquiring
service tickets to authenticate to other applications. This means that other applications would be able
to use a CAS client to accept Service Tickets rather than to rely upon another technology such as
client SSL certificates for application-to-application authentication of requests. This is achieved
by exposing a way to RESTfully obtain a Ticket Granting Ticket and then use that to obtain a Service Ticket.
<divclass="alert alert-warning"><strong>Usage Warning!</strong><p>The REST endpoint may become a tremendously convenient target for brute force dictionary attacks on CAS server. Enable support only soberly and with due consideration of security aspects.</p></div>
<divclass="alert alert-info"><strong>Restlet Module</strong><p>If you are looking for the Restlet implementation of the CAS REST API, you will find the instructions <ahref="REST-Protocol-Deprecated.html">here in this document</a>.</p></div>
<divclass="alert alert-warning"><strong>Usage Warning!</strong><p>The REST endpoint may
become a tremendously convenient target for brute force dictionary attacks on CAS server. Enable support
only soberly and with due consideration of security aspects.</p></div>
# Components
By default the CAS REST API is configured to add 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.
By default the CAS REST API is configured to add 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.
Support is enabled by including the following in your `pom.xml` file:
...
...
@@ -27,33 +34,6 @@ Support is enabled by including the following in your `pom.xml` file:
REST support is currently provided internally by the [Spring framework](http://spring.io/guides/gs/rest-service/).
#Configuration
To turn on the protocol, add the following to the `web.xml`:
{% highlight xml %}
<servlet-mapping>
<servlet-name>cas</servlet-name>
<url-pattern>/v1/*</url-pattern>
</servlet-mapping>
{% endhighlight %}
...or delete the `web.xml` in the overlay altogether if there are no other customizations there as this mapping is provided by CAS' webapp module's `web.xml` out of the box.
Please note that if there are local customizations in overlay's `web.xml`, the following `contextConfigLocation``<context-param>` must also be added in order to enable the new REST module: `classpath*:/META-INF/spring/*.xml`. So the entire context-param block would look like this:
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.
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 a Service Ticket
...
...
@@ -97,7 +79,8 @@ service={form encoded parameter for the service url}
ST-1-FFDFHDSJKHSDFJKSDHFJKRUEYREWUIFSD2132
{% endhighlight %}
####Unsuccessful Response
CAS will send a 400 Bad Request. If an incorrect media type is sent, it will send the 415 Unsupported Media Type.
CAS will send a 400 Bad Request. If an incorrect media type is
sent, it will send the 415 Unsupported Media Type.
