The Central Authentication Service (CAS) Shawn Bayern Research programmer, Yale University Author, JSTL in Action, Web Development with JavaServer Pages JSTL implementation lead (JCP, Apache)

Agenda Introduction to CAS Examples of CAS in action N-tier authentication Using CAS with applications like portals and web-based CAS in context CAS at Yale Alternatives to CAS Summary, URLs, Q&A

Introducing CAS What is CAS, what does it offer, and how does it function?

What is CAS? CAS is a single sign-on framework for Web applications Resources that web applications use (e.g., mail servers) Why single sign-on? Convenience and security (unlikely allies) Users have to do less Applications are protected from one another Content aggregation

Aggregating content → Aggregating authentication BeforeAfter

CAS in a nutshell Browser Web application Authenticates without sending password Authenticates via password (once) Determines validity of user’s claimed authentication

Primary benefits of CAS Works with existing authentication infrastructures, such as Kerberos Can be used by nearly any Web-application development environment (JSP, Servlets, ASP, Perl, mod_perl, PHP, Python, PL/SQL, and so forth) — or as a server-wide Apache module Allows "proxy" authentication for Web portals Lets users authenticate securely to untrusted sites (e.g., student-run sites and third-party vendors) without supplying a password directly Is portable (written in Java: Servlets, JSP, and JSTL) Is freely available from Yale (with source code)

How CAS really works Web resource CAS Web browser S C ST ST

CAS requirements CAS uses but does not require JavaScript For consistent, secure redirection HTTP cookies For single sign-on CAS server requires Servlet 2.3, JSP 1.2 container

Side benefits of CAS Users can be asked to avoid supplying password except to trusted site. Expected URL Known “look and feel” Authentic peer certificate (if anyone cares)

Side benefits of CAS Easy way to “reach” users e.g., to require them to change password at regular intervals Centralized maintenance Can change many CAS details without changing client libraries Unified authentication Can manage smart cards, Kerberos, etc. from a single location

CAS examples Low-level and high-level APIs and tools

Example: Low-level API Java Servlet that authenticates users import edu.yale.its.tp.cas.client.ServiceTicketValidator; ServiceTicketValidator sv = new ServiceTicketValidator(); sv.setCasValidateUrl( " sv.setService(“ sv.setServiceTicket(request.getParameter(“ticket”)); sv.validate(); if (sv.isAuthenticationSuccesful()) { System.out.println("user: " + sv.getUser()); // record authentication in HttpSession } Application must manage redirection to CAS itself

Example: Reusable CAS component JSP page to authenticate users Welcome,. If you’ve gotten this far, you are authenticated. Come, make yourself at home. Redirection occurs automatically

Example: Declarative CAS authentication in application server Servlet 2.3 filter to assert requirement for CAS authentication CAS Filter edu.yale.its.tp.cas.client.filter.CASFilter edu.yale.its.tp.cas.client.filter.loginUrl edu.yale.its.tp.cas.client.filter.validateUrl CAS Filter /filtered/* Application simply retrieves username from HttpSession

Example: Declarative CAS authentication in web server mod_cas for Apache 1.x, Apache 2.x Username exposed as CGI environment variable, REMOTE_USER Or… just protect static content mod_cas supports “Require user X,Y,Z” and “Require group” in addition to “Require valid-user” AuthType CAS Require valid-user Server manages authentication. Application simply checks with server.

N-Tier Authentication How can we use CAS in portals, web-based applications, and other scenarios where non- web resources provide secure data?

The goal Portal Web-mail Channel Mail server

The problem Applications can authenticate users securely with CAS. But applications don’t have first-hand knowledge of users’ credentials. This is a good thing... Except that the application can’t impersonate the user in order to acquire secure data for the user.

CAS’s solution: proxiable credentials 1. During validation of ST, an application acquires a proxy-granting ticket (PGT) from CAS 2. When the application needs access to a resource, it uses the PGT to get a proxy ticket (PT) 3. The application sends the PT to a back- end application. 4. The back-end application confirms the PT with CAS, and also gains information about who proxied the authentication.

Proxiable credentials illustrated Web resource CAS ST Non-web resource PGT PT -Username -Identity of web resource

Characteristics of CAS’s solution Back-end applications maintain control over their data For instance, IMAP server may assert, “The only web-based application I trust is Default: no proxies allowed! User logout or timeout destroys subordinate credentials User must be “present” for proxied authentication to occur.

CAS in context How is CAS used at Yale? Are there alternatives to CAS?

CAS at Yale Used by systems in support of students and administrators Used occasionally by unprivileged students Mostly Java and Perl; some ASP Apache module used widely Proxy authentication: incipient deployment PAM module to be used with servers CAS to support uPortal deployment

Characteristics of alternative systems Typically require pre-registration Institution determines security requirements of services. May handle more than just authentication Session management ACLs Identification Principal translation May be platform- or server-specific Passport (Windows) Pubcookie May depend on particular institutional characteristics—e.g., Network topology Service hosting on institutionally managed web servers CAS’s main advantages: simplicity and generality.

Summary CAS… is a free single sign-on framework from Yale works with nearly all back-end authentication subsystems provides secure authentication for both trusted and untrusted applications CAS supports proxied authentication for applications like portals and web-based

URLs CAS distribution site Whitepapers Design Protocol Source distribution License information My address

Q&A Alternative single sign-on systems? CAS implementation questions? Statistics? Comments from schools already using CAS?