Central Authentication Service

Scott Battaglia (Rutgers University)

Andrew Petro (Yale University)

Bill Thompson (Rutgers University)

What is CAS?

CAS isEnterprise level single sign on for the webA trusted sourceA proxy authenticator

History of CAS

CAS 1.0Created by Yale UniversitySimple to use

Protocol was simple yes or no

No proxy authenticaton

History of CAS

CAS 2Also produced by Yale University Introduced Proxy authenticationSimple implementation

Few classes

Extending CAS required modifying source code

History of CAS

CAS 3.0Collaboration between Yale University and

Rutgers UniversityGoal was to make it easy to extend CAS

without modifying core codeCompletely compatible with CAS 2 protocolLeverages tried-and-tested open source

software

Why CAS 3?

CAS 2 was simple to use and understand CAS 3 arguably is more complex, is it

true? Why/why not? Introduce many “best practices” Position CAS for future enhancements Leverage knowledge gained working with

other tools

New in CAS 3

Customizable login flow Pluggable architecture

Ticket StoreAuthentication HandlersMore…

Support for Web Services Support for alternative views

CAS in a nutshell

BrowserWeb application

Authenticateswithout sending password

Authenticates

via password (once)

Determinesvalidity of user’sclaimedauthentication

How CAS Works

Webapplication

CAS

Webbrowser

S

C

T

S T

NetID

CAS Community

Mailing Lists Wiki Issue Tracking Continuous Integration Tools Maven CVS Frappr Non JA-SIG Communities

Mailing Lists

Provide two mailing listsDeveloper

http://tp.its.yale.edu/mailman/listinfo/cas-dev

User http://tp.its.yale.edu/mailman/listinfo/cas

Wiki

Instance of Atlassian Confluencehttps://clearinghouse.ja-sig.org/wiki/spaces/vi

ewspacesummary.action?key=CAS Provides

DocumentationDownloadsetc

Issue Tracking

Instance of Atlassian JIRAhttp://clearinghouse.ja-sig.org/issues

Provides snapshot of project plan Fixed and outstanding bugs

Continuous Integration

Instance of Luntbuildhttp://developer.ja-sig.org/builds/

Download nightly snapshots of CAS

Maven Site

Publishes:Java docsTest ResultsClover reports

Version Control

CVS RepositoryAnonymous checkout of any version of CASObtain latest code (bleeding edge)

Web View via FishEyehttp://developer.ja-sig.org/source/

Frappr http://www.frappr.com/jasigcasdeployers

ESUP Portail

French language CAS community Produce quick starts and common tools French email lists

http://listes.esup-portail.org/wws/lists/cas

Requirements to Deploy CAS

A server and network connection A servlet container supporting Servlet

2.4/JSP 2.0 specification Certificate Java 1.4 or higher CAS 3.0.2

Download CAS

CAS releases are available from the Wiki Available as

ZIPTAR GZ

Starting with 3.0.3, include md5, SHA1 hash

CAS Service Clients

Making your application

use CAS

(compellingly)

How to use CAS

Abstraction Layer

Your Application

CAS

Many CAS Clients

Acegi (for Java web-apps, esp. Spring) AuthCAS (Perl Apache module) PerlCAS phpCAS

Many More CAS Clients

for Prado (a PHP framework) for Seraph (a Java security framework) for uPortal

for WebObjects For Zope

Yale CAS clients

Java Servlet Filter Java Objects JSP tag library

MOD_CAS PAM_CAS ISAPI filter PL/SQL

Many Supported Platforms

Applications distributed CASified

Your Application Goes Here.

BlueSocket (!)

CAS Features for Services

Renew, Gateway,

Proxy authentication

Renew

Opts out of Single Sign On

Advisory on /login (CAS always prompt for credentials)

Security implications on /validate (tells CAS to only succeed validation if credentials were presented)

Gateway

Tells CAS to redirect back without a ticket if one cannot be acquired non-interactively (e.g., via an established SSO session).

Allows you to provide the best user experience possible under the circumstances.

Public Portal

Authenticated Portal

First request to the portal

CASify all requests

Login Screen

But I just wanted the weather…

Needlessly locking public information

Effective use of Gateway

1) Authenticated, personalized content2) Public, generic content3) Login screen

Why am I telling you this?

CAS Server offers a few primitives Upon which you can build compelling user

experiences Renew and Gateway are “advanced” tools

in the toolkit.

Proxying authentication

Another “advanced” tool in the toolkit More on this later.

CAS Clients everywhere…

That was SSO *

Lots of SSO solutions out there CAS is a nice one They all look and work more or less just

like CAS for SSO purposes.

Portal authentication

Portals need to authenticate usersTo provide customized contentTo restrict portal-accessible resources

