Authentication Systems and Single SignOn SSO

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
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
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-Gilm
  ore.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
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_at_eduserv.org.uk
• http//www.eduserv.org.uk/athens