Authentication Systems, Single-Sign-On (SSO) - Terena

licoricebedsΑσφάλεια

22 Φεβ 2014 (πριν από 3 χρόνια και 3 μήνες)

251 εμφανίσεις

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