Central Authentication
Service
Scott Battaglia (Rutgers University)
Andrew Petro (Yale University)
Bill Thompson (Rutgers University)
What is CAS?

CAS is
 Enterprise
level single sign on for the web
 A trusted source
 A proxy authenticator
History of CAS

CAS 1.0
 Created
by Yale University
 Simple to use

Protocol was simple yes or no
 No
proxy authenticaton
History of CAS

CAS 2
 Also
produced by Yale University
 Introduced Proxy authentication
 Simple implementation

Few classes
 Extending
code
CAS required modifying source
History of CAS

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
 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
Store
 Authentication Handlers
 More…
Support for Web Services
 Support for alternative views

CAS in a nutshell
Browser
Web application
How CAS Works
S
Web
application
T
CAS
NetID
S
T
Web
browser
C
CAS Community








Mailing Lists
Wiki
Issue Tracking
Continuous Integration Tools
Maven
CVS
Frappr
Non JA-SIG Communities
Mailing Lists

Provide two mailing lists
 Developer

http://tp.its.yale.edu/mailman/listinfo/cas-dev
 User

http://tp.its.yale.edu/mailman/listinfo/cas
Wiki

Instance of Atlassian Confluence
 https://clearinghouse.ja-
sig.org/wiki/spaces/viewspacesummary.action
?key=CAS

Provides
 Documentation
 Downloads
 etc
Issue Tracking

Instance of Atlassian JIRA
 http://clearinghouse.ja-sig.org/issues
Provides snapshot of project plan
 Fixed and outstanding bugs

Continuous Integration

Instance of Luntbuild
 http://developer.ja-sig.org/builds/

Download nightly snapshots of CAS
Maven Site

Publishes:
 Java
docs
 Test Results
 Clover reports
Version Control

CVS Repository
 Anonymous
checkout of any version of CAS
 Obtain latest code (bleeding edge)

Web View via FishEye
 http://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

 ZIP
 TAR

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
CAS
Your
Application
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)
2)
3)
Authenticated, personalized content
Public, generic content
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 users
 To
provide customized content
 To restrict portal-accessible resources

Portals also need access to third-party
resources “as the user”
 “n-tier”
authentication
 Single sign-on
Aggregating content →
Aggregating authentication
After
Before
What we will cover
1.
2.
3.
How does uPortal 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?
uPortal’s pluggable securitycontext mechanism
Authentication support in uPortal manifested
through ISecurityContext:
 Key
functions:
Accept IPrincipal
 Accept IOpaqueCredentials
 Authenticate user
 Return true/false (and optionally more)

uPortal’s authentication
infrastructure: advantages
Flexibility
 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
Union Provider
Simple
Provider
(password)

CAS
Provider

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
N-tier authentication
Channel
Portal
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:
IOpaqueCredentials
NotSoOpaqueCredentials
(Not particularly secure)
String getCredentials();
Caching Security Provider
A way to replay passwords by giving
channels access to them
 Not the best idea

 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
Passwordprotected
service
PW
PW
Portal
Channel
PW
Passwordprotected
service
PW


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?


Yale’s model is called CAS (Central Authentication
Service). Model based (loosely) on Kerberos.





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
WebISO, Passport
CAS in a nutshell
Browser
Web application
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
S
T
Web
resource
CAS
S
S
T
Web
browser
C
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 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
T
PGT
PT
IMP
CAS
PGT
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

Channel
resource
uPortal with
CAS Provider
PT
Channel
getCasServiceToken
PT
CAS
Security
Context
S
T
PGT IOU
CAS
getProxyTicket(pgtIou,service)
PT
CAS
Ticket
Receptor
Servlet
PGT
PGT
PT
Characteristics of CAS’s
solution

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!

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 Registry
 Distributed
Ticket Store
 Shared Ticket Store

Session Management
 Sticky
sessions
 Remove sessions entirely
Failover
Not handled by CAS directly
 Content Switch
 CAS-spare

Attributes

CAS allows attachment of attributes to:
 Principal
 Authentication
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:
 Authentication
 Ticket
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
services

 Hessian
 Burlap
 SOAP
 HttpInvoker
Future CAS Extensions
SAML response
 Single Sign Out
 Administration Summary Screens
 Expose more configuration options via
JMX
 What would you like to see?
