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?
• 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
Authentication Domain
Secondary domain
1. Access application
2. Refer
for authn.
3. Ask for
credentials
SSO
Application
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 (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
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
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
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
(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
overview
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 (SecurID, Vasco,
…)
Biometrics
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
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 iChain
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