Shibboleth A Technical Overview

1
ShibbolethA Technical Overview

• Tom Scavotrscavo_at_ncsa.uiuc.edu
• NCSA

2
Shibboleth Defined

• Shibboleth provides cross-domain single sign-on
  and attribute-based authorization while
  preserving user privacy
• Shibboleth is simultaneously
• A project
• A specification
• An implementation

3
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

4
Collaborations
Internet2
E-Auth
OASIS
Shibboleth
Liberty
Educause
Vendors
5
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 detailsS. Cantor et
  al., Shibboleth Architecture Protocols and
  Profiles. Internet2-MACE, 10 September 2005.

6
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

7
Shibboleth Implementation

• The Shibboleth implementation consists of two
  components
• Shibboleth Identity Provider
• 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

8
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

9
Other Implementations

• Implementations of Shibboleth (the spec)
• Shibboleth (of course!)http//shibboleth.internet
  2.edu/
• Guanxihttp//www.jisc.ac.uk/index.cfm?nameprojec
  t_guanxi
• AthensIM (Identity Provider only)http//www.athen
  sams.net/shibboleth/AthensIM/
• There are more open source implementations of
  Shibboleth than there are of SAML itself!

10
Introduction
11
Presentation Overview

• Shibboleth Components
• Identity Provider
• Service Provider
• Shibboleth SSO Profiles
• Browser/POST Profile
• Browser/Artifact Profile
• Attributes
• Attribute Exchange Profile
• eduPerson
• Metadata

12
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-tech-overvi
  ew-1.1-cd
• SAML on Wikipediahttp//en.wikipedia.org/wiki/SAM
  L

13
Background References

• Shibboleth Technical Overviewhttp//shibboleth.in
  ternet2.edu/docs/draft-mace-shibboleth-tech-overvi
  ew-latest.pdf
• Shibboleth Protocol Specificationhttp//shibbolet
  h.internet2.edu/docs/internet2-mace-shibboleth-arc
  h-protocols-latest.pdf
• SAML 2.0 Metadata Specificationhttp//docs.oasis-
  open.org/security/saml/v2.0/saml-metadata-2.0-os.p
  df

14
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

15
Notation

• XML namespace prefixes
• xmlnssaml"urnoasisnamestcSAML1.0assertion"
  
• xmlnssamlp"urnoasisnamestcSAML1.0protocol"
  
• xmlnsmd"urnoasisnamestcSAML2.0metadata"
• xmlnsds"http//www.w3.org/2000/09/xmldsig"
• xmlnsxsd"http//www.w3.org/2001/XMLSchema"
• xmlnsxsi"http//www.w3.org/2001/XMLSchema-instan
  ce"
• Abbreviations
• Identity Provider (IdP)
• Service Provider (SP)
• Where Are You From? (WAYF)
• Authentication (AuthN)

16
The Shibboleth Experience
17
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

18
(No Transcript)
19
Shib Browser Profile

• The user clicks the link Login via InQueue IdP
• This initiates a sequence of steps known as Shib
  Browser Profile

3
UIUC
C L I E N T
4
1
InQueue
7
6
2
5
OSU
8
20
(No Transcript)
21
Shib Browser Profile

• InQueue provides a Where Are You From? service
• The user chooses their preferred identity
  provider from a menu

3
UIUC
C L I E N T
4
1
InQueue
7
6
2
5
OSU
8
22
(No Transcript)
23
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

3
UIUC
C L I E N T
4
1
InQueue
7
6
2
5
OSU
8
24
(No Transcript)
25
Shib Browser Profile

• After validating the assertion, the wiki
  retrieves user attributes via back-channel Shib
  attribute exchange

3
UIUC
C L I E N T
4
1
InQueue
7
6
2
5
OSU
8
26
Asserting Identity

• Initially, the user is unknown to the wiki
• After querying the home institution, the wiki
  knows the users identity
• trscavo-uiuc.edu is wiki-speak for
  trscavo_at_uiuc.edu
• The latter is eduPersonPrincipalName, an identity
  attribute asserted by the users home institution

27
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 eduPersonPrincipalN
  ame)

28
Shibboleth Components
29
The Actors
Identity Provider

• Identity Provider
• The Identity Provider (IdP) creates, maintains,
  and manages user identity
• A Shibboleth IdP produces SAML assertions
• Service Provider
• The Service Provider (SP) controls access to
  services and resources
• A Shibboleth SP consumes SAML assertions

Authentication Authority
Attribute Authority
SSO Service
Artifact Resolution Service
Assertion Consumer Service
Attribute Requester
Resource
Service Provider
30
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

31
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

32
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
  URLhttps//idp.example.org/shibbolethhttps//sp
  .example.org/shibboleth
• Use of an https URL facilitates metadata
  publication

33
Shibboleth SSO Profiles
34
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

35
Shib AuthN Request Profile

• A Shibboleth authentication request is an
  ordinary GET requesthttps//idp.org/shibboleth/S
  SO? providerIdhttps//sp.org/shibboleth/
  shirehttps//sp.org/shibboleth/SSO
  targethttps//sp.org/myresource
  time1102260120
• The client is redirected to this location after
  requesting a protected resource at the SP without
  a security context

