Central Authentication Service

1
Central Authentication Service (CAS)
Brian Donnelly University of California,
Davis June 21, 2007
2
What is CAS?

• Enterprise level single sign on for the web
• Your users authenticate to CAS
• Only CAS sees user passwords
• Your applications receive assurance of
  authentication from CAS
• A source of authenticated identity

3
JA-SIG CAS

• The JA-SIG Central Authentication Service was
  originally developed by Yale University. It has
  since become a JA-SIG project.
• JA-SIG supports and distributes a Java CAS server
  and client.
• Other client modules are developed and supported
  by the user community.

4
Technical Specifications

• Servlet-based Java application
• Tomcat 4.x (Tomcat 5.x recommended)
• Platform-independent (Linux, Windows, OSX, nix)
• No Database component
• Large in-memory ticket caches
• Client modules exist for many web servers and
  applications

5
CAS Timeline
2002
CAS 1.0 Initial Yale Deployment
CAS 2.0 JA-SIG Ownership, Proxy
Authentication
2004
CAS 3.0 Architectural Improvements,
Clustering
2006
CAS 3.1 Administrative Interfaces and
New Features
2007
6
CAS Cluster
CAS Authentication Walk-Through
MyUCDavis Portal
7
CAS Cluster
MyUCDavis Portal
8
Service ID / URL
S
CAS Cluster
TGT
ST
MyUCDavis Portal
9
Service ID / URL
S
CAS Cluster
TGT
TGT
ST
TGT
MyUCDavis Portal
10
Service ID / URL
S
Ticket Granting Ticket (Cookie)
TGT
CAS Cluster
Service Ticket
ST
TGT
TGT
ST
TGT
MyUCDavis Portal
11
The CAS Security Model

• User names and passwords never exposed to clients
  or client applications.
• Only opaque tickets are passed through the users
  web browser.
• Authenticated identity is provided via a secure
  server-to-server communication channel.

12
CAS Security Model (cont.)

• Tickets used for authentication are subject to
  configurable time and use expiration policies.
• Per-service authentication tickets ensure that
  client applications cannot undermine the security
  of the system.
• Once authentication is performed, it becomes the
  client application's responsibility to store and
  protect the authenticated identity.

13
Security Attacks

• Cookie / Ticket Replay
• Ticket Granting Ticket (TGT) is a persistent
  cookie
• Service Tickets (ST) are passed via URL parameter
• Mitigated by TGT Timeout and Reuse settings
• Phishing
• Login is a web page and can be impersonated
• Our CAS pages have a Geotrust Siteseal

14
Security Attacks (cont.)

• Eavesdropping
• SSL used for all communications
• Ticket values are randomly-generated strings
• Browser Caching
• CAS currently does not support Single Sign Out
  (SSO)
• Exposed Credentials
• No way to protect the service once the attacker
  knows a User name / Password

15
Why CAS?

• Robust SSO system in use by over 50 Universities
  and Corporations.
• Mature open-source product in active development.
• Client Modules are actively developed and
  supported by the CAS community.
• Greatly reduced cross-traffic between SSO system
  and protected web application.

16
Why CAS? (cont.)

• Configurable authentication work-flow allows for
  custom authentication modules
• X509 Certificates, RADIUS, SPNEGO
• Common authentication backends supported
• Kerberos, LDAP
• Provides fall-through authentication for
  credentials.

17
Upcoming CAS Features

• 3.1
• Single Sign Out
• SAML Support
• SecurID (RSA Hard Token) Support
• Service Restrictions
• Password Management
• Administration Interfaces
• 3.1
• Multi-factor authentication

18
Single Sign Out

• In the current CAS framework, clients are
  responsible for storing authentication
  information.
• What happens when you sign out of CAS?
• To support SSO, a callback mechanism is being
  created.
• Each CAS Client module must be updated to support
  the SSO Callback.

19
SAML

• Security Assertion Markup Language (SAML)
• XML-based syntax for the exhange of
  authentication information.
• CAS 3.0 is already XML-based so will require
  little work.

20
SecurID Support

• RSA SecurID is token based security
• Tokens may be hardware or software
• New authentication codes are generated every 60
  seconds
• Interesting feature Supports duress PIN

21
Service Restrictions

• CAS enhancement creates a Service Manager
  Adminstrative tool
• Allows for enabling/disabling authentication
  access for services (service ids)
• Supports service grouping
• Provides per service configurable attribute
  policies

22
Password Managment

• Part of CAS Account Management add on module
• Provides ability to set password expiration
  conditions
• Password reset includes configurable strength
  rules

23
Multi-Factor Authentication

• Long term goal for CAS implementation
• Allows multiple authentication workflows to be
  created
• Each workflow can contain one of more
  authentication modules / credentials
• Services can request a particular workflow when
  redirecting for authentication

24
Proxy Authentication

• Allows a web application to get authenticated
  user data from another application.
