Authentication Systems and Single SignOn SSO David Orrell

Authentication Systems and Single Sign-On (SSO) David Orrell, Eduserv Athens Euro. CAMP, 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? • 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

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

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

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

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

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

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

Single Sign-On applications • Cross-institutional SSO – Athens (Eduserv/UK) – PAPI (Rediris/Spain) – Shibboleth (Internet 2/USA) • Commercial SSO products – Often companion products to identity managers/directories – Increasing standards compliance (SAML etc. ) – Eg. Novell i. Chain, Sun Java System Access Manager etc… • Others – VLE, portal and library management products often have SSO capability

Web. ISO 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

Web. ISO products (2) • Yale Central Authentication Service (CAS) – http: //www. yale. edu/tp/auth • Pubcookie (Washington) – http: //www. pubcookie. org • Web. Auth (Stanford) – http: //webauthv 3. stanford. edu • Michigan Co. Sign – http: //www. umich. edu/~umweb/software/cosign • X. 509 certificates via Kerberos (Michigan) – http: //www. umich. edu/~x 509 • A-Select (Surfnet) – http: //a-select. surfnet. nl

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

Supported Authentication Methods • CAS – LDAP server (Open. LDAP, Active Directory) – Kerberos (MIT, Active Directory) • Pubcookie – Kerberos v 5 – LDAP server – /etc/shadow • Web. Auth – MIT Kerberos – Open. LDAP • Co. Sign – Supports GSSAPI • A-Select – Banking – SMS ‘SURFkey’ – LDAP – Radius

overview

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 (Secur. ID, Vasco, …) Biometrics

Choosing an SSO system (1) • Need to evaluate systems appropriate to your environment – Apache/IIS/J 2 EE – 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

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?

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 i. Chain

SSO in portals

SSO in portals

Other SSO services

Other SSO services

Other SSO services

Other SSO services

Logout

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