Table of Contents

CAS Protocol

CAS Protocol v1.0 Diagram

Tickets

Common Tickets

Version 2.0 Tickets

CAS URIs

Version 1.0 URIs

Version 2.0 URIs

CAS Protocol

The CAS protocol is an authentication protocol for services that are accessible either directly or indirectly (via
proxy mechanism) via the Web. This document attempts to summarize the technical details of the CAS
protocol. See the official CAS Protocol Specification for more information.

There are two CAS protocol versions, 1.0 (plain text) and 2.0 (XML). The version 2.0 of the protocol supports
proxy tickets which allows one service to access another on behalf of the user without user interaction. This
feature is most commonly used in portal environments where the portal accesses a service on the user's
behalf and presents the data from the 3rd-party service to the user inside the portal.

CAS Protocol v1.0 Diagram

This example uses the specific scenario of an end user accessing a protected resource on the MyVT Web
site for which the underlying authentication mechanism is the VT CAS infrastructure. Although the example
uses services specific to Virginia Tech, the protocol steps are the same as a generic scenario.

PDF Version of CAS Protocol v1.0 Diagram

Tickets

Tickets are the means by which authentication decisions are made in CAS. All tickets begin with a brief
string indicating their purpose followed by a dash and random data, e.g.
LT-35051-7mM70oRxV1AESgrrlCyK. The random portion of tickets have varying requirements on the
strength of their randomness. The proxy-granting ticket and the proxy-granting ticket IOU have the most

1/3
stringent requirements for randomness, while the login ticket need only be “probabilistically unique.―
See *Section 3, CAS Entities* of the official CAS protocol specification for exact details.

Common Tickets

Login Ticket (LT): One-time-use ticket issued by the CAS /login URI to help prevent replay attacks.
Service Ticket (ST): One-time-use ticket issued by the CAS /login URI to be used for service validation _only
for the service for which it was granted_. Ticket length is between 32 and 256 characters.
Ticket-Granting Cookie (TGC): Optional cookie set by the CAS /login URI to facilitate single sign-on. If this
cookie is set, the user does not need to provide primary authentication credentials to access other
CAS-enabled services.

Version 2.0 Tickets

The 2.0 version of the CAS Protocol supports a proxy mechanism by which back-end services are
accessible through front-end services via a proxy mechanism. The length of the proxy client chain is arbitrary,
but is commonly one. The following tickets enable the proxy mechanism.

Proxy Ticket (PT): Issued by CAS upon presentation of a valid proxy-granting ticket for use in accessing a
back-end service from a CAS-enabled service on behalf of a client. Ticket length is between 32 and 256
characters.
Proxy-Granting Ticket (PGT): A multi-use ticket used to obtain proxy tickets. Ticket length is between 64 and
256 characters.
Proxy-Granting Ticket IOU (PGTIOU): Returned in the CAS response from either the /serviceValidate or
/proxyValidate URIs if the service requests and is granted proxy privileges. The PGTIOU is passed between
the proxying service and CAS to access the associated proxy-granting ticket, which in turn allows it to receive
proxy tickets. Ticket length is between 64 and 256 characters.

CAS URIs

CAS URIs are exposed by the CAS server and represent services that CAS clients consume in order to
implement the CAS protocol.

Version 1.0 URIs

/login: Acts as both an authentication credential requestor and acceptor

/validate: Validates service tickets and returns two-line text/plain response.
/logout: Destroys a user's CAS session

Version 2.0 URIs

The /login and /logout URIs function the same as in version 1.0. The /validate URI is augmented by two
additional URIs described below.

/serviceValidate: Validates service tickets and returns a text/xml response. If the service requests a proxy
ticket, the XML response contains information about the status of the proxy ticket request. This URI MUST
NOT perform validation of proxy tickets.
/proxyValidate: Performs validation of both service tickets and proxy tickets and returns a text/xml response
whose schema is the same as the /serviceValidate URI.

2/3
See *Appendix A: CAS response XML schema* of the official CAS Protocol Specification for details on the
structure of XML data returned from the URIs above.

3/3