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 email

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

Before After

CAS in a nutshell

BrowserWeb application

Authenticateswithout sending password

Authenticates

via password (once)

Determinesvalidity of user’sclaimedauthentication

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

Webresource

CAS

Webbrowser

S

C

S T

S T

CAS requirements

CAS uses but does not requireJavaScript

• 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” userse.g., to require them to change

password at regular intervals Centralized maintenance

Can change many CAS details without changing client libraries

Unified authenticationCan 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( "https://secure.its.yale.edu/cas/serviceValidate");sv.setService(“http://my/url”);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

<%@ taglib prefix=“cas” uri=“…” %>

<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>

Redirection

occurs

automatically

Example:Declarative CAS authentication in application server

Servlet 2.3 filter to assert requirement for CAS authentication

<filter> <filter-name>CAS Filter</filter-name> <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name> <param-value>https://secure.its.yale.edu/cas/login</param-value> </init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name> <param-value>https://secure.its.yale.edu/cas/proxyValidate</param-value> </init-param> </filter> <filter-mapping> <filter-name>CAS Filter</filter-name> <url-pattern>/filtered/*</url-pattern> </filter-mapping>

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 CASRequire valid-user

Server manages

authentication.

Application simply

checks with server.

N-Tier Authentication

How can we use CAS in portals, web-based email 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

Webresource CAS

S T

Non-webresource

PGT

PGT

PT

PT

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 email application I trust is https://www.mail.yale.edu/”

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 email 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 email

URLs

CAS distribution sitehttp://www.yale.edu/tp/cas/

• Whitepapers• Design• Protocol

• Source distribution• License information

My email address shawn.bayern@yale.edu

Q&A

Alternative single sign-on systems?

CAS implementation questions?

Statistics?

Comments from schools already using CAS?