1 / 43

Shibboleth: How It Relates to SAML

Shibboleth: How It Relates to SAML. Marlena Erdos Aug 27, 2001. Outline. What is Shibboleth? Why Shibboleth? (Shortened) High Level Architecture Artifact Creation & Use Connects & Disconnects with SAML. What is Shibboleth? (meta-information). A joint project of Internet2/MACE and IBM

Download Presentation

Shibboleth: How It Relates to SAML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Shibboleth: How It Relates to SAML Marlena Erdos Aug 27, 2001

  2. Outline • What is Shibboleth? • Why Shibboleth? (Shortened) • High Level Architecture • Artifact Creation & Use • Connects & Disconnects with SAML

  3. What is Shibboleth?(meta-information) • A joint project of Internet2/MACE and IBM • Internet2: a consortium of 200+ higher-ed institutions (e.g. MIT, Brown, Ohio State) • A system with an emphasis on higher-ed • A system very applicable to the B2B space

  4. What is Shibboleth?(Really!) • “A system for the secure exchange of interoperable authorization information which can be used in access control decisions ” • AuthZ info • name • attributes e.g. group, role, course membership

  5. What is Shibboleth?(Yet More) A system ... • with an emphasis on privacy • users control release of their attributes • partially based on the emerging SAML std • both narrower and broader • an example of “federated administration”

  6. Outline • What is Shibboleth? • Why Shibboleth? • High Level Architecture • Artifact Creation & Use • Connects & Disconnects with SAML

  7. Why Shibboleth? • [Slides about the benefits of Federated Admin removed.] • Higher Ed has privacy obligations • “FERPA” demands permission for PII release • General interest and concern in privacy • Shibboleth has privacy provisions “built in”

  8. Outline • What is Shibboleth? • Why Shibboleth? • High Level Architecture • Artifact Creation & Use • Connects & Disconnects with SAML

  9. High Level Arch Outline • Simplified Arch -- Getting Attributes • More Full Arch -- Getting Handles • Attributes • Attribute Release Policies

  10. Simplified Arch/FlowGetting Attributes • Browser User tries to access web resource • “Shibbolized” web server has no user context • “SHAR” part of server gets attrs from an AA • SHAR = SHibboleth Attribute Requestor • AA : Attribute Authority

  11. Simplified Flow

  12. More Full Arch/FlowGetting an artifact aka “handle package” • Privacy aspect of Shibb creates burdens • No (zero) identifying info on user initially • No “home site” info either • Shibbolized server must get a user handle • The “SHIRE” does this work Note: The following describes “first contact” rather than “local portal”. Both work.

  13. SHIRE • The part of the server that gets artifacts is “Shibboleth Indexical Reference Establisher” • “Indexical Reference” -> point at user • No identity • No description

  14. SHIRE (cont) • SHIRE uses http connection to point at user • SHIRE acquires artifacts securely • SHIRE passes the some of the artifact contents to SHAR • “handle” to use in a query • AA address info

  15. SHIRE Flow The SHIRE interacts with • WAYF to get user’s home institution info • Home institution’s “Handle Server”

  16. SHIRE/WAYF • WAYF = Where Are You From • WAYF • asks user for their home institution • retrieves handle server info of the home site • Handle server info: • IP address • PKI certificate or equivalent

  17. SHIRE/Handle Server • SHIRE asks handle server for a handle • “Point” to user via http redirect • Handle server interacts with • authentication system and user if necessary • AA (potentially)

  18. Acquiring a handle

  19. The Whole Flow

  20. High Level Arch Outline • Simplified Arch -- Getting Attributes • More Full Arch -- Getting Handles • Attributes • Attribute Release Policies • AQMs, ARPs, & Assertions

  21. Attributes • EPPN EduPerson Principal Name • From the EduPerson schema • e.g. StevenCarmody@brown.edu • Affiliation • Faculty, Staff, Student • MemberOfCommunity • GroupMembershipExt • allow for extension of attribute space

  22. Attribute Release Policies (ARPs) An ARP at an AA consists of • The destination SHAR's name • The attributes to be released to the SHAR • And optionally a URL (called a “target”) • Target refers to entire subtree of resources

  23. ARPs (cont) • User can have as many ARPs as needed • AA finds set of ARPs • Initial set based on SHAR making AQM • AA finds “best match” • AQM contains user’s requested destination URL • Requested URL compared with targets in ARPs

  24. ARPs, AQM, & Assertions • When AQM comes in ... • AA finds best fit ARP ... • ... creates or finds an assertion that fits the ARP! • Finds ARP based on user and SHAR • Finds user from handle!!! -> Handle is in the AQM

  25. Outline • What is Shibboleth? • Why Shibboleth? • High Level Architecture • Artifact Creation & Use • Connects & Disconnects with SAML

  26. Artifact Creation and Use • Handle Server • SHIRE

  27. Handle Server • Answers attribute query handle request • AQHR contains • SHIRE Name (FQDN) • URL that user typed (for the redirect)

  28. Handle Server (cont) • The AQHR is redirect thru the browser • HS must • figure out who the user is • can interact with user and authN system • create a handle that identifies the user to the AA (but to no one else) • Could encrypt principal id with AA’s public key

  29. Handle Server The response to the AQHR • version number of response • opaque user handle • FQDN of the requesting SHIRE • IP address of browser process • issue time of this response • AA contact information • FQDN of Handle Server • Signature (w/o certificate) (XSIG)

  30. SHIRE • Performs inpersonation checks • Possible threats include • malicious user pretends to be real user • malicious SHIRE pretends to be real user

  31. SHIRE (cont) • Malicious user counter-measure • IP address and issue time • Malicious SHIRE counter-measure • Intended SHIRE name • SHIRE checks counter-measure info against reality.

  32. Outline • What is Shibboleth? • Why Shibboleth? • High Level Architecture • Artifact Creation & Use • Connects & Disconnects with SAML

  33. Connects • Query & Assertion & Artifact formats • We want to use SAML query & assn format! • We want to be artifact framework compliant! Summary: Differences from current spec seem workable.

  34. Disconnects with SAML • Disconnects: • Semantics of the artifact • Where impersonation countermeasure info belongs • In the assertion or in packaging? • Requirement for an AuthN assertion • How to represent an anonymous browser user in the assertion

  35. Disconnects Semantics of the artifact: • Shibb: A handle that refers to a user plus counter-measure packaging. • Bindings doc: “A ‘small’, bounded-size [item], which unambiguously identifies an assertion” • Possible resolution: “The thing can be used to retrieve an assertion about the related browser user.”

  36. Connect within the Disconnect • Out of Band trust info for the source: • Bindings: “<PartnerID> is a four byte value used by the destination site to determine source site identity as well as the URL (or address) for the ‘assertion lookup service’. ” • Shib: Destination keeps lists of trusted Handle Services. But, “Assertion Lookup Service” addr info is carried in the handle package.

  37. Artifact Structure Framework for Artifacts: B64 rep of <TypeCode> <artifact contents>

  38. Artifact vs “Handle Package” • Bindings Instantiation of an Artifact <TypeCode> := 0x0001 <PartnerID> <AssertionHandle> • Handle Package [No type code -- yet!!] Name & Signature of Handle Service Opaque user handle plus Countermeasure Info AA contact information

  39. Disconnects • CounterMeasure Protection Placement • Shibb: Countermeasures are “in” the artifact and “package” the handle. • Bindings: Countermeasures are in the assertion & the assertion must be an AuthN assertion!! -e.g “Audience Restriction” • What about “Post-ed” assertions? • Marlena: Package the assertion just like the handle!

  40. Disconnect • Web Browser profiles currently *requires* an AuthN assn • Mar claims: • not really necessary for the “framework” • rather tied to the “001” type artifact • A Shib-like artifact is possible: ‘002’ • Different specifics to meet overall goals!

  41. Disconnects • Representation of anonymous browser user • In the query and in the assertion • Shibb hope: Query by handle • Shibb hope: Assertion Subject indicates ‘handle” (in some way) • Core doc says ...

  42. Disconnects (?) • Core Doc: Subject • Name • SubjectConfirmation • Assertion Specifier. • SubjectConfirmation • Confirmation Method -> Artifact (4.1.1) • Marlena: Which part of the artifact? What about new “types” of artifacts?

  43. THE END Shibboleth Acknowledgements: Design Team: David Wasley U of C; RL Bob Morgan U of Washington; Keith Hazelton U of Wisconsin (Madison);Marlena Erdos IBM/Tivoli; Steven Carmody Brown; Scott Cantor Ohio State Important Contributions from: Ken Klingenstein (I2); Michael Gettes Georgeton, Scott Fullerton (Madison)

More Related