1 / 27

Authentication Systems and Single Sign-On (SSO)

Authentication Systems and Single Sign-On (SSO). David Orrell, Eduserv Athens EuroCAMP, 7-9 November 2005, Porto, Portugal. Overview. What is SSO? How SSO operates Implications of SSO SSO products and authentication systems SSO real-world examples and applications. Why SSO?.

wareham
Download Presentation

Authentication Systems and Single Sign-On (SSO)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authentication Systems and Single Sign-On (SSO) David Orrell, Eduserv Athens EuroCAMP, 7-9 November 2005, Porto, Portugal

  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. Authentication Domain Secondary domain Application/resource Application/resource 1. Access application 2. Refer for authn. 3. Ask for credentials SSO Application 4. Transfer to application SSO Session (Ticket Granting Ticket) Transfer/Service ticket Secondary domain Simple SSO operation

  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. HTTP server SSO Application Application Enforcement agent • LDAP • Kerberos • RDBMS • … Authentication server SSO Components 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… • Others • VLE, portal and library management products often have SSO capability

  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. 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 Supported Authentication Methods

  15. overview overview

  16. Authentication in A-Selectchoose 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

  21. SSO in portals

  22. Other SSO services

  23. Other SSO services

  24. Other SSO services

  25. Other SSO services

  26. Logout

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

More Related