CAS 2.0 is the version of CAS currently in production at Yale University. CAS 2.0 is backwards compatible with CAS 1.0; it simply introduces new features. Application developers at Yale need only understand the concepts and techniques in the CAS 1.0 paper to integrate with CAS successfully, unless their applications need to proxy credentials (as is the case with portals, web-mail services, and so forth). Unless you develop such applications, you will likely be more interested in the original CAS 1.0 document.
In a multi-tier CAS installation, an agent acting on behalf of a user, but without direct access to the user's cookie cache, may need to convince a third party that it represents the user legitimately. There are two requirements that must be met for any such convincing to be convincing:
The first criterion alone is insufficient because it is undesirable for even a relatively trusted agent to be able to impersonate all users baselessly; the second is likewise inadequate because not every agent in contact with the user is necessarily trusted to represent that user to any given third party. (Indeed, CAS specifically prevents two unrelated services from sharing credentials meaningfully.)
In practice (and in the absense of an explicit user logout), it is not straightforward to determine whether a user is still present and desirous of authenticated services. Thus, we settle on "recent contact" as a basis for assuming the user has given implicit pemission for credentials to be proxied. (Such "permission" is not a blanket license for any proxy agent to impersonate the user to the world; as we'll see, a back-end service must explicitly trust the "proxy path" of a credential.)
(As a side note, since "contact" with a service protected by the Central Authentication Service doesn't necessarily involve any affirmative action on the part of the user, the "contact with service" provision could be dropped, and a simpler requirement of "contact with CAS itself" could be substituted in its place. Under such a model, a proxy could simply authenticate itself to a back-end target service and assert that it acts on behalf of any user who recently authenticated with CAS. However, we prefer a model where CAS -- instead of back-end services -- may authenticate proxy agents. As usual, CAS can centralize authentication procedures, resulting in simpler management and use.)
In this document, we explain an extension to CAS 1.0 that accommodates the two requirements discussed above. When these two requirements have been met, a back-end service may determine (a) what user is being impersonated; (b) who is handling the impersonation. These two determinations allow service to accept proxied credentials selectively.
A few definitions are in order:
Parties involved in a CAS authentication make use of tickets, or opaque strings that prove some assertion to CAS. CAS 2.0 uses the following tickets:
For the purposes of the this document, it's assumed you're familiar with CAS 1.0's underlying processes, which are described in more detail in the ITS Central Authentication Service paper. CAS's basic mechanism can be diagrammed as follows:
In this diagram, the actual protocol implemented by a web application that wishes to use CAS is represented by the thick gray line at the top. In version 1.0, the protocol works as follows:
Request: The web application sends an HTTP request with two query parameters: ticket and service, representing respectively an ST and the unique identifier (URL) corresponding to the web application.
Response: CAS responds with a message in one of two formats: "no\n" or "yes\nnetid", where NetID is the authentic NetID of the user.
In recognition of XML's increasing popularity, CAS 2.0 supplements this existing protocol with an existing and optionally available one. The format of the request is the same as above, but the response takes the following format:
Response: CAS response with an XML document whose root element is <cas:serviceResponse>. On failure, the document node contains a single subelement:<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationFailure code="..."> Optional authentication failure message </cas:authenticationFailure> </cas:serviceResponse>
On success, the document node contains a subelement with its own marked-up content:<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>NetID</cas:user> </cas:authenticationSuccess> </cas:serviceResponse>
In addition to this core validation protocol, CAS 2.0 provides an additional protocol available to any web applications that wish to use it. As before, the format of the request is the same, but the response, on success, contains an extra element providing new information:
<cas:serviceResponse> <cas:authenticationSuccess> <cas:user>NetID</cas:user> <cas:proxyGrantingTicket>PGTIOU</cas:proxyGrantingTicket> </cas:authenticationSuccess> </cas:serviceResponse>
The proxyGrantingTicket element contains as its body content information identifying the PGT to be sent to the web application, essentially a PGT "IOU". This value is not the typical opaque identifier for the actual PGT; it is simply a unique value that indexes this PGT. Synchronously, CAS must send the PGT's actual (opaque) value as a request parameter to a URL owned by the application (and identified by the request parameter proxyCallbackUrl in the validation request to CAS). The callback request contains two query parameters: pgtId, containing the actual value representing the PGT, and pgtIou, containing the PGTIOU contained in CAS's response to the web application's request.
(This indirection is necessary to let CAS validate the service using its server certificate, which was deemed the simplest way to provide for mutual authentication, in the field, of services. Custom certificates, and locally shared secrets, are other options, but both were deemed less convenient.
Once this PGT has been received and matched appropriately by the web application, it enables a new protocol (exposed to web applications) that allows the retrieval of specific-use proxy tickets (PTs), also defined earlier:
Request: The web application sends an HTTP request with two query parameters: pgt and targetService, representing respectively a PGT and the unique identifier (URL) corresponding to the target web application to which the present web application (i.e., the proxy) wishes to gain access.
Response: A cas:proxyFailure message can be returned here for invalid or expired PGTs. On success, a message of the following format is sent by CAS to the application:<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:proxySuccess> <cas:proxyTicket>PT</cas:proxyTicket> </cas:proxySuccess> </cas:serviceResponse>
This PT may then be sent by the application to the target service, which validates it with CAS using the following protocol.
Request: (Same as above, for a "regular" service.)
Response: As before, authenticationFailure is an option here. On success, a message with the following form is returned:<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>NetID</cas:user> <cas:proxyGrantingTicket>PGTIOU</cas:proxyGrantingTicket> <cas:proxies> <cas:proxy>proxy1</cas:proxy> <cas:proxy>proxy2</cas:proxy> <cas:proxy>proxy3</cas:proxy> ... </cas:proxies> </cas:authenticationSuccess> </cas:serviceResponse>
The target service may then make any access-control decisions it needs to make, based both on the username and the proxy "path" conveyed by the response from CAS.
As the general format of this latest response message suggests, proxies may be "chained" -- that is, applied successively -- before an ultimate target is reached. This chaining is achieved by the added PGTIOU to this recent message -- when target services implement the "proxy granting" protocol. Thus, a target service may act as a proxy as well.
In addition to proxiable credentials, CAS 2.0 introduces a few new features to the base CAS design:
Restrictions and other changes include the following: