Transcript Shibboleth: Technical Architecture Marlena Erdos and Scott Cantor Revised Oct 2, 2001

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
2
Establishing a User Context
3
Getting Attributes
and Determining Access
4
Outline
The View from Above
Detailed Component Descriptions
“Club Shibboleth” and Initial Implementation
5
Detailed Component Descriptions
Attribute Authority
Handle Server
SHIRE
SHAR
WAYF
6
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
7
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
8
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)
9
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
10
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
11
Detailed Component Descriptions
Attribute Authority
Handle Server
SHIRE
SHAR
WAYF
12
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
13
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?
14
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
15
Detailed Component Descriptions
Attribute Authority
Handle Server
SHIRE
SHAR
WAYF
16
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.
17
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
18
Detailed Component Descriptions
Attribute Authority
Handle Server
SHIRE
SHAR
WAYF
19
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?
20
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”
21
Choices Abound
Destination
Architecture
5
Policy
Decision
Point
(PDP)
PEP
PEP
1
SHAR
****
SHIRE
7
Resource
Manager
Proxy
2
Attribute
Mapper
4
Resource
Manager
6
resources
3
Policy
Decision
Point
(PDP)
22
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.
23
Detailed Component Descriptions
Attribute Authority
Handle Server
SHIRE
SHAR
WAYF
24
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).
25
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!
26
Outline
The View from Above
Detailed Component Descriptions
“Club Shibboleth” and Initial Implementation
27
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.
28
“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!
29
“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.
30
“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.
31
“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
32
“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).
33
“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.)
34
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
35
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.
36
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).
37
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.
38
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)
39