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

Transfer/Service
ticket
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
Authentication
server
SSO
Application
HTTP server
LDAP
Kerberos
RDBMS

Application
Enforcement
agent
Sign-on (verification) App (enforcement)
Authorisation
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