1. Authentication Systems and Single Sign-On (SSO) David Orrell, Eduserv Athens 1st EuroCAMP, 2-4 March 2005, Turin, Italy

2. Overview What is SSO? How SSO operates Implications of SSO SSO products and authentication systems SSO real-world examples and applications

3. Why SSO? Multiple systems typically require multiple sign-on dialogues –Eg. Desktop logon, email, VLE, library systems, external resources … –Multiple sets of credentials –Presenting credentials multiple times Headache for administration and users The more security domains, the more sign-ons required

4. Simple SSO operation Application /resource SSO Application Application /resource 1. Access application 2. Refer for authn. 3. Ask for credentials 4. Transfer to application Authentication DomainSecondary domain SSO Session (Ticket Granting Ticket) Transfer/Service ticket

5. Security implications Credentials never leave the authentication domain Secondary (affiliated) domains have to trust the authentication domain –Credentials must be asserted correctly –Protect from unauthorised use Authentication transfer has to be protected –Replay prevention –Interception/masquerade attacks

6. SSO Components Authentication server SSO Application HTTP server LDAP Kerberos RDBMS … Application Enforcement agent Sign-on (verification)App (enforcement) Authorisation

7. SSO dependencies SSO system relies on other infrastructure –Authentication system –Requires interface with web server –Identity management/registration Need to provide for authorisation –Applications often need more than just authentication information –Attribute information –Shibboleth or other architectures

8. Other considerations Most SSO systems are HTTP based –Browser cookies (restricted to the authentication domain) –HTTP redirects –Placement of tokens in querystring May require integration with application –Agent-based architecture –SSO protocol Needs to interface with authentication system Needs protocol between authentication domain and target application –Token/ticket-based –SAML POST/artifact profiles

9. Session management The SSO application maintains a session (TGT) for the user The target application usually maintains a session Logging out of the target application may not log you out of the SSO application Single Sign-On  Single Sign-Out! –Application specific

10. Single Sign-On applications Cross-institutional SSO –Athens (Eduserv/UK) –PAPI (Rediris/Spain) –Shibboleth (Internet2/USA) Commercial SSO products –Often companion products to identity managers/directories –Increasing standards compliance (SAML etc.) –Eg. Novell iChain, Sun Java System Access Manager etc…

11. WebISO products (1) “Web initial sign-on” products available for intra-institutional use –Allow authentication to web-based resources across an institution Freely available –Many released under Open Source licences Comparison study carried out for JISC, UK –Recommended reading http://www.jisc.ac.uk/uploaded_documents/CMSS-Gilmore.pdf

12. WebISO products (2) Yale Central Authentication Service (CAS) –http://www.yale.edu/tp/auth Pubcookie (Washington) –http://www.pubcookie.org WebAuth (Stanford) –http://webauthv3.stanford.edu Michigan CoSign –http://www.umich.edu/~umweb/software/cosign X.509 certificates via Kerberos (Michigan) –http://www.umich.edu/~x509 A-Select (Surfnet) –http://a-select.surfnet.nl

13. SSO methods Most SSO systems rely on cookies –Widely accepted and supported by browsers –Users who disable cookies or change browser security settings may lose SSO capability X.509 certificates provide alternative approach –Require installation on users machine –Need for revocation –Can be confusing for users

14. Supported Authentication Methods CAS –LDAP server (OpenLDAP, Active Directory) –Kerberos (MIT, Active Directory) Pubcookie –Kerberos v5 –LDAP server –/etc/shadow WebAuth –MIT Kerberos –OpenLDAP CoSign –Supports GSSAPI A-Select –Banking –SMS ‘SURFkey’ –LDAP –Radius

15. overview

16. Authentication in A-Select choose your own method (and strength) IP address Username / password –LDAP / Active Directory –RADIUS –SQL Passfaces PKI certificate OTP through SMS OTP through internet banking Tokens (SecurID, Vasco, … ) Biometrics

17. Choosing an SSO system (1) Need to evaluate systems appropriate to your environment –Apache/IIS/J2EE –OS/platform support Will the SSO product integrate with my –authentication system –applications (agent/webserver integration, legacy applications) –authorisation system (Shibboleth support?) Need to provide resilient system –Single point of failure –Performance/throughput

18. Choosing an SSO system (2) Need to be supportable –Is the product actively developed? –What is the support like? –Logging/diagnostics –Error handling Customisable –Some SSO products are specific to the organisation they originated from. Can it be customised for your needs?

19. SSO applications Applications typically require an ‘enforcement agent’ –Webserver module –Application-level integration –Usually require authorisation info Some SSO products utilise a proxy approach –SSO-enable legacy products without code change –Eg. Novell iChain

20. SSO in portals

22. Other SSO services

26. Logout

27. QUESTIONS? david.orrell@eduserv.org.uk http://www.eduserv.org.uk/athens