Central Authentication Service Scott Battaglia Rutgers University Andrew

Central Authentication Service Scott Battaglia (Rutgers University) Andrew Petro (Yale University) Bill Thompson (Rutgers University)

What is CAS? n CAS is ¨ Enterprise level single sign on for the web ¨ A trusted source ¨ A proxy authenticator

History of CAS n CAS 1. 0 ¨ Created by Yale University ¨ Simple to use n Protocol was simple yes or no ¨ No proxy authenticaton

History of CAS n CAS 2 ¨ Also produced by Yale University ¨ Introduced Proxy authentication ¨ Simplementation n Few classes ¨ Extending code CAS required modifying source

History of CAS n CAS 3. 0 ¨ Collaboration between Yale University and Rutgers University ¨ Goal was to make it easy to extend CAS without modifying core code ¨ Completely compatible with CAS 2 protocol ¨ Leverages tried-and-tested open source software

Why CAS 3? CAS 2 was simple to use and understand n CAS 3 arguably is more complex, is it true? Why/why not? n Introduce many “best practices” n Position CAS for future enhancements n Leverage knowledge gained working with other tools n

New in CAS 3 Customizable login flow n Pluggable architecture n ¨ Ticket Store ¨ Authentication Handlers ¨ More… Support for Web Services n Support for alternative views n

CAS in a nutshell s nce) te ica rd (o nt he sswo t Au pa via Browser Authent icates without sending pass Dete rm valid ines it claim y of user’ s e auth d entic ation word Web application

How CAS Works S Web application T CAS Net. ID S T Web browser C

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

Mailing Lists n Provide two mailing lists ¨ Developer n http: //tp. its. yale. edu/mailman/listinfo/cas-dev ¨ User n http: //tp. its. yale. edu/mailman/listinfo/cas

Wiki n Instance of Atlassian Confluence ¨ https: //clearinghouse. ja- sig. org/wiki/spaces/viewspacesummary. action ? key=CAS n Provides ¨ Documentation ¨ Downloads ¨ etc

Issue Tracking n Instance of Atlassian JIRA ¨ http: //clearinghouse. ja-sig. org/issues Provides snapshot of project plan n Fixed and outstanding bugs n

Continuous Integration n Instance of Luntbuild ¨ http: //developer. ja-sig. org/builds/ n Download nightly snapshots of CAS

Maven Site n Publishes: ¨ Java docs ¨ Test Results ¨ Clover reports

Version Control n CVS Repository ¨ Anonymous checkout of any version of CAS ¨ Obtain latest code (bleeding edge) n Web View via Fish. Eye ¨ http: //developer. ja-sig. org/source/

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

ESUP Portail French language CAS community n Produce quick starts and common tools n French email lists n ¨ http: //listes. esup-portail. org/wws/lists/cas

Requirements to Deploy CAS A server and network connection n A servlet container supporting Servlet 2. 4/JSP 2. 0 specification n Certificate n Java 1. 4 or higher n CAS 3. 0. 2 n

Download CAS releases are available from the Wiki n Available as n ¨ ZIP ¨ TAR n GZ Starting with 3. 0. 3, include md 5, SHA 1 hash

CAS Service Clients Making your application use CAS (compellingly)

How to use CAS Abstraction Layer CAS Your Application

Many CAS Clients Acegi (for Java web-apps, esp. Spring) n Auth. CAS (Perl Apache module) n Perl. CAS n php. CAS n

Many More CAS Clients for Prado (a PHP framework) n for Seraph (a Java security framework) n for u. Portal n for Web. Objects n For Zope n

Yale CAS clients Java Servlet Filter n Java Objects n JSP tag library n MOD_CAS n PAM_CAS n ISAPI filter n PL/SQL n

Many Supported Platforms

Applications distributed CASified Your Application Goes Here. Blue. Socket (!)

CAS Features for Services Renew, Gateway, Proxy authentication

Renew n Opts out of Single Sign On n Advisory on /login (CAS always prompt for credentials) n 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). n Allows you to provide the best user experience possible under the circumstances. n

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) 2) 3) Authenticated, personalized content Public, generic content Login screen

Why am I telling you this? CAS Server offers a few primitives n Upon which you can build compelling user experiences n Renew and Gateway are “advanced” tools in the toolkit. n

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

CAS Clients everywhere…

That was SSO * Lots of SSO solutions out there n CAS is a nice one n They all look and work more or less just like CAS for SSO purposes. n

Portal authentication n Portals need to authenticate users ¨ To provide customized content ¨ To restrict portal-accessible resources n Portals also need access to third-party resources “as the user” ¨ “n-tier” authentication ¨ Single sign-on

Aggregating content → Aggregating authentication Before After

