450 likes | 640 Views
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
E N D
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
Log in to each application Application A Application B Application C Application E Application F Application D
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 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.
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.
Recent Email Channel CAS NetID ProxyIDs PT PGT S PT Email Servlet uPortal IMAP Server PT XML NetID IMAP session
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 • 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?
Resources • New CAS documentation (Wiki) • Active mailing list • The larger CAS community
Contact information • http://www.yale.edu/its/tp/ • andrew.petro@yale.edu • drew.mazurek@yale.edu • cas@tp.its.yale.edu