36
Shib Browser/POST Profile

• The Shibboleth Browser/POST Profile consists of
  eight (8) steps
• 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

37
Shib Browser/POST Profile
Identity Provider

• Browser/POST is an SP-first profile
• The IdP produces an assertion at step 4, which
  the SP consumes at step 5

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
Assertion Consumer Service
6
5
8
Resource
7
2
1
Service Provider
38
Shib Browser/Artifact Profile

• The Shibboleth Browser/Artifact Profile has ten
  (10) steps
• 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

39
Shib Browser/Artifact Profile
Identity Provider

• Browser/Artifact is SP-first, too
• This time the authN assertion is passed by
  reference
• The SP resolves the artifact into the assertion

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
Artifact Resolution Service
4
3
7
6
Assertion Consumer Service
8
5
10
Resource
9
2
1
Service Provider
40
IdP Discovery
41
Identity Provider Discovery

• Step 2 of the Shib browser profiles is
  problematic since the SP does not know the
  browser users 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

42
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 users preferred IdP
• redirects the client to the desired IdP
• A Shibboleth WAYF is usually interactive

43
Shib WAYF Service
Identity Provider
C L I E N T
Authentication Authority
Attribute Authority
SSO Service
8
7
WAYF
6
5
4
3
Assertion Consumer Service
10
9
12
Resource
11
2
1
Service Provider
44
WAYF Implementations

• A typical request to the InQueue
  WAYFhttps//wayf.internet2.edu/InQueue/WAYF?
  providerIdhttps//sp.org/shibboleth/
  shirehttps//sp.org/shibboleth/SSO
  targethttps//sp.org/myresource
  time1102260120
• InCommon also provides a WAYF servicehttps//way
  f.incommonfederation.org/InCommon/WAYF
• Implementation weaknesses
• User selection from a list does not scale
• No provisions for user maintenance of IdP
  preferences

45
InCommon Federation
46
Attributes
47
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

48
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

49
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

50
Browser/POST Attribute Pull

• The Shibboleth Browser/POST Profile with
  Attribute Pull has ten (10) steps
• 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

51
Browser/POST Attribute Pull
Identity Provider

• 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

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
7
6
Assertion Consumer Service
Attribute Requester
8
5
10
Resource
9
2
1
Service Provider
52
Browser/POST Attribute Pull Step 1
Identity Provider

• The Client requests a target resource at the SP

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
Assertion Consumer Service
Resource
1
Service Provider
53
Browser/POST Attribute Pull Step 2
Identity Provider

• 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

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
Assertion Consumer Service
Resource
2
1
Service Provider
54
Browser/POST Attribute Pull Step 3
Identity Provider

• The Client requests the SSO service at the IdP

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
3
Assertion Consumer Service
Resource
2
1
Service Provider
55
Browser/POST Attribute Pull Step 4
Identity Provider

• 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

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
Assertion Consumer Service
Resource
2
1
Service Provider
56
Browser/POST Attribute Pull Step 5
Identity Provider

• The Client issues a POST request to the assertion
  consumer service at the SP
• The authN assertion is included with the request

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
Assertion Consumer Service
5
Resource
2
1
Service Provider
57
Browser/POST Attribute Pull Step 6
Identity Provider

• 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

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
6
Assertion Consumer Service
Attribute Requester
5
Resource
2
1
Service Provider
58
Browser/POST Attribute Pull Step 7
Identity Provider

• The IdP returns an attribute assertion subject to
  attribute release policy
• The SP filters the attributes according to
  attribute acceptance policy

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
7
6
Assertion Consumer Service
Attribute Requester
5
Resource
2
1
Service Provider
59
Browser/POST Attribute Pull Step 8
Identity Provider

• The assertion consumer service updates the
  security context and redirects the Client to the
  target resource

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
7
6
Assertion Consumer Service
Attribute Requester
8
5
Resource
2
1
Service Provider
60
Browser/POST Attribute Pull Step 9
Identity Provider

• The Client requests the target resource at the SP
  (again)

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
7
6
Assertion Consumer Service
Attribute Requester
8
5
Resource
9
2
1
Service Provider
61
Browser/POST Attribute Pull Step 10
Identity Provider

• Since a security context exists, the SP returns
  the resource to the Client

C L I E N T
Authentication Authority
Attribute Authority
SSO Service
4
3
7
6
Assertion Consumer Service
Attribute Requester
8
5
10
Resource
9
2
1
Service Provider
62
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)

63
Attribute Acceptance Policy

• At step 7, the SP applies an Attribute Acceptance
  Policy (AAP.xml) to the received attributes
• Policy restricts what attributes can be asserted
  by whom
• Maps SAML attributes to HTTP headers
• At step 9, the resource uses the HTTP headers to
  make an access control decision

64
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

65
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

66
InCommon Attributes

• InCommons 6 highly recommended attributes

Attribute Name Attribute Value
givenName Mary
sn (surname) Smith
cn (common name) Mary Smith
eduPersonScopedAffiliation student_at_example.org
eduPersonPrincipalName mary.smith_at_example.org
eduPersonTargetedID ?
(eduPersonTargetedID does not have a precise
value syntax)
67
Metadata
68
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!