Presentation is loading. Please wait.

Presentation is loading. Please wait.

Open-source Single Sign-On with CAS (Central Authentication Service) Pascal Aubry, Vincent Mathieu & Julien Marchal Copyright © 2004-2005 – ESUP-Portail.

There are copies: 1
Open-source Single Sign-On with CAS (Central Authentication Service) Pascal Aubry, Vincent Mathieu & Julien Marchal Copyright © 2004 – ESUP-Portail consortium.

Similar presentations


Presentation on theme: "Open-source Single Sign-On with CAS (Central Authentication Service) Pascal Aubry, Vincent Mathieu & Julien Marchal Copyright © 2004-2005 – ESUP-Portail."— Presentation transcript:

1 Open-source Single Sign-On with CAS (Central Authentication Service) Pascal Aubry, Vincent Mathieu & Julien Marchal Copyright © 2004-2005 – ESUP-Portail consortium

2 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

3 Lets 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…

4 Lets fight generally accepted ideas! SSO to federate authentication

5 Lets fight generally accepted ideas! SSO is a suite of tools that memorizes passwords for users and provide them to applications No, not at all!

6 Lets 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 ;-)

7 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, …

8 SSO: the users point of view web browser app. #1app. #2app. #3 without SSO service web browser app. #1app. #2app. #3 with SSO service

9 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

10 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

11 web browser app. #1app. #2app. #3 with CAS service CAS: why did we choose it? web browser app. #1app. #2app. #3 authentication server without SSO user database service netId password

12 web browser app. #1app. #2app. #3 with CAS service CAS: why did we choose it? web browser app. #1app. #2app. #3 authentication server without SSO user database service netId password

13 User authentication CAS server HTTPS web browser

14 User authentication TGC: Ticket Granting Cookie –Users passport to the CAS server –Private and protected cookie (the only one used by CAS, optional) –Opaque re-playable ticket CAS server netId password HTTPS user database web browser TGC

15 Accessing an application after authentication web browser CAS server TGC HTTPS application TGC ST ST: Service Ticket –Browsers passport to the CAS client (application) –Opaque and non re-playable ticket –Very limited validity (a few seconds) ID

16 Accessing an application after authentication CAS server HTTPS TGC ST ID web browser TGC Redirections are transparent to users application ST: Service Ticket –Browsers passport to the CAS client (application) –Opaque and non re-playable ticket –Very limited validity (a few seconds)

17 Accessing an application without authentication web browser CAS server HTTPS Authentication form application

18 Accessing an application without authentication web browser CAS server TGC HTTPS ST ID netId password ST TGC No need to be previously authenticated to access an application application

19 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

20 Authenticating users with CAS CAS authentication left to administrators ESUP-Portail CAS Generic Handler –Mixed authentication –XML configuration LDAP directory databaseNIS domain X509 certificates Kerberos domain Windows NT domain flat files CAS server

21 Using the ESUP-Portail CAS GH org.esupportail.cas.server.handlers.ldap.FastBindLdapHandler uid=%u,ou=people,dc=esup-portail,dc=org ldap://ldap.esup-portail.org org.esupportail.cas.server.handlers.nis.NisHandler ESUP-PORTAIL pammd5 nismaster.esup-portail.org nisslave.esup-portail.org

22 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

23 CAS-ifying a web application An example using phpCAS (ESUP-Portail) Successfull Authentication! User's login:.

24 N-tier installations PGT: Proxy Granting Ticket –Applications passport for a user to the CAS server –Opaque and re-playable ticket web browser CAS server TGC application (CAS proxy) ST service ID PGT

25 application (CAS proxy) N-tier installations web browser CAS server TGC ST service PGT PT ID PGT PGT: Proxy Granting Ticket –Applications passport for a user to the CAS server –Opaque and re-playable ticket PT : Proxy Ticket –Applications passport for a user to a tier service –Opaque and non re-playable ticket –Very limited validity PT

26 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.so auth sufficient /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_cas.so

27 pam_cas The pam_cas PAM module Pam_cas authenticates users with a CAS ticket pam_pwdb client application pam_ldap LDAP directory login/password /etc/passwd login/password client application CAS server ticket server application login/ticket

28 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 :-)

29 pam_cas CAS-ifying an IMAP server pam_pwdb traditional mail client pam_ldap LDAP directory login / password /etc/passwd login / password CAS-ified webmail (CAS proxy) login / PT CAS server PT web browser ST IMAP server

30 pam_cas pam_pwdb pam_ldap CAS-ifying Cyrus IMAPd traditional mail client LDAP directory login / password /etc/passwd CAS-ified webmail (CAS proxy) CAS server PT web browser ST sasl Cyrus imapd login / PT

31 pam_cas pam_pwdb pam_ldap sasl CAS-ifying Cyrus IMAPd traditional mail client Cyrus imapd LDAP directory login / password /etc/passwd CAS-ified webmail (CAS proxy) login / PT CAS server PT web browser ST sasl_authd cache Unix socket Cyrus IMAP daemon sasl_authd daemon Cache efficiency: 95%

32 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

33 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

34 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?

35 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!

36 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

37 Enjoy CAS!


Download ppt "Open-source Single Sign-On with CAS (Central Authentication Service) Pascal Aubry, Vincent Mathieu & Julien Marchal Copyright © 2004-2005 – ESUP-Portail."

Similar presentations


Ads by Google