CAS - Central Authentication Service

Introduction

The Central Authentication Service (CAS) was developed here at Yale University between 2000-2002.  In 2003, a release of the server core code was refactored in collaboration with Rutgers University and in 2004 we collectively placed the code in the public domain under the oversight of Jasig (later Apereo).

Using CAS Libraries

The links below should prove useful when developing against the CAS API.

• Getting Started
• CAS Protocol Specification
• CAS Clients (Official via Apereo)
  • .NET
  • Java
  • PHP
  • Apache
• CAS Client (Community Developed)
  • Ruby
  • Node JS (Passport Framework)
  • Grails

Writing and Debugging CAS Client Libraries 

The documentation here is designed to help developers better understand the CAS protocol and potentially write or debug CAS client libraries. This information should not be used to construct web services that programmatically use CAS to establish authentication context without user involvement.  The reason is simple.   Part of the security of CAS is that the CAS web page handles the user’s credentials so that (potentially) compromised applications can’t serve as password capturing trojan horses.  If code were written to drive the interaction with the web page programmatically then that code would have to capture (and potentially store) a user’s credentials.

The Yale CAS servers support the CAS version 1.0 and CAS version 2.0 protocols.  Both are documented below.  Version 2.0 is preferred (as well as more feature rich), but version 1.0 is easier to implement.  The full and comprehensive standard for CAS can be found at this link. Below are a minimum walk through of the version 1.0 and version 2.0 protocols.

CAS Version 1.0 Protocol

The original CAS protocol uses HTML “text/plain” MIME types.  The browser renders a form where credentials are entered.

The following are marshalled as HTTP POST data and FORM URL encoded.  The values are sent to the “/login” CAS service.

If CAS authentication is successful, the CAS server returns a browser redirect to the target service with the service ticket included in the query string as “ticket=<ST>”

Validation by the target service occurs by calling the CAS “/validate” service.  The following is included as HTTP GET querystring encoded data.

Upon successful authentication, the response to “/validate” will be the ASCII text string “yes\n”. If the ticket isn’t valid then the string “no\n” is returned.

CAS Version 2.0 Protocol

The primary enhancement to CAS Version 2.0 is the addition of an XML-based return value to the validation process along with the proxy authentication chain (if present).  (See the above-mentioned protocol specification for a discussion of CAS proxy functionality.).

Version 2.0 validation by the target service occurs by calling the CAS “/serviceValidate” service. In addition to the parameters for “/validate” you may include an optional:

Upon successful authentication, the response to “/serviceValidate” will be an XML production similar to:

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
      <cas:authenticationSuccess>
        <cas:user>username</cas:user>
        <cas:proxyGrantingTicket>PGTIOU-84678-8a9d...</cas:proxyGrantingTicket>
      </cas:authenticationSuccess>
    </cas:serviceResponse>