• Removes the user's browser from the transaction.
• Commonly used in Portal applications to display
  personal information (email, etc.).
• Requires a trust relationship between the
  applications.

25
CAS Cluster
TGT
ST
Cyrus Mail Server
MyUCDavis Portal
PGT
26
CAS Cluster
TGT
PT
Cyrus Mail Server
MyUCDavis Portal
PGT
PGT
27
CAS Proxy Requirements

• CAS Server
• CAS-Protected Web Application
• Proxy data consumer
• Web service implementing CAS proxy authentication
  client protocol
• Proxy data provider
• PAM_CAS Module

28
CAS Client Types

• CAS Clients generally fall into two types
• HTTP / URL Filters
• Inspect incoming http traffic for protected
  resources
• Invokes the CAS Client code and stores successful
  authentications
• Authentication Functions
• Provide a set of exposed functions/methods to
  directly invoke the CAS Client code
• The invoking application must handle and store
  the authenticated ID

29
Protecting Common Web Applications with CAS

• Web Servers
• Apache
• Multiple modules are available for Apache 1.x and
  2.x
• ESUP-Portail's MOD_CAS recommended for all Apache
  installations
• IIS
• Currently no community-supported modules exist
  for IIS
• Locally Developed .NET and ISAPI Modules

30
Common Web Applications with CAS (cont.)

• Web Servers (cont.)
• Tomcat
• Ja-Sig Supported module
• Acegi Support

• Web Applications
• PHP
• ASP.NET
• ColdFusion
• Perl
• Ruby on Rails
• Zope
• WebObjects

31
Client Deployment Example

• CAS Apache Client
• Configured at the Apache Directory security level
• Any requests to pages within the protected
  directory will be subjected to the CAS
  authentication code
• ESUP-Portail's MOD_CAS client will be used
• It is a C-code client and must be built on the
  web server
• In our testing, this module has worked reliably
  on Apache 1.x and 2.x
• Our example is based on a RHEL 4 installation

32
Aquiring and Building

• Download from
• http//esup-portail.org/consortium/espace/download
  /Mod_cas/
• Ensure that httpd-devel and openssl-devel are
  installed
• Build using apxs

gt tar zxf Mod_cas-2.0.11-esup-2.tar.gz gt cd
Mod_cas-2.0.11-esup-2/sources gt /usr/sbin/apxs -i
-c mod_cas.c ssl_client.c
33
Installation

• Assuming Apache modules are located in
• /usr/lib/httpd/modules/
• Output file from apxs build is mod_cas.so

cd .libs sudo cp mod_cas.so /usr/lib/httpd/modules
/
34
Configure

• Create /etc/httpd/conf.d/mod_cas.conf

LoadModule cas_module modules/mod_cas.so ltIfModul
e mod_cas.cgt CASLocalCacheInsecure On
CASLocalCacheFile /tmp/CAScache
CASLocalCacheSize 1000 CASLocalCacheTimeout
3600 CASTrustedCACert /etc/pki/tls/cert.pem
CASLoginURL https//cas.ucdavis.edu8443/cas/log
in CASHost cas.ucdavis.edu CASPort 8443
CASValidate /cas/validate CASDebug
on lt/IfModulegt
35
Configure (cont.)

• mod_cas.conf continued...

ltDirectory "/var/www/html/secure"gt
DirectoryIndex index.shtml index.html
AddHandler server-parsed .shtml Options
IncludesNoExec ltIfModule mod_cas.cgt
AuthType CAS AuthName "UC Davis" Require
valid-user lt/IfModulegt lt/Directorygt
36
Test!

• Navigate to any page in http//localhost/secure
• CAS Authentication will be enforced
• REMOTE_USER populated with authenticated user id

37
CAS at UC Davis

• Eventual replacement for aging SSO system
• Distauth SSO system has dependency on AFS
• Client modules must be locally maintained
• Pre-built modules for new Web Applications
• Sakai
• Confluence/Jira
• Outlook Web Access

38
CAS at UC Davis (cont.)

• Configurable authentication workflow well suited
  to new authentication factors.
• RADIUS
• SPNEGO

39
UCD CAS Configuration

• Current
• CAS Version 3.0.6
• Distauth Client Authentication module
• Custom UC-Davis Skin

• Summer Upgrade
• CAS Version 3.1
• JBossCache Clustering
• New Skin

40
UCD CAS Roadmap

• Future Projects
• Single Sign Out (dependent on CAS 3.1)
• Wireless RADIUS Authentication Passthrough
• SPNEGO Windows Domain Login Passthrough

41
UCD CAS Installation

• Current
• Primary CAS Server with Hot Spare
• Service Monitoring Script
• Kerberos KDC

Kerberos KDC
Load Balancer
CAS Primary
CAS Spare
42
UCD CAS Installation

• Final
• 3 Clustered CAS Servers
• Load Balancer
• Kerberos KDC

CAS Server Cluster
Kerberos KDC
Load Balancer
43
Questions?