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 Attributesand Determining Access

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

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

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

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)

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

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

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

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?

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

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.

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

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?

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”

Choices Abound

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.

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

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!

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.

“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!

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

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

“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

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

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

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

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.

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

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.

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)

Shibboleth: Technical Architecture