Portals also need access to third-party resources “as the user”“n-tier” authenticationSingle sign-on

Aggregating content → Aggregating authentication

BeforeAfter

What we will cover

1. How does uPortal authenticate users in the first place?

2. What is the N-tier authentication problem?

3. How does the Yale’s model, called CAS, (Central Authentication Service) solve the problem?

uPortal’s pluggable security-context mechanismAuthentication support in uPortal manifested

through ISecurityContext:

Key functions: Accept IPrincipal Accept IOpaqueCredentials Authenticate user Return true/false (and optionally more)

uPortal’s authentication infrastructure: advantagesFlexibility

Adapts to nearly any back-end campus authentication solution – e.g.,

Kerberos (4, 5) LDAP “authentication” Unix password file (small-scale) Server-based authentication (“trust”)

Supports “chaining” providers to establish more than one context.

ChainingSecurityContext Allows for a chain or a tree of

providers to be called Originally envisioned as acquiring

multiple credentials at sign in For Example:

A database connection or an LDAP initial context or Kerberos TGT

Has not turned out to be the enabling component for single sign on

UnionSecurityContext

Can sit at the top of the tree of chaining providers and present isAuthenticated status and credentials of first provider in the chain to succeed

Portal property determines whether to continue

SimpleProvider(password)

CASProvider

Union Provider

N-tier authentication

Portal

Channel

uPortal’s authentication infrastructure: disadvantages Limitations

Provides unified authentication “gate,” but no extra portal-specific functionality. No single sign-on.

Just a model—does little work itself.But… can be wrenched to cache passwords:

NotSoOpaqueCredentials

String getCredentials();(Not particularly secure)

IOpaqueCredentials

Caching Security Provider

A way to replay passwords by giving channels access to them

Not the best ideaMay expose password to insecure use by channelsParticipating applications have less security than

before If the portal is compromised users’ primary

credentials are compromised

Password caching

Portal

Channel

Channel

Channel

Password-protectedservice

Password-protectedservice

Password-protectedservice

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

Given the drawbacks of caching and re-using passwords, what’s a better approach?

How can a web based Single Sign on System really work?

Web-based single sign-on

Why is this problem different from existing single sign-on systems? Limited client support

Yale’s model is called CAS (Central Authentication Service). Model based (loosely) on Kerberos. “100% Pure Java” Pluggable back-end Available through JA-SIG Clearinghouse Thank you to Shawn Bayern

Other models: Liberty, Pubcookie (Washington), MACE WebISO, Passport

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

Webresource

CAS

Webbrowser

S

C

S T

S T

Back to the N-tier problem

uPortal can authenticate users securely with CAS.

But it does not have first-hand knowledge of users’ credentials.

This is a good thing . . .Except that uPortal can’t impersonate the user

in order to acquire secure data for the user.

CAS’s solution: proxiable credentials1. During validation of ST, an application acquires

a proxy-granting ticket (PGT) from CAS2. 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

IMP CAS

S TIMAP serverCAS PAM

modulePGT

PGT

PT

PT

PT

-Username

-Identity of web resource

CAS Security Provider

Uses CAS for primary authentication Use CAS ProxyTicketReceptor servlet to

receive PGT to be redeemed later Exposes public method to channels to get a

Proxy Service Ticket for a particular service Back end system must be configured to

validate and accept proxy credentials from uPortal

uPortal withCAS Provider

CAS

S T

Channelresource

PGT IOU

PGT

PT

PT

PT-Usernam

e

-Identity of proxy (portal)CAS SecurityContext

Channel

getProxyTicket(pgtIou,service)

CASTicketReceptorServlet

getCasServiceToken

PGT

PT

PT

PT

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.

Extending CAS 3

Clustering Failover Attributes Certificates Events Service Restrictions Web Services

Clustering

Ticket RegistryDistributed Ticket StoreShared Ticket Store

Session ManagementSticky sessionsRemove sessions entirely

Failover

Not handled by CAS directly Content Switch CAS-spare

Attributes

CAS allows attachment of attributes to:PrincipalAuthentication object

Attributes are available to payload Customize payload to return attributes you

need

Automatically Presented Credentials Credentials such as…

Certificates Modify login web flow to place check for

credentials before

Events

Publishes events:AuthenticationTicket creation, destruction, etc.

EventListener captures published events Custom EventHandler to handle events

Service Restrictions

Example in code repository Use to protect CAS from unauthorized

services Uses whitelist

Web Services

Designed that layers are separated Expose layer as multiple types of web

servicesHessianBurlapSOAPHttpInvoker

Future CAS Extensions

SAML response Single Sign Out Administration Summary Screens Expose more configuration options via

JMX What would you like to see?