1 / 39

Shibboleth: Technical Architecture

Shibboleth: Technical Architecture. Marlena Erdos and Scott Cantor Revised Oct 2, 2001. Outline. The View from Above Detailed Component Descriptions “Club Shibboleth” and Initial Implementation. Establishing a User Context. Getting Attributes and Determining Access. Outline.

lisadbrown
Download Presentation

Shibboleth: Technical Architecture

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: Technical Architecture Marlena Erdos and Scott Cantor Revised Oct 2, 2001

  2. Outline • The View from Above • Detailed Component Descriptions • “Club Shibboleth” and Initial Implementation

  3. Establishing a User Context

  4. Getting Attributesand Determining Access

  5. Outline • The View from Above • Detailed Component Descriptions • “Club Shibboleth” and Initial Implementation

  6. Detailed Component Descriptions • Attribute Authority • Handle Server • SHIRE • SHAR • WAYF

  7. Attribute Authority • Responds to Attribute Query Messages (AQM) from SHAR • Allows for specification and management of ARPs • Not a directory, but works with institutional directories and databases to aggregate and export attributes in a controlled fashion

  8. Attribute AuthorityResponding to AQMs • Upon receipt of an AQM, the AA… • …checks to see if it understands the handle • i.e. can map between the handle and a user • …authenticates the AQM • …locates all ARPs that apply based on user, SHAR, and target URL • user ARPs • Institutional ARPs

  9. Attribute AuthorityResponding to AQMs • Once the AA has found the right ARP… • Check that the attributes and/or values specified in the ARP are valid for the user • attributes in ARP may be out of sync with reality (e.g. faculty member becomes a staff member) • Create the response message (AQM) • adheres to SAML format (more or less)

  10. Attribute AuthorityManagement of ARPs • The AA must provide ARP management tools/interfaces. • user APRs perhaps via “MyAA” web interface • institutional ARPs • administrative default policies and default attributes • default ARP when none apply • interfaces themselves are secured, of course

  11. Attibute AuthoritySecurity Considerations • Attributes sent will be used in authorization decisions • attributes are nearly as sensitive to the target as name/password would be • Auditing Candidates • modifications to "meta-policies" (e.g. policies about ARP precedence) • modifications to ARPs • modifications to the list of AA administrators • modifications to attribute data

  12. Detailed Component Descriptions • Attribute Authority • Handle Server • SHIRE • SHAR • WAYF

  13. Handle Server • Works with AA and local Web ISO system to associate a query handle with an authenticated browser user and generate a signed assertion • Performs its work in response to an Attribute Query Handle Request (currently an unauthenticated HTTP GET) • AQHR contains • SHIRE URL for acceptance of response via HTTP POST • URL of desired resource/service at destination

  14. Handle Server • Upon receiving a handle request, the HS must… • …figure out who the user is • can interact with the user and the origin site’s Web ISO system • …create a handle that identifies the user to the AA (but to no one else) • …log useful information?

  15. Handle Server • The response to the destination site is a signed SAML authentication assertion passed via HTTP POST, exact format and packaging TBD. • The opaque user handle is the “Subject” of the assertion. • We must also include: • Validity period of response (very short) • Validity period of handle (advisory) • URL of the SHIRE intended as recipient of assertion • IP address of browser process • AA location/binding information

  16. Detailed Component Descriptions • Attribute Authority • Handle Server • SHIRE • SHAR • WAYF

  17. SHIREIndexical Reference Establisher • Destination site component responsible for context/session establishment • Session establishment will commonly rely on traditional techniques (i.e. cookies). • The SHIRE accepts an assertion from a HS and associates the incoming handle with the session it creates.

  18. SHIREHandle Acceptance • Assertions containing handles are passed to SHIRE via an HTTP POST. • Checks are performed to prevent impersonation attacks. • Malicious user countermeasures include assertion validity time and client IP address (optional). • Malicious SHIRE countermeasure consists of the intended SHIRE’s URL (i.e. a SHIRE insures that it is the intended recipient). • SHIRE passes on “configured” info to SHAR • Organization name

  19. Detailed Component Descriptions • Attribute Authority • Handle Server • SHIRE • SHAR • WAYF

  20. SHARAttribute Requester • A SHAR makes attribute requests using the handle given it by the SHIRE. • Upon receiving a response (AQR), the SHAR… • …authenticates the response • …extracts the attributes • …checks attribute acceptance • e.g. can an AA at MIT issue attributes for Harvard?

  21. SHARUsing Attributes • Resource Managers must make access control decisions. • Legacy RMs typically: • expect particular attribute syntax • assume particular attribute semantics • Shibboleth attributes are in XML • Syntax and semantics are likely mismatched • Proxy RM can provide translation “glue”

  22. Choices Abound

  23. SHARCaching and App Domains • A SHAR must cache attributes, but care must be taken. • A user may want to release different attributes for different resources behind the same SHAR. • When accessing a different application domain, the cache should “miss” with a new AQM sent. • This is a potential problem area for Shibboleth.

  24. Detailed Component Descriptions • Attribute Authority • Handle Server • SHIRE • SHAR • WAYF

  25. WAYFWhere are You From? • The WAYF is the transition point from destination to origin site HS when users contact a destination first. • With no session in place, the SHIRE knows nothing about the user, so must either ask directly (SHIRE==WAYF) or redirect the user to a location that will ask on its behalf (SHIRE!=WAYF).

  26. WAYF • Users can respond to the WAYF by indicating in “colloquial” fashion which institution can authenticate them. • The WAYF will determine the URL of the appropriate HS based on the user’s input. • A variety of nasty semantic attacks lurk!

  27. Outline • The View from Above • Detailed Component Descriptions • “Club Shibboleth” and Initial Implementation

  28. Architecture vs. Implementation • The Shibboleth architecture specifies what messages must be authenticated, integrity protected and/or encrypted. • An implementation determines how the requirements are met and what trust policies are applied. • The implementation’s flexibility at run-time determines the degree of interoperability.

  29. “Club Shibboleth” • The Club defines one set of rules and policies that describe how messages will be protected, how trust will flow, and what the information means. • Any collection of collaborating sites must make these decisions (implicitly or otherwise) with any security technology. • The Club is not the only way to do Shib!

  30. “Club Shibboleth”Key Concepts • PKI technology will be used to protect message exchanges for the initial implementation. • The SHAR, HS, and AA have public DNS-style names that can be embedded in the Subject field of X.509 certificates. • A set of CAs will be designated as trusted by the Club to reduce certificate preconfiguration. • Expected names are validated against certificate Subjects to perform authentication of messages.

  31. “Club Shibboleth”Trust Flows from the HS • Each SHIRE is configured with a list of “valid” HS names and the organization names they speak for. • An incoming assertion from a HS includes the signing certificate and is validated against the list of trusted HS names. • The HS provides the name and location of one or more AAs the SHAR can use.

  32. “Club Shibboleth”Transitive Trust • Recall the SHIRE gives the SHAR a handle, the name of one or more AAs to query, and the origin site’s name. • A SHAR trusts an AA named “aa.foo.edu” because a SHIRE tells it to do so; a SHIRE does this because it trusts the HS it got the name from. • Thus, trust is transitive: • SHAR trusts SHIRE trusts HS trusts AA, ergo SHAR trusts AA

  33. “Club Shibboleth”Does the AA trust the SHAR? • Can anybody with a trusted certificate request attributes? YES • An AA trusts any SHAR only in that it trusts the target URL inside the request and that attributes won’t be misused. • The default ARP for an arbitrary SHAR should be very tight (no leakage means no cost for misuse).

  34. “Club Shibboleth”Signing and Verification • All signed messages are accompanied by a certificate. • The certificate’s Subject matches the name of the entity doing the signing. • In all but one case, certificate validation relies on evaluating that certificate’s signer against a set of trusted signers. • (The exception is the HS->SHIRE flow.)

  35. Initial Implementation • To get code written and pilots deployed, various simplifying assumptions have been made or are being discussed: • WAYF integrated with SHIRE • SAML alignment a best-fit effort • SHAR/AA communicate via TLS/SSL without extra signing

  36. Initial ImplementationWhere’s the WAYF? • Implementing the WAYF well requires some effort, so a decision was made to require each SHIRE to implement this functionality. • Each SHIRE will know a set of origin site names and the associated HS URL for all pilot participants. • When first access is trapped, the user will indicate their origin site to the SHIRE and then be sent to the HS they choose.

  37. Initial ImplementationSAML • SAML drafts are not expected to meet 100% of Shibboleth’s needs in the short run. • Message formats and exchanges will be tightly encapsulated to allow easy revision for greater compliance (this is good design anyway).

  38. Initial ImplementationTo Sign or Not to Sign… • XML Signature implementations are rare. • SHAR requests to the AA MUST be authenticated, and MAY be encrypted. • AA responses to the SHAR MUST be authenticated and MUST be encrypted. • An HTTPS connection with certificates at both ends meets both requirements without the explicit use of signed XML. • Assertions from HS MUST still be signed.

  39. THE END • 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