Transcript casJasigWinter2004v2

Central Authentication
Service
Roadmap
JA-SIG Winter 2004
A new CAS Presentation
What is CAS? (Enterprise Single Sign On)
 What’s new with CAS? (new CAS Java
Client)
 What’s using CAS? (Acegi)
 Where is CAS going? (Roadmap)
 Resources?

What is CAS?
Enterprise Web Single-sign-on
 Your users authenticate to CAS



Only CAS sees user passwords
Your applications receive assurance of
authentication from CAS
CAS as Trusted

CAS is the Trusted Intermediary
The Bad Old Days
Log in to each application
Application A
Application B
Application D
Application E
Application C
Application F
Examples

We’re going to walk through two examples
demonstrating CAS’s features.
Example: Network registration
Welcome to Our University Network
Registration.
First, you need to log in:
CAS Login
CAS redirects back to
application

Places ticket=ABCDEFG123 on the
request
Application receives ticket

Validates ticket with CAS server
<cas:serviceResponse
xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>awp9</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
Okay, user is authenticated

Notice: The user didn’t give her password
to the application itself.
CAS Vocabulary
Ticket – it’s longish random String.
 Ticket Granting Ticket / Ticket Granting
Cookie – a CAS session identifier

Service Ticket
 Proxy Granting Ticket
 Proxy Ticket

Example 2: uPortal & SSO

Great, we’ve authenticated. Now let’s visit
our uPortal:
CAS does not display
Reads the secure cookie from the browser
session.
 Single sign on.
 Redirects back to uPortal with the ticket.

uPortal validates the ticket

And requests a Proxy Granting Ticket.
Authenticated to uPortal
Proxying to get my mail
uPortal uses PGT to get PT for mail XML
service, requests mail XML service
 Mail XML service receives PT, validates it,
and gets a PGT.
 Mail XML service gets PT for IMAP server,
presents to IMAP server.
 IMAP server delegates to PAM_CAS to
validate the PT.

The result
Recent Email Channel
CAS
PT
PGT S
IMAP
Server
PT
NetID
IMAP session
Email
Servlet
uPortal
XML
What is CAS?
CAS is web SSO.
 CAS is a concrete (Java Servlets)
implementation.
 CAS is a constellation of client libraries,
including PAM, Apache modules, Java
.jars, php, perl, …

What’s new? CAS Java Client

Version 2.1.0
CASFilter

CAS Java Servlet Filter
Renew and Gateway features
 Optionally set the remoteUser
 Allows multiple authorized proxies

CASReceipt
CASReceipt represents results from CAS
authentication
 Exposed in the session by CASFilter

Filter Composition

Subsequent filters can examine the results
of CAS authentication:

ProxyChainScrutinizerFilter
Commons logging

CAS Java Client 2.1.x
uPortal:
YaleCASFilteredContext

Use CASValidateFilter to accomplish the
actual ticket validation –
YaleCASFilteredContext just consumes
the CASReceipt.
The approach
CASFilter
Additional filtering
Your application
What’s new: Acegi
What’s new: Acegi
Acegi is an authentication/authorization
framework that works well with Spring
 It supports CAS for enterprise single sign
on


A layer of abstraction beyond the CAS
Java Client.
Roadmap

Where is CAS going?
Formalization of CAS protocol
 SAML as the language for CAS requests
and responses
 Interface-rich, more pluggable server
implementation

Formalization of CAS protocol

Before CAS can be re-implemented, we
need a formal specification of exactly what
protocol it implemented the first time.
SAML
CAS 2.0 uses ad-hoc XML. This was
simple, worked well.
 CAS 3.0 will additionally support SAML.
More complex, but more standards
compliant.


CAS as the authentication piece in a
Shibboleth installation.
Assertions
CAS SAML assertions of who logged in
how when
 Attribute assertions
 PGTs are attributes?


Details not yet fully defined
Attribute assertions

Common use case: now that you’ve
authenticated your user, you want some
attributes

SAML language allows us to assert
attributes other than the user name at
ticket validation
SSL callback and client certs
CAS uses an https: callback to
authenticate the service
 Signed SAML requests provide us an
alternative

Interface-rich, more pluggable
Old model: you download CAS and then
hack away at it to make it meet your
needs.
 New model: you plug in local changes at
well-defined extension points

Load Balancing CAS

Why not to do this
Default: ticket store backed by in-memory
cache
 Possible: ticket store backed by RDBMS
 Possible: ticket store backed by [pick your
favorite cache implementation]

Whitelisting services

Why not to do this

Possible: impose whitelist at ticket
validation layer
Authentication itself

CAS PasswordHandlers

CasGenericHandler – more ad-hoc XML
confguration

Instead wire together using Spring
“Single Sign Out”

Why not to do this

But if we’re going to do this, let’s at least
make it easier to maintain the local mod

Or maybe an optional aspect of the
protocol – standardize without requiring
Extension points?

Others?
Rutgers and their fine work
Resources
New CAS documentation (Wiki)
 Active mailing list


The larger CAS community
Contact information
http://www.yale.edu/its/tp/
 [email protected]


[email protected]

[email protected]