Shibboleth-intro-dec051 Shibboleth A Technical Overview Tom Scavo [email protected] [email protected] NCSA

shibboleth-intro-dec05 1

ShibbolethA Technical Overview

Tom [email protected]

NCSA

mailto:[email protected]


What is Shibboleth?• 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 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


Collaborations

Shibboleth

Internet2

E-Auth

Liberty

Vendors

OASIS

Educause


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.

http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-latest.pdf


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


The Shibboleth Experience


The Shibboleth Wiki• For example, the Shibboleth wiki (hosted at

ohio-state.edu) is “shibbolized”:https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/WebHome

• 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

https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/WebHome




Shib Browser Profile• The user clicks

the link “Login via InQueue IdP”

• This initiates a sequence of steps known as the Shibboleth Browser Profile

7

8

6

5

UIUC

OSU

CLIENT

3

4

2

1

InQueue



Shib Browser Profile• InQueue

provides a “Where Are You From?” service

• The user chooses their preferred identity provider from a menu

7

8

6

5

UIUC

OSU

CLIENT

3

4

2

1

InQueue



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

7

8

6

5

UIUC

OSU

CLIENT

3

4

2

1

InQueue



Shib Browser Profile• After validating

the assertion, the wiki@OSU retrieves user attributes via back-channel Shib attribute exchange

7

8

6

5

UIUC

OSU

CLIENT

3

4

2

1

InQueue


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


OpenIdP.org• By design, a user with an account at an

institution belonging to InCommon, InQueue, or SDSS can log into the wiki:https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/WebHome

• Other users can register at openidp.org, which is a zero-admin Shibboleth IdP

• The openidp asserts an alternate form of identity (email addresses as opposed to eduPersonPrincipalName)




Shibboleth SSO Profiles


Identity Provider

Service Provider

The Actors• 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

AuthenticationAuthority

AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

ArtifactResolution

Service

AttributeRequester


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


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


8

7

1

2

5

6

3

4

Identity Provider

Service Provider

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

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource


Attributes


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


Browser/POST Profile• 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

10

9

1

2

5

8

3

4

Identity Provider

Service Provider

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

AttributeRequester

7 6


1

Identity Provider

Service Provider

Browser/POST Step 1• The Client

requests a target resource at the SP C

LIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource


2

1

Identity Provider

Service Provider

Browser/POST 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

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource


3

2

1

Identity Provider

Service Provider


requests the SSO service at the IdP C

LIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource


4

3

2

1

Identity Provider

Service Provider

Browser/POST 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

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource


4

3

5

2

1

Identity Provider

Service Provider

Browser/POST Step 5• The Client issues

a POST request to the assertion consumer service at the SP

• The authN assertion is included with the request

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource


6

4

3

5

2

1

Identity Provider

Service Provider

Browser/POST 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

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

AttributeRequester


7 6

4

3

5

2

1

Identity Provider

Service Provider

Browser/POST Step 7• The IdP returns an

attribute assertion subject to attribute release policy

• The SP filters the attributes according to attribute acceptance policy

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

AttributeRequester


1

2

5

8

3

4

Identity Provider

Service Provider

Browser/POST Step 8

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

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

AttributeRequester

7 6


9

1

2

5

8

3

4

Identity Provider

Service Provider


requests the target resource at the SP (again) C

LIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

AttributeRequester

7 6


10

9

1

2

5

8

3

4

Identity Provider

Service Provider

Browser/POST Step 10

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

CLIENT


AttributeAuthority

SSOService

AssertionConsumer

Service

Resource

AttributeRequester

7 6


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


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


InCommon Attributes• InCommon’s 6 “highly recommended” attributes:

Attribute Name Attribute Value

givenName Mary

sn (surname) Smith

cn (common name) Mary Smith

eduPersonScopedAffiliation [email protected]

eduPersonPrincipalName [email protected]

eduPersonTargetedID ?

(eduPersonTargetedID does not have a precise value syntax)

Documents

Shibboleth-intro-dec051 Shibboleth A Technical Overview Tom Scavo [email protected] [email protected] NCSA