Central Authentication Service

1
Central Authentication Service

• Roadmap
• JA-SIG Winter 2004

2
A new CAS Presentation

• What is CAS? (Enterprise Single Sign On)
• Whats new with CAS? (new CAS Java Client)
• Whats using CAS? (Acegi)
• Where is CAS going? (Roadmap)
• Resources?

3
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

4
CAS as Trusted

• CAS is the Trusted Intermediary

5
The Bad Old Days
6
Log in to each application
Application A
Application B
Application C
Application E
Application F
Application D
7
Examples

• Were going to walk through two examples
  demonstrating CASs features.

8
Example Network registration

• Welcome to Our University Network Registration.
• First, you need to log in

9
CAS Login
10
CAS redirects back to application

• Places ticketABCDEFG123 on the request

11
Application receives ticket

• Validates ticket with CAS server
• ltcasserviceResponse xmlnscas'http//www.yale.ed
  u/tp/cas'gt ltcasauthenticationSuccessgt
  ltcasusergtawp9lt/casusergt lt/casauthenticationSucc
  essgt
• lt/casserviceResponsegt

12
Okay, user is authenticated

• Notice The user didnt give her password to the
  application itself.

13
CAS Vocabulary

• Ticket its longish random String.
• Ticket Granting Ticket / Ticket Granting Cookie
  a CAS session identifier
• Service Ticket
• Proxy Granting Ticket
• Proxy Ticket

14
Example 2 uPortal SSO

• Great, weve authenticated. Now lets visit our
  uPortal

15
CAS does not display

• Reads the secure cookie from the browser session.
• Single sign on.
• Redirects back to uPortal with the ticket.

16
uPortal validates the ticket

• And requests a Proxy Granting Ticket.

17
Authenticated to uPortal
18
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.

19
The result
20
Recent Email Channel
CAS
NetID
ProxyIDs
PT
PGT
S
PT
Email Servlet
uPortal
IMAP Server
PT
XML
NetID
IMAP session
21
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,

22
Whats new? CAS Java Client

• Version 2.1.0

23
CASFilter

• CAS Java Servlet Filter
• Renew and Gateway features
• Optionally set the remoteUser
• Allows multiple authorized proxies

24
CASReceipt

• CASReceipt represents results from CAS
  authentication
• Exposed in the session by CASFilter

25
Filter Composition

• Subsequent filters can examine the results of CAS
  authentication
• ProxyChainScrutinizerFilter

26
Commons logging

• CAS Java Client 2.1.x

27
uPortal YaleCASFilteredContext

• Use CASValidateFilter to accomplish the actual
  ticket validation YaleCASFilteredContext just
  consumes the CASReceipt.

28
The approach
CASFilter
Additional filtering
Your application
29
Whats new Acegi
30
Whats 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.

31
Roadmap

• Where is CAS going?
• Formalization of CAS protocol
• SAML as the language for CAS requests and
  responses
• Interface-rich, more pluggable server
  implementation

32
Formalization of CAS protocol

• Before CAS can be re-implemented, we need a
  formal specification of exactly what protocol it
  implemented the first time.

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

34
Assertions

• CAS SAML assertions of who logged in how when
• Attribute assertions
• PGTs are attributes?
• Details not yet fully defined

35
Attribute assertions

• Common use case now that youve authenticated
  your user, you want some attributes
• SAML language allows us to assert attributes
  other than the user name at ticket validation

36
SSL callback and client certs

• CAS uses an https callback to authenticate the
  service
• Signed SAML requests provide us an alternative

37
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

38
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

39
Whitelisting services

• Why not to do this
• Possible impose whitelist at ticket validation
  layer

40
Authentication itself

• CAS PasswordHandlers
• CasGenericHandler more ad-hoc XML confguration
• Instead wire together using Spring

41
Single Sign Out

• Why not to do this
• But if were going to do this, lets at least
  make it easier to maintain the local mod
• Or maybe an optional aspect of the protocol
  standardize without requiring

42
Extension points?

• Others?

43
Rutgers and their fine work
44
Resources

• New CAS documentation (Wiki)
• Active mailing list
• The larger CAS community

45
Contact information

• http//www.yale.edu/its/tp/
• andrew.petro_at_yale.edu
• drew.mazurek_at_yale.edu
• cas_at_tp.its.yale.edu