Shibboleth: Technical ArchitectureShibboleth: 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 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

SHAR

****SHIRE

ResourceManager

resources

AttributeMapper

ResourceManager

Proxy

PolicyDecision

Point(PDP)

PEP

PolicyDecision

Point(PDP)

PEP

1

2 3

4

5

67

DestinationArchitecture

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)