The Central Authentication Service CAS Shawn Bayern Research

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

Agenda ¢ ¢ ¢ Introduction to CAS Examples of CAS in action N-tier authentication l ¢ CAS in context l l ¢ Using CAS with applications like portals and web-based email 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 l l ¢ Web applications Resources that web applications use (e. g. , mail servers) Why single sign-on? l Convenience and security (unlikely allies) • Users have to do less • Applications are protected from one another l Content aggregation

Aggregating content → Aggregating authentication Before After

CAS in a nutshell s nce) te ica rd (o nt he sswo t Au pa via Browser Authent icates without sending pass Dete rm valid ines it claim y of user’ s e auth d entic ation word Web application

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 S T Web resource CAS S S T Web browser C

CAS requirements ¢ CAS uses but does not require l Java. Script • For consistent, secure redirection l 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. l l l Expected URL Known “look and feel” Authentic peer certificate (if anyone cares)

Side benefits of CAS ¢ Easy way to “reach” users l ¢ Centralized maintenance l ¢ e. g. , to require them to change password at regular intervals Can change many CAS details without changing client libraries Unified authentication l 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. Service. Ticket. Validator; n atio age ic ppl man A ust ction lf m ire se red AS it to C Service. Ticket. Validator sv = new Service. Ticket. Validator(); sv. set. Cas. Validate. Url( "https: //secure. its. yale. edu/cas/service. Validate"); sv. set. Service(“http: //my/url”); sv. set. Service. Ticket(request. get. Parameter(“ticket”)); sv. validate(); if (sv. is. Authentication. Succesful()) { System. out. println("user: " + sv. get. User()); // record authentication in Http. Session }

Example: Reusable CAS component ¢ JSP page to authenticate users <%@ taglib prefix=“cas” uri=“…” %> n ctio re edi s R ur ly cal occ mati o aut <cas: auth var=“username” scope=“session”/> <p> Welcome, <c: out value=“${username}”/>. If you’ve gotten this far, you are authenticated. Come, make yourself at home. </p>

Example: Declarative CAS authentication in application server ¢ Servlet 2. 3 filter to assert requirement for CAS authentication <filter> <filter-name>CAS Filter</filter-name> on ti <filter-class>edu. yale. its. tp. cas. client. filter. CASFilter</filter-class> lica p <init-param> Ap ply <param-name>edu. yale. its. tp. cas. client. filter. login. Url</param-name> sim ieves e r <param-value>https: //secure. its. yale. edu/cas/login</param-value> ret rnam e </init-param> us ion <init-param> from Sess p <param-name>edu. yale. its. tp. cas. client. filter. validate. Url</param-name> Htt <param-value>https: //secure. its. yale. edu/cas/proxy. Validate</param-value> </init-param> </filter> <filter-mapping> <filter-name>CAS Filter</filter-name> <url-pattern>/filtered/*</url-pattern> </filter-mapping>

Example: Declarative CAS authentication in web server ¢ mod_cas for Apache 1. x, Apache 2. x Auth. Type CAS s age n Require valid-user ma tion. ly er ca p rv Se enti n sim ver. h r o aut licati ith se p Ap cks w l Username exposed as che l 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”

N-Tier Authentication How can we use CAS in portals, web-based email applications, and other scenarios where nonweb 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. . . ¢ l Except that the application can’t impersonate the user in order to acquire secure data for the user.

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

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

Characteristics of CAS’s solution ¢ Back-end applications maintain control over their data l l ¢ For instance, IMAP server may assert, “The only web-based email application I trust is https: //www. mail. yale. edu/” Default: no proxies allowed! User logout or timeout destroys subordinate credentials l 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 l ¢ ¢ ¢ Used occasionally by unprivileged students Mostly Java and Perl; some ASP Apache module used widely Proxy authentication: incipient deployment l l PAM module to be used with email servers CAS to support u. Portal deployment

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

Summary ¢ CAS… l l 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 email

URLs ¢ CAS distribution site l http: //www. yale. edu/tp/cas/ • Whitepapers • Design • Protocol • Source distribution • License information ¢ My email address l shawn. bayern@yale. edu

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