Shibboleth: Technical Architecture Marlena Erdos and Scott Cantor Revised Oct 2, 2001 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 Attributes and 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 Authority Responding 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 Authority Responding 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 Authority Management 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 Authority Security 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 SHIRE Indexical 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 SHIRE Handle 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 SHAR Attribute 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 SHAR Using 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 SHAR Caching 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 WAYF Where 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 Implementation Where’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 Implementation SAML 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 Implementation To 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)