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

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

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”

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

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”

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

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

Simplified Flow

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.

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

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

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

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

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)

Acquiring a handle

The Whole Flow

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

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

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

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

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

Artifact Creation and Use • Handle Server • SHIRE

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

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

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)

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

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.

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.

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

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.”

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.

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

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

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!

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!

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 ...

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?

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)

Shibboleth: How It Relates to SAML