Open-source Single Sign-On with CAS (Central Authentication Service)
Pascal Aubry, Vincent Mathieu & Julien Marchal
Copyright © 2004-2005 – ESUP-Portail consortium
Open-source Single Sign-On with CAS
• Single Sign-On– Why SSO?– The main principles of web SSO– The choice of CAS
• CAS (Central Authentication Service)– How does it work?– How to CAS-ify applications
• Web applications
• Non-web applications
• Limits• The effort of the ESUP-Portail consortium around CAS• Perspectives
Let’s fight generally accepted ideas!
• “Facing the growing number of passwords, Single Sign-On increases the security policy of firms and users’ comfort.”
• Well, yes, but…
Let’s fight generally accepted ideas!
• “SSO to federate authentication”
Let’s fight generally accepted ideas!
• “SSO is a suite of tools that memorizes passwords for users and provide them to applications”
• No, not at all!
Let’s fight generally accepted ideas!
• “SSO is generally deployed as a rest, after a centralized user directory and a unique entry point for the IS have been set up. SSO is then a modest project, easily developed in-house.”
• We must have missed something ;-)
Why Single Sign-On?
• Unique accounts but several authentications– Each time users access an application
• Security (password stealing)– Protect password transmission– Do not transmit passwords to applications
• Simplify applications
• Delegate developments without delegating authentication
• Abstract authentication– LDAP, NIS, database, NT, Active Directory, X509 certificates, …
SSO: the user’s point of view
web browser
app. #1 app. #2 app. #3
without SSO
service
web browser
app. #1 app. #2 app. #3
with SSO
service
SSO: principles on the web
• Authentication is centralized– One (redundant) authentication server
• Transparent HTTP redirections– From applications to the authentication server (when not authenticated)– From the authentication server to applications (when authenticated)
• Tokens propagate identities– Cookies, CGI parameters
CAS: why did we choose it?
• Security– Password is never transmitted to applications– Opaque tickets are used
• N-tier installations– Without transmitting any password!
• Portability (client libraries)– Java, Perl, JSP, ASP, PHP, PL/SQL, Apache and PAM modules
• Permanence– Developed by Yale University– World-wide used (mainly Universities)– Adopted by all the French educational community
• J2EE platform– Very light code (about 1000 lines)
• Open source• Integrated into uPortal
web browser
app. #1 app. #2 app. #3
with CAS
service
CAS: why did we choose it?
web browser
app. #1 app. #2 app. #3authentication
server
without SSO
userdatabase user
databaseservice
netId
passw
ord
net
Idp
assw
ord
web browser
app. #1 app. #2 app. #3
with CAS
service
CAS: why did we choose it?
web browser
app. #1 app. #2 app. #3authentication
server
without SSO
userdatabase user
databaseservice
netId
passw
ord
net
Idp
assw
ord
User authentication
CASserver
HT
TP
S
web browser
1ère authentification d’un utilisateur
CASserver
authentication form:
HT
TP
S
web browser
User authentication
• TGC: Ticket Granting Cookie– User’s passport to the CAS server– Private and protected cookie
(the only one used by CAS, optional)– Opaque re-playable ticket
CASserver
netIdpassword
HT
TP
Suser
database
web browser
TGC
TGC
1ère authentification d’un utilisateur
CASserver
netIdpassword
HT
TP
Suser
database
web browser
TGC
TGC
Accessing an applicationafter authentication
web browser
CASserver
TGC
HT
TP
S
application
TGC ST
ST
ST
• ST: Service Ticket– Browser’s passport to the CAS client (application)
– Opaque and non re-playable ticket
– Very limited validity (a few seconds)
ID
Accessing an applicationafter authentication
CASserver
HT
TP
S
TGC ST
ST
ST
ID
web browserTGC
• Redirections are transparent to users
application
• ST: Service Ticket– Browser’s passport to the CAS client (application)
– Opaque and non re-playable ticket
– Very limited validity (a few seconds)
Accessing an applicationwithout authentication
web browser
CASserver
HT
TP
S
Authentication form
application
Accessing an applicationwithout authentication
web browser
CASserver
TGC
HT
TP
S ST
ST
ID
netIdpassword ST
TGC
• No need to be previously authenticated to access an application
application
Remarks
• Once a TGC acquired, authentication is transparent for the access to any CAS-ified application of the workspace
• Once authenticated by an application, a session should be used between the browser and the application
Authenticating users with CAS
• CAS authentication left to administrators
• ESUP-Portail CAS Generic Handler– Mixed authentication– XML configuration
LDAPdirectory
database NISdomain
X509certificates
Kerberosdomain
Windows NTdomain
flat files
CASserver
Using the ESUP-Portail CAS GH<authentication debug="on"> <handler> <classname> org.esupportail.cas.server.handlers.ldap.FastBindLdapHandler </classname> <config> <filter>uid=%u,ou=people,dc=esup-portail,dc=org</filter> <server> <url>ldap://ldap.esup-portail.org</url> </server> </config> </handler> <handler> <classname> org.esupportail.cas.server.handlers.nis.NisHandler </classname> <config> <domain>ESUP-PORTAIL</domain> <encryption>pammd5</encryption> <server> <host>nismaster.esup-portail.org</host> <host>nisslave.esup-portail.org</host> </server> </config> </handler></authentication>
CAS-ifying a web application
• Use provided libraries
• Add a few lines of code
• Note: you can also protect static resources– With mod_cas, an Apache module
CAS-ifying a web application
• An example using phpCAS (ESUP-Portail)
<?php // include phpCAS library include_once('CAS/CAS.php');
// declare our script as a CAS client phpCAS::client(CAS_VERSION_2_0,'auth.univ.fr',443,'');
// redirect to the CAS server if needed phpCAS::authenticateIfNeeded();
// at this point, the user is authenticated?><h1>Successfull Authentication!</h1><p>User's login: <?php echo phpCAS::getUser(); ?>.</p>
N-tier installations
• PGT: Proxy Granting Ticket– Application’s passport for a user to the
CAS server– Opaque and re-playable ticket
web browser
CASserver
TGC
application(CAS proxy)
ST
ST
service
IDPGT
PGT
application(CAS proxy)
N-tier installations
web browser
CASserver
TGC
ST
service
PGT
PT
PTID
PGT
• PGT: Proxy Granting Ticket– Application’s passport for a user to the
CAS server– Opaque and re-playable ticket
• PT : Proxy Ticket– Application’s passport for a user to a tier
service– Opaque and non re-playable ticket– Very limited validity
PT
CAS-ifying a non web application
• One of the strongest points of CAS
• Use the pam_cas PAM module
• Example of PAM configuration:
auth sufficient /lib/security/pam_ldap.soauth sufficient /lib/security/pam_pwdb.so shadow nullokauth required /lib/security/pam_cas.so
pam_cas
The pam_cas PAM module
• Pam_cas authenticates users with a CAS ticket
pam_pwdb
clientapplication
pam_ldap
LDAP directory
login/password
login/password
/etc/passwd
login/password
clientapplication
CASserver
ticket
serverapplication
login/ticket
CAS-ifying an IMAP server
• Objectives
– Access an IMAP server from a web application that does not know the password of the user connected
– Let traditional mail clients authenticate “normally” (with a password)
– Do not modify the IMAP server
• The solution: pam_cas :-)
pam_cas
CAS-ifying an IMAP server
pam_pwdb
traditionalmail client
pam_ldap
LDAP directory
login / password
login / password
/etc/passwd
login / password
CAS-ified webmail(CAS proxy)
login / PT
CASserver
PT
web browser
ST
IMAPserver
pam_cas
pam_pwdb
pam_ldap
CAS-ifying Cyrus IMAPdtraditionalmail client
LDAPdirectory
login / password
login / password
/etc/passwd
CAS-ified webmail(CAS proxy)
CASserver
PT
web browserST
sasl
Cyrusimapd
login / PT
pam_cas
pam_pwdb
pam_ldap
sasl
CAS-ifying Cyrus IMAPdtraditionalmail client
Cyrusimapd
LDAPdirectory
login / password
login / password
/etc/passwd
CAS-ified webmail(CAS proxy)
login / PT
CASserver
PT
web browserST
sasl_authd
cache
Unix socket
Cyrus IMAP daemon
sasl_authd daemon
Cache
efficiency:
95%
Limits
• CAS deals with authentication, not authorization
• No redundancy– No native load-balancing (but low load)– No fault-tolerance (but very good reliability)
• No Single Sign-Off
• A very poor documentation
The effort of the ESUP-Portail consortium
• Writing documentation
• Adding libraries (phpCAS, esup-mod_cas, esup-pam_cas)
• Adding features to the CAS server– Authentication handlers (LDAP, NIS, files, databases, NT domains, …)– Mixed authentication– Authentication debug mode– Rendering customization (appearance, internationalization)– CAS quick start (Jakarta Tomcat + Yale CAS server + CAS GH)
• Supporting the French CAS community– Through forums and mailing lists
Now, what to do first (requirements)?
• Data organization– The Information System should be well-formed– Small technical problems, big political issues
• Data storage– A standard way to store users (an Excel sheet is no standard ;-)
• Competences– Web technologies– PKI (CRU)
• Voluntary policy– Is security a real concern?
So, what next?
• Add new authentication modes
• Make establishments cooperate– Propagate user attributes (namely or anonymously)– Shibboleth, Liberty Alliance
• CAS is now a JASIG project
• Share your experience!
Note this!
• CRU is starting a circle of trust (federation project) among the French educational community– Comité Réseau des Universités (http://www.cru.fr)– Authenticate at university level– Authorize at resource level by relying on propagated attributes
• Many questions, a few answers only at this time– Compare Shibboleth and Liberty Alliance– Test existing solutions– Study if CAS can be used with Shibboleth, and how– Can LASSO implement a WAYF service?– Would LASSO replace CAS?
• A goal– Show how it is possible for establishments to cooperate securely
Enjoy CAS!