Transcript shibboleth-tech-overview-dec05

Shibboleth
A Technical Overview
Tom Scavo
[email protected]
NCSA
shibboleth-tech-overview-dec05
1
Shibboleth Defined
•
•
Shibboleth provides cross-domain
single sign-on and attribute-based
authorization while preserving user
privacy
Shibboleth is simultaneously:
1. A project
2. A specification
3. An implementation
shibboleth-tech-overview-dec05
2
Shibboleth Project
• Shibboleth, a project of Internet2-MACE:
– Advocates a federated identity management
policy framework focused on user privacy
– Develops middleware architectures to
facilitate inter-institutional attribute sharing
– Manages an open source reference
implementation of the Shibboleth spec
• Shibboleth has made significant
contributions to the SAML-based identity
management space
shibboleth-tech-overview-dec05
3
Collaborations
Internet2
OASIS
E-Auth
Shibboleth
Educause
Liberty
Vendors
shibboleth-tech-overview-dec05
4
Shibboleth Specification
• Shibboleth is an extension of the SAML
1.1 browser profiles:
– Shibboleth Browser/POST Profile
– Shibboleth Browser/Artifact Profile
– Shibboleth Attribute Exchange Profile
• See the Shibboleth spec for details:
S. Cantor et al., Shibboleth Architecture:
Protocols and Profiles. Internet2-MACE,
10 September 2005.
shibboleth-tech-overview-dec05
5
Shibboleth Contributions
• Shibboleth contributions are many
• Privacy and Anonymity
– Attribute Release Policy
– Opaque, transient name identifiers
• SP-first browser profiles
– Authentication Request Profile
– Where Are You From? service
• Attribute Exchange Profile
shibboleth-tech-overview-dec05
6
Shibboleth Implementation
•
The Shibboleth implementation consists
of two components:
1. Shibboleth Identity Provider
2. Shibboleth Service Provider
•
•
The Identity Provider is a J2EE webapp
The Service Provider is a C++ Apache
module
– A pure Java Service Provider is in beta
shibboleth-tech-overview-dec05
7
Shibboleth Versions
• The current version of Shibboleth is:
– Shibboleth 1.3 (Jul 2005)
• Previous versions:
– Shibboleth 1.2.1 (Nov 2004)
– Shibboleth 1.2 (Apr 2004)
– Shibboleth 1.1 (Aug 2003)
– Shibboleth 1.0 (Jun 2003)
• Work has begun on Shibboleth 2.0,
which is based on SAML 2.0
shibboleth-tech-overview-dec05
8
Other Implementations
• Implementations of Shibboleth (the spec):
– Shibboleth (of course!)
http://shibboleth.internet2.edu/
– Guanxi
http://www.jisc.ac.uk/index.cfm?name=project_guanxi
– AthensIM (Identity Provider only)
http://www.athensams.net/shibboleth/AthensIM/
• There are more open source
implementations of Shibboleth than there
are of SAML itself!
shibboleth-tech-overview-dec05
9
Introduction
shibboleth-tech-overview-dec05
10
Presentation Overview
• Shibboleth Components
– Identity Provider
– Service Provider
• Shibboleth SSO Profiles
– Browser/POST Profile
– Browser/Artifact Profile
• Attributes
– Attribute Exchange Profile
– eduPerson
• Metadata
shibboleth-tech-overview-dec05
11
Prerequisites
• Familiarity with SAML 1.1 is assumed
• J. Hughes et al. Technical Overview of
the OASIS Security Assertion Markup
Language (SAML) V1.1. OASIS, May
2004. Document ID sstc-saml-techoverview-1.1-cd
• SAML on Wikipedia
http://en.wikipedia.org/wiki/SAML
shibboleth-tech-overview-dec05
12
Background References
• Shibboleth Technical Overview
http://shibboleth.internet2.edu/docs/draftmace-shibboleth-tech-overview-latest.pdf
• Shibboleth Protocol Specification
http://shibboleth.internet2.edu/docs/internet2mace-shibboleth-arch-protocols-latest.pdf
• SAML 2.0 Metadata Specification
http://docs.oasisopen.org/security/saml/v2.0/saml-metadata2.0-os.pdf
shibboleth-tech-overview-dec05
13
Related Projects
• SAML
– Shib contributed significant IP to SAML specs
• Liberty ID-FF
– Liberty formed the basis of the SAML 2.0 spec
• eduPerson
– Shib was a driving force behind this attribute vocabulary
• ADFS (WS-Federation)
– Microsoft's approach to federated IdM
• LionShare/ECL
– Federated P2P file sharing
• GridShib
– Shib-based authorization in Globus Toolkit
shibboleth-tech-overview-dec05
14
Notation
• XML namespace prefixes:
–
–
–
–
–
–
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
• Abbreviations
–
–
–
–
Identity Provider (IdP)
Service Provider (SP)
Where Are You From? (WAYF)
Authentication (AuthN)
shibboleth-tech-overview-dec05
15
The Shibboleth Experience
shibboleth-tech-overview-dec05
16
The Shibboleth Wiki
• For example, the Shibboleth wiki (hosted
at ohio-state.edu) is “shibbolized”
• To edit wiki pages, a user must be
known to the wiki
• Users have wikiNames but do not have
wiki passwords
• Users log into their home institution,
which asserts user identity to the wiki
shibboleth-tech-overview-dec05
17
shibboleth-tech-overview-dec05
18
Shib Browser Profile
• The user clicks
the link “Login
via InQueue
IdP”
• This initiates a
sequence of
steps known as
Shib Browser
Profile
shibboleth-tech-overview-dec05
3
UIUC
4
1
InQueue
2
C
L
I
E
N
T
6
7
5
OSU
8
19
shibboleth-tech-overview-dec05
20
Shib Browser Profile
• InQueue
provides a
“Where Are You
From?” service
• The user
chooses their
preferred
identity provider
from a menu
shibboleth-tech-overview-dec05
3
UIUC
4
1
InQueue
2
C
L
I
E
N
T
6
7
5
OSU
8
21
shibboleth-tech-overview-dec05
22
Shib Browser Profile
• The user is
redirected to
UIUC login
page
• After login, the
user is issued a
SAML assertion
and redirected
back to the wiki
shibboleth-tech-overview-dec05
3
UIUC
4
1
InQueue
2
C
L
I
E
N
T
6
7
5
OSU
8
23
shibboleth-tech-overview-dec05
24
Shib Browser Profile
• After validating
the assertion,
the wiki
retrieves user
attributes via
back-channel
Shib attribute
exchange
shibboleth-tech-overview-dec05
3
UIUC
4
1
InQueue
2
C
L
I
E
N
T
6
7
5
OSU
8
25
Asserting Identity
• Initially, the user is unknown to the wiki
• After querying the home institution, the
wiki knows the user’s identity
• “trscavo-uiuc.edu” is wiki-speak for
[email protected]
• The latter is eduPersonPrincipalName,
an identity attribute asserted by the
user’s home institution
shibboleth-tech-overview-dec05
26
OpenIdP.org
• By design, a user with an account at an
institution belonging to InCommon,
InQueue, or SDSS can log into the wiki
• Other users can register at openidp.org,
which is a zero-admin Shib IdP
• The openidp asserts an alternate form of
identity (email addresses as opposed to
eduPersonPrincipalName)
shibboleth-tech-overview-dec05
27
Shibboleth Components
shibboleth-tech-overview-dec05
28
The Actors
• Identity Provider
– The Identity Provider (IdP)
creates, maintains, and
manages user identity
– A Shibboleth IdP produces
SAML assertions
Identity Provider
Authentication
Authority
Attribute
Authority
SSO
Service
Artifact
Resolution
Service
Assertion
Consumer
Service
Attribute
Requester
• Service Provider
– The Service Provider (SP)
controls access to services
and resources
– A Shibboleth SP consumes
SAML assertions
shibboleth-tech-overview-dec05
Resource
Service Provider
29
Identity Provider
• Authentication Authority
– Produces SAML authentication assertions
• Single Sign-On Service
– A (SAML2) browser-facing component
– Orchestrates SP-first browser profiles
• Artifact Resolution Service
– Resolves SAML artifacts into assertions
• Attribute Authority
– Produces SAML attribute assertions
shibboleth-tech-overview-dec05
30
Service Provider
• Assertion Consumer Service
– A browser-facing component
– Participates in the browser profiles
– Consumes SAML authentication assertions
• Attribute Requester
– Consumes SAML attribute assertions
• Resource Manager
– Protects web resources
shibboleth-tech-overview-dec05
31
ProviderIds
• Every SAML provider has a unique
identifier called a providerId
• A providerId must be a URI of no more
than 1024 characters
• In practice, a providerId is often an URL:
https://idp.example.org/shibboleth
https://sp.example.org/shibboleth
• Use of an “https” URL facilitates
metadata publication
shibboleth-tech-overview-dec05
32
Shibboleth SSO Profiles
shibboleth-tech-overview-dec05
33
Shib SSO Profiles
• Shibboleth SSO profiles are SP-first
• Shibboleth specifies an Authentication
Request Profile
• Shibboleth Browser/POST Profile =
Shib Authn Request Profile +
SAML Browser/POST Profile
• Shibboleth Browser/Artifact Profile =
Shib Authn Request Profile +
SAML Browser/Artifact Profile
shibboleth-tech-overview-dec05
34
Shib AuthN Request Profile
• A Shibboleth authentication request is an
ordinary GET request:
https://idp.org/shibboleth/SSO?
providerId=https://sp.org/shibboleth/&
shire=https://sp.org/shibboleth/SSO&
target=https://sp.org/myresource&
time=1102260120
• The client is redirected to this location
after requesting a protected resource at
the SP without a security context
shibboleth-tech-overview-dec05
35
Shib Browser/POST Profile
•
The Shibboleth Browser/POST Profile
consists of eight (8) steps:
1.
2.
3.
4.
5.
6.
7.
8.
Request the target resource
Redirect to the Single Sign-On (SSO) Service [SP]
Request the SSO Service
Respond with an HTML form plus assertion [IdP]
Request the Assertion Consumer Service
Redirect to the target resource [SP]
Request the target resource again
Respond with the requested resource [SP]
shibboleth-tech-overview-dec05
36
Shib Browser/POST Profile
• Browser/POST is
an SP-first profile
• The IdP
produces an
assertion at step
4, which the SP
consumes at
step 5
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
6
5
SSO
Service
Attribute
Authority
Assertion
Consumer
Service
8
7
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
37
Shib Browser/Artifact Profile
•
The Shibboleth Browser/Artifact Profile has
ten (10) steps:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Request the target resource
Redirect to the Single Sign-On (SSO) Service [SP]
Request the SSO Service
Redirect to the Assertion Consumer Service [IdP]
Request the Assertion Consumer Service
Request the Artifact Resolution Service [SP]
Respond with a SAML AuthN Assertion [IdP]
Redirect to the target resource [SP]
Request the target resource again
Respond with the requested resource [SP]
shibboleth-tech-overview-dec05
38
Shib Browser/Artifact Profile
• Browser/Artifact
is SP-first, too
• This time the
authN assertion
is passed by
reference
• The SP resolves
the artifact into
the assertion
Identity Provider
4
C
L
I
E
N
T
3
Authentication
Authority
Attribute
Authority
SSO
Service
Artifact
Resolution
Service
7
8
5
6
Assertion
Consumer
Service
10
9
2
Resource
1
Service Provider
shibboleth-tech-overview-dec05
39
IdP Discovery
shibboleth-tech-overview-dec05
40
Identity Provider Discovery
• Step 2 of the Shib browser profiles is
problematic since the SP does not know
the browser user’s preferred IdP!
• The SP relies on a process called
Identity Provider Discovery
• The Shib approach to IdP Discovery is
called a “Where Are You From?”
(WAYF) service
shibboleth-tech-overview-dec05
41
Shib WAYF Service
• Shibboleth specifies an optional WAYF
(Where Are You From?) service that
facilitates IdP discovery
• A Shibboleth WAYF:
–
–
–
–
supports the Authentication Request Profile
accepts authN requests from the SP
knows the browser user’s preferred IdP
redirects the client to the desired IdP
• A Shibboleth WAYF is usually interactive
shibboleth-tech-overview-dec05
42
Shib WAYF Service
Identity Provider
Authentication
Authority
8
6
5
WAYF
4
3
C
L
I
E
N
T
7
10
9
SSO
Service
Attribute
Authority
Assertion
Consumer
Service
12
11
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
43
WAYF Implementations
• A typical request to the InQueue WAYF:
https://wayf.internet2.edu/InQueue/WAYF?
providerId=https://sp.org/shibboleth/&
shire=https://sp.org/shibboleth/SSO&
target=https://sp.org/myresource&
time=1102260120
• InCommon also provides a WAYF service:
https://wayf.incommonfederation.org/InCo
mmon/WAYF
• Implementation weaknesses:
– User selection from a list does not scale
– No provisions for user maintenance of IdP
preferences
shibboleth-tech-overview-dec05
44
InCommon Federation
shibboleth-tech-overview-dec05
45
Attributes
shibboleth-tech-overview-dec05
46
Attribute Push
• The POSTed response may contain both
an authentication assertion and an
attribute assertion, called attribute push
• Depending on the use case, attribute
push may raise privacy concerns
• An alternative is attribute pull, which
requires a back-channel exchange
shibboleth-tech-overview-dec05
47
Shib Attribute Exchange
• A Shibboleth SP often queries an IdP for
attributes after validating an authN
assertion
• An opaque, transient identifier called a
handle is embedded in the authN
assertion
• The SP sends a SAML AttributeQuery
message with handle attached
shibboleth-tech-overview-dec05
48
Attribute Pull
• Attribute pull is a secure, mutually
authenticated back-channel exchange
• No IdP discovery is involved because
the SP already knows the IdP by virtue
of the authN assertion
• Attribute pull is subject to PKI, firewalls
and other security and network
concerns, however
shibboleth-tech-overview-dec05
49
Browser/POST Attribute Pull
•
The Shibboleth Browser/POST Profile with
Attribute Pull has ten (10) steps:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Request the target resource
Redirect to the Single Sign-On (SSO) Service [SP]
Request the SSO Service
Respond with an HTML form plus assertion [IdP]
Request the Assertion Consumer Service
Request attributes from the AA [SP]
Respond with a SAML Attribute Assertion [IdP]
Redirect to the target resource [SP]
Request the target resource again
Respond with the requested resource [SP]
shibboleth-tech-overview-dec05
50
Browser/POST Attribute Pull
• The first 5 steps of
this profile are
identical to ordinary
Browser/POST
• Before redirecting
the Client to the
Resource Manager,
the SP queries for
attributes via a
back-channel
exchange
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
7
8
5
Assertion
Consumer
Service
Attribute
Requester
10
9
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
6
51
Browser/POST Attribute Pull Step 1
• The Client
requests a target
resource at the
SP
Identity Provider
Authentication
Authority
SSO
Service
C
L
I
E
N
T
Attribute
Authority
Assertion
Consumer
Service
Resource
1
Service Provider
shibboleth-tech-overview-dec05
52
Browser/POST Attribute Pull Step 2
• The SP performs a
security check on
behalf of the target
resource
• If a valid security
context at the SP
does not exist, the
SP redirects the
Client to the single
sign-on (SSO)
service at the IdP
Identity Provider
Authentication
Authority
SSO
Service
C
L
I
E
N
T
Attribute
Authority
Assertion
Consumer
Service
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
53
Browser/POST Attribute Pull Step 3
• The Client
requests the
SSO service at
the IdP
Identity Provider
Authentication
Authority
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
Assertion
Consumer
Service
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
54
Browser/POST Attribute Pull Step 4
• The SSO service
processes the authN
request and performs a
security check
• If the user does not
have a valid security
context, the IdP
identifies the principal
(details omitted)
• The SSO service
produces an
authentication assertion
and returns it to the
Client
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
Assertion
Consumer
Service
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
55
Browser/POST Attribute Pull Step 5
• The Client issues
a POST request
to the assertion
consumer
service at the SP
• The authN
assertion is
included with the
request
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
5
2
1
SSO
Service
Attribute
Authority
Assertion
Consumer
Service
Resource
Service Provider
shibboleth-tech-overview-dec05
56
Browser/POST Attribute Pull Step 6
• The assertion
consumer service
validates the
request, creates a
security context at
the SP
• The attribute
requester sends a
(mutually
authenticated)
attribute query to
the AA
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
6
5
2
1
Assertion
Consumer
Service
Attribute
Requester
Resource
Service Provider
shibboleth-tech-overview-dec05
57
Browser/POST Attribute Pull Step 7
• The IdP returns an
attribute assertion
subject to attribute
release policy
• The SP filters the
attributes according
to attribute
acceptance policy
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
7
5
2
1
Assertion
Consumer
Service
Attribute
Requester
Resource
Service Provider
shibboleth-tech-overview-dec05
6
58
Browser/POST Attribute Pull Step 8
• The assertion
consumer
service updates
the security
context and
redirects the
Client to the
target resource
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
7
8
5
2
1
Assertion
Consumer
Service
Attribute
Requester
Resource
Service Provider
shibboleth-tech-overview-dec05
6
59
Browser/POST Attribute Pull Step 9
• The Client
requests the
target resource
at the SP (again)
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
7
8
5
Assertion
Consumer
Service
Attribute
Requester
9
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
6
60
Browser/POST Attribute Pull Step 10
• Since a security
context exists,
the SP returns
the resource to
the Client
Identity Provider
Authentication
Authority
4
C
L
I
E
N
T
3
SSO
Service
Attribute
Authority
7
8
5
Assertion
Consumer
Service
Attribute
Requester
10
9
2
1
Resource
Service Provider
shibboleth-tech-overview-dec05
6
61
Attribute Release Policy
• At step 6, the AA releases attributes
subject to Attribute Release Policy
(arp.site.xml)
• In the site ARP, policy is specified on a
per-SP basis (granularity does not
extend to the resource)
• User ARPs (arp.user.principal.xml) may
be applied, although in practice this is
seldom done (a GUI does not exist)
shibboleth-tech-overview-dec05
62
Attribute Acceptance Policy
•
At step 7, the SP applies an Attribute
Acceptance Policy (AAP.xml) to the
received attributes:
1. Policy restricts what attributes can be
asserted by whom
2. Maps SAML attributes to HTTP headers
•
At step 9, the resource uses the HTTP
headers to make an access control
decision
shibboleth-tech-overview-dec05
63
Directory Schema
• Neither Shibboleth nor SAML define any
attributes per se
• It is left to individual deployments to
define their own attributes
• A standard approach to user attributes
is crucial
• Without such standards, interoperability
is impossible
shibboleth-tech-overview-dec05
64
eduPerson
• Internet2 and EDUCAUSE have jointly
developed a set of attributes and
associated bindings called eduPerson
• The LDAP binding of eduPerson is
derived from the standard LDAP object
class called inetOrgPerson [RFC 2798]
• Approximately 40 attributes have been
defined by InCommon as common
identity attributes
shibboleth-tech-overview-dec05
65
InCommon Attributes
• InCommon’s 6 “highly recommended” attributes:
Attribute Name
givenName
sn (surname)
Attribute Value
Mary
Smith
cn (common name)
eduPersonScopedAffiliation
eduPersonPrincipalName
eduPersonTargetedID
Mary Smith
[email protected]
[email protected]
?
(eduPersonTargetedID does not have a precise value syntax)
shibboleth-tech-overview-dec05
66
Metadata
shibboleth-tech-overview-dec05
67
SAML 2.0 Metadata
• A metadata format was introduced by
Liberty, which was adopted by SAML 2.0
• SAML 2.0 metadata has been profiled for
SAML 1.x entities
• Likewise, SAML 1.x metadata has been
profiled for Shibboleth 1.3
• SAML 2.0 metadata has really caught on!
shibboleth-tech-overview-dec05
68