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 Architecture 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 agent must establish its own identity
- The agent must demonstrate that it has been in contact with the user "recently."
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.
|
Player
|
Role
|
| CAS = The Central Authentication Service |
a trusted arbiter of authenticity |
| Service |
A web application that authenticates users via CAS. |
| Proxy |
A service that wants to access other services on behalf of a particular user. |
| Target (or back-end service) |
A service that accepts proxied credentials from at least one particular proxy. |
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:
|
Ticket type
|
description
|
| Ticket-granting cookie (TGC) |
A ticket encapulated by a cookie that is sent to the user's web browser and returned only to CAS, and only over a secured channel. This (optional) ticket establishes the user's identity with CAS and lets CAS act as a single sign-on system for the web. |
| Service ticket (ST) |
A ticket sent by CAS, through the user's browser, to a service. Each ST may be used only once, and must be combined with the unique identifier for one specific service in order to be useful. (Put another way, a service that knows its own unique identifier will refuse to accept STs intended for another service. This prevents one service from mounting a "man in the middle" attack against another.) |
| Proxy-granting ticket (PGT) |
A ticket sent by CAS to a service holding a valid ST (but see below). This ticket (associated with an individual service and an individual user) confers the ability to produce proxy tickets (see below) |
| Proxy-granting ticket IOU (PGTIOU) |
A ticket sent by CAS alone in a service validation response, and with a PGT to the callback URL. It is the web application's responsibility to maintain a table to correlate PGTIOUs and PGTs (see below) |
| Proxy ticket (PT) |
A ticket usable by a proxy to access a target by impersonating a single user. The PT carries information about the proxy or proxies attempting to gain access. For targets that are also (second- or higher-level proxies), a PT may be used to obtain a PGT, but this PGT will preserve information about the linear series of proxies that lie between the user and the ultimate target. |
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:
- Users can now choose, from the login page, to be warned before CAS uses its single sign-on capabilities to log them into web applications. This facilitates anonymous web browsing in situations where this is a concern.
- Applications that pass the value true for the request parameter renew when redirecting users to CAS's login page can explicitly choose to opt out of CAS's single sign-on facility. This is appropriate for applications that want to use CAS but want to ensure that the user is still present before displaying sensitive information. Normally, this behavior is simply advisory and does not ensure the user just recently logged in; however, if you pass the value true for the request parameter renew to the URL for service-ticket validation, CAS will fail to authenticate the user unless the service ticket you've passed was the result of a new primary authentication.
- Applications that pass the value true for the request parameter "gateway" when redirecting users to CAS's login page instruct CAS not to conduct a primary authentication. This is useful for applications that want to accept a pre-existing CAS ticket-granting cookie but do not otherwise want to interrupt their own page flow with CAS's login screen. (Such behavior is expected to be transitional.)
- Because of incompatibilities between different browsers, service URLs may not include encoded or bare representations of linefeed, carriage return, or double-quotation-mark characters. If a page in your application uses such characters in query strings, ensure that it is not the first page that requires CAS authentication.