What we will cover 1. 2. 3. How does u. Portal authenticate users in the first place? What is the N-tier authentication problem? How does the Yale’s model, called CAS, (Central Authentication Service) solve the problem?

u. Portal’s pluggable securitycontext mechanism Authentication support in u. Portal manifested through ISecurity. Context: ¨ Key functions: Accept IPrincipal n Accept IOpaque. Credentials n Authenticate user n Return true/false (and optionally more) n

u. Portal’s authentication infrastructure: advantages Flexibility ¨ Adapts to nearly any back-end campus authentication solution – e. g. , Kerberos (4, 5) n LDAP “authentication” n Unix password file (small-scale) n Server-based authentication (“trust”) n ¨ Supports “chaining” providers to establish more than one context.

Chaining. Security. Context n n n 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 n Has not turned out to be the enabling component for single sign on

Union. Security. Context Union Provider Simple Provider (password) n CAS Provider n Can sit at the top of the tree of chaining providers and present is. Authenticated status and credentials of first provider in the chain to succeed Portal property determines whether to continue

N-tier authentication Channel Portal

u. Portal’s authentication infrastructure: disadvantages n 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: IOpaque. Credentials Not. So. Opaque. Credentials (Not particularly secure) String get. Credentials();

Caching Security Provider A way to replay passwords by giving channels access to them n Not the best idea n ¨ May expose password to insecure use by channels ¨ Participating applications have less security than before ¨ If the portal is compromised users’ primary credentials are compromised

Password caching PW PW PW Passwordprotected service PW Channel PW PW PW Channel PW Portal Channel PW Passwordprotected service PW

n n 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 n Why is this problem different from existing single sign-on systems? ¨ n Yale’s model is called CAS (Central Authentication Service). Model based (loosely) on Kerberos. ¨ ¨ n Limited client support “ 100% Pure Java” Pluggable back-end Available through JA-SIG Clearinghouse Thank you to Shawn Bayern Other models: Liberty, Pubcookie (Washington), MACE Web. ISO, Passport

CAS in a nutshell s nce) te ica rd (o nt he sswo t Au pa via Browser Authent icates without sending pass Dete rm valid ines it claim y of user’ s e auth d entic ation word Web application

Primary benefits of CAS n n n 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 S T Web resource CAS S S T Web browser C

Back to the N-tier problem u. Portal can authenticate users securely with CAS. n But it does not have first-hand knowledge of users’ credentials. n This is a good thing. . . n ¨ Except that u. Portal can’t impersonate the user in order to acquire secure data for the user.

CAS’s solution: proxiable credentials 1. 2. 3. 4. During validation of ST, an application acquires a proxy-granting ticket (PGT) from CAS When the application needs access to a resource, it uses the PGT to get a proxy ticket (PT) The application sends the PT to a back-end application. The back-end application confirms the PT with CAS, and also gains information about who proxied the authentication.

Proxiable credentials illustrated IMAP server CAS PAM module S PT T PGT IMP CAS PGT PT PT -Username -Identity of web resource

CAS Security Provider Uses CAS for primary authentication n Use CAS Proxy. Ticket. Receptor servlet to receive PGT to be redeemed later n Exposes public method to channels to get a Proxy Service Ticket for a particular service n Back end system must be configured to validate and accept proxy credentials from u. Portal n

e rox am f p rn o se tity -U en Channel T l) ta PT or PGT IOU CAS get. Proxy. Ticket(pgt. Iou, service) CAS Ticket Receptor Servlet (p CAS Security Context S y get. Cas. Service. Token PT -Id PT PT PT u. Portal with CAS Provider Channel resource PGT PT

Characteristics of CAS’s solution n Back-end applications maintain control over their data ¨ For instance, IMAP server may assert, “The only webbased email application I trust is https: //www. mail. yale. edu/” ¨ Default: no proxies allowed! n 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 n Ticket Registry ¨ Distributed Ticket Store ¨ Shared Ticket Store n Session Management ¨ Sticky sessions ¨ Remove sessions entirely

Failover Not handled by CAS directly n Content Switch n CAS-spare n

Attributes n CAS allows attachment of attributes to: ¨ Principal ¨ Authentication object Attributes are available to payload n Customize payload to return attributes you need n

Automatically Presented Credentials n Credentials such as… ¨ Certificates n Modify login web flow to place check for credentials before

Events n Publishes events: ¨ Authentication ¨ Ticket creation, destruction, etc. Event. Listener captures published events n Custom Event. Handler to handle events n

Service Restrictions Example in code repository n Use to protect CAS from unauthorized services n Uses whitelist n

Web Services Designed that layers are separated n Expose layer as multiple types of web services n ¨ Hessian ¨ Burlap ¨ SOAP ¨ Http. Invoker

Future CAS Extensions SAML response n Single Sign Out n Administration Summary Screens n Expose more configuration options via JMX n What would you like to see? n