CAS is an acronym for the Central Authentication Service
.
The CAS project has recently moved to JA-SIG.
The Central Authentication Service provides Single Sign on for the web.
What is CAS?
CAS is a simple wire protocol, Java web application server implementation, and collection of clients for various languages, providing Single Sign On (authentication) for the Web. Your insitution runs one CAS server. Your application developers then use CAS client libraries for various languages (Java, Perl, PL/SQL, ...) to "CASify" their web applications, making them able to participate in CAS single sign on.
CAS is widely deployed.
What is "Single Sign On"?
Single sign on is the ability of an end user to authenticate once and then to experience transparent login to each application she visits (does not have to re-present username and password).
With CAS, "Single Sign On" is optional both from the perspective of CASified applications and from the perspective of the end user. Applications can opt out of CAS single sign on, requiring the user to re-present primary credentials to the CAS server. End users can opt into being warned and required to acknowledge before proceeding whenever an otherwise transparent single sign on occurs.
What does it mean to "CASify" an application
To CASify an application is to enable it to participate in CAS single sign on. That is, an end user can log into the application by means of CAS authentication. The Integration confleunce space includes notes about CASifying Sakai. There was a fairly comprehensive high-level Powerpoint on CASifying Sakai [presented at the July 2005 meeting of SEPP Dev at Yale University].
What technologies does CAS require?
On the end user browser side, CAS will take advantage of JavaScript and Cookies to provide an enhanced end user experience but requires neither. Any web browser will do.
On the server side, CAS server version 2.x runs in a JSP 1.2 or better container. Tomcat 4 or 5.x would be just fine. Out of the box, CAS server version 3.x requires a JSP 2.0 container (Tomcat 5.x, e.g.) but it's trivial to backport.
On the CASified application side, the application needs to be able to participate in the CAS wire protocol. There are a number of packaged CAS clients for various languages that make this feasible.
History
CAS started life as a Yale-local web SSO solution. It was, among other things, a response to many web applications needing to collect and validate end user primary credentials (usernames and passwords) against the Kerberos realm. CAS reduced the security risk profile by making it so that only one application (CAS server itself) need handle actual end user primary credentials (usernames and passwords). CAS also provided a convenient mechanism to let entities with a loose affiliation with the University in terms of web application production (outside vendors, student groups) authenticate Yale community members without touching Yale community members' passwords.
CAS version 2.0 introduced proxy ticket functionality, especially useful to portals but with other applications as well.
As of December 2004, CAS server became a JA-SIG project with initial collaboration primarily between Rutgers and Yale. This has resulted in the CAS Server 3.0.0 release and ongoing CAS Server 3.x efforts. CAS Server 3.0 is basically CAS Server 2.0 functionality aggressively refactored to use Spring, Dependency Injection, Maven...
Related Links
