Shibboleth A Technical Overview

1. ShibbolethA Technical Overview Tom Scavotrscavo@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 OASIS E-Auth Shibboleth Educause Liberty 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 details:S. 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.internet2.edu/ • Guanxihttp://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!

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-overview-1.1-cd • SAML on Wikipediahttp://en.wikipedia.org/wiki/SAML

13. Background References • Shibboleth Technical Overviewhttp://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-latest.pdf • Shibboleth Protocol Specificationhttp://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-latest.pdf • SAML 2.0 Metadata Specificationhttp://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

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: • 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)

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

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 C L I E N T UIUC 4 InQueue 1 6 7 2 5 OSU 8

21. Shib Browser Profile • InQueue provides a “Where Are You From?” service • The user chooses their preferred identity provider from a menu 3 C L I E N T UIUC 4 InQueue 1 6 7 2 5 OSU 8

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 C L I E N T UIUC 4 InQueue 1 6 7 2 5 OSU 8

25. Shib Browser Profile • After validating the assertion, the wiki retrieves user attributes via back-channel Shib attribute exchange 3 C L I E N T UIUC 4 InQueue 1 6 7 2 5 OSU 8

26. 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 trscavo@uiuc.edu • The latter is eduPersonPrincipalName, an identity attribute asserted by the user’s 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 eduPersonPrincipalName)

28. Shibboleth Components

29. 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 Identity Provider 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 URL:https://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 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

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 • Browser/POST is an SP-first profile • The IdP produces an assertion at step 4, which the SP consumes at step 5 Identity Provider C L I E N T Authentication Authority SSO Service Attribute Authority 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 • 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 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 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

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 user’s 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 SSO Service Attribute Authority 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 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/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]