[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Indexical problem in Shibboleth
Solving the Indexical Problem in Shibboleth:
An informational note for OASIS SAML participants
Introduction/
This note will try to lay out for OASIS SAML participants how Shibboleth
solves the so-called "indexical problem". In our case the situation
boils down to a destination website obtaining a set of attributes that
"belong" to browser user that is trying to access a resource at the
destination -- and being sure that the attributes really are associated
with the user.
This note assumes that the reader is very knowledgeable about SAML:
its entities, its terminology etc. Also, this note won't lay out all
of Shibboleth, but rather only those details that are relevant to
exploring the indexical problem. (And frankly, these details are in
flux. Among other things, we are rethinking the "relying party" portion
hof the architecture.)
The rest of the document consists of:
Background on Shibboleth and its architecture,
Messages flows that "solve" the indexical problem (we hope! :-))
Security Considerations i.e. how we can be broken.
Background on Shibboleth/
Shibboleth is a system (still being designed) for the secure exchange
of interoperable authorization information between federating sites. Our
fundamental scenario is that of a browser user who is affiliated with an
"origin site" wishing to access a resource at a "destination". The
destination PEP will make an access decision based on the user's
attributes (possibly but not necessarily including 'user name').
Shibboleth differs from SAML in that our system includes a design for
the attribute authority (AA) that address certain privacy concerns: The
Shibboleth AA includes a model of specifying destination resources such
that the user can control which attributes are released to each resource.
(This note however will not go into detail on the AA. (If you'd like to
know more, contact me, Marlena Erdos, at marlena@us.ibm.com. I can send
you my PowerPoint presentation on the AA.))
Attributes are obtained from an AA at the origin site. The entity
at the destination site that engages in the Shibb protocol and makes the
attribute request is called a "Shibboleth Attribute Requestor" or SHAR
(rhymes with 'tar') for short . The SHAR will pass on attributes to the
relevant PEP (though that won't be further discussed in this note).
Both the AA and the SHAR have public key identities and hence can sign
the messages and tokens they exchange.
The origin site also has a "Web Login Service" component that
functions similarly to the SAML authentication authority. The difference
is that the assertion that actually identifies the user is consumed by
the AA and never by the SHAR (or PEP). This note will continue to say
"Web Login Service".
Finally, Shibboleth has the notion of a "Where Are You From" service
(WAYF) that lives "somewhere" in the Internet. This service interacts
with the user at least once to find their origin site. Its use will
become clear in the message flows.
Message Flows/
1. The browser user enters a URL for the desired resource.
2. The destination web server/SHAR determines that the desired resource
is access controlled but there is no context information about the user
accompanying the request. The SHAR redirects the user to the "Where
Are You From (WAYF) service, appending the URL for the destination
resource.
3. The WAYF service determines that the user has not used WAYF before.
It presents the user with a web form, and asks the user to identify their
origin site. (We intend to allow casual institutional names like "Brown",
in addition to more formal "neticized" ones like "brown.edu")
4. The user selects (or types) their site name, and clicks "Go There!".
The WAYF server optionally creates a cookie to remember the user's origin
site, and then redirects the user to their origin site's local Web Login
Server, appending the resource URL.
5. The origin site's local WebLogin Server determines that the user
has not yet authenticated. It presents the user with a web form.
6. The user enters their userid and password (or does whatever the site
requires), and clicks "Submit".
7. The origin Web Login Server, authenticates the user, using the local
methodology. If authentication fails, the origin WLS presents the user
with an error screen, and the user gets to try again.
8. When authentication succeeds, the origin WLS sends a request to the
origin Attribute Authority (AA), passing along the user's local principal
identity. (We expect to use the SAML authentication assertion to hold the
user's principal identity.)
9. The AA generates a token called an "Attribute Authority Subject
Identifier" or AASID (pronounced "acid"). The AASID will be used by
the destination SHAR to create the request for attributes about 'this'
user. This AASID contains
- a handle for the user that is meaningful only to the AA.
- information about the AA so that the SHAR can make the attribute
request.
- the DNS name of the SHAR (to prevent a malicious SHAR from
masquerading as the user to another SHAR)
- the IP address of the user (to make use of a stolen AASID a bit more
difficult)
- a relatively short validity period (on the order of minutes rather
than hours)
After signing the AA, the AA sends it to the origin WLS.
10. The origin WLS then redirects the user back to the destination,
appending the AASID object to the destination resource URL
11. The user arrives back at the destination SHAR. The SHAR determines
that the desired resource is access controlled and there is an AASID
object accompanying the request.
12. The SHAR validates the signature on the AASID object, checks that
the DNS name in the AASID is its own name, that the IP address in the
AASID matches the IP address of the request, and that the validity period
is OK. If all these checks pass, it extracts the user handle.
13. The SHAR builds the attribute request message directed to the origin
AA. At this point in time, the only allowable request is "Give me all
appropriate attributes". We do not currently allow the SHAR to request
specific attributes. Included in the request is the user handle that
was in the AASID, and the URL that the user originally passed in. The
SHAR signs this request and sends it off (over a TBD protocol).
14. The AA checks the signature on the request message, then obtains
the user handle and the resource URL. It also checks that the SHAR is
a legitimate speaker for the resource represented by the URL.
15. The AA does a "best fit" match of the target URL and SHAR name
against the entries in the user's "attribute release" policy set. It gets
the attribute release information associated with the best fit and the
corresponding attributes of the user.
16. The AA then creates the attribute response message, sending back
the attributes and a validity period.
17. The SHAR receives the attribute response, does checks on the
signature etc, and obtains the user's attributes. The SHAR then creates a
cookie, scoped just to this server, containing the AASID object.
18. The SHAR sends on the user's request and user's attributes to the
PEP. [Actually, we have some other steps here -- to deal with mapping the
attribute into privileges appropriate for the PEP/PDP, but that isn't
relevant to the indexical problem, so I've left it out.]
The Second Time Around
The next time the user contacts the destination, the destination will
received the AASID that was stored as a cookie. The SHAR can either
make another attribute request or use the user handle to find attributes
that it has cached. If the validity period of the AASID is expired,
that should be taken as "advice" to the SHAR that it might be wise to
obtain a new AASID.
Security Considerations/
If the AASID is "stolen" and the stealer can modify their IP address to be
that contained in the AASID, and do this within the validity period of the
AASID, the stealer will have all the attributes and associated rights of
the user. To mitigate the possibility of stealing and misuse, we suggest
the following guidelines to implementers:
SSL must be used by all SHARs to prevent eavesdropping on the
AASID.
The AASID cookie should be a "memory cookie" that disappears when
the browser exits.
SHARs should pay attention to the validity period in the AASID.
That is it! We have another message flow that also solves the
indexical problem but doesn't yield a user handle that could be
used for new attribute requests. I'll send this along later.
Comments welcome of course. I apologize for the lack of pictures.
(I am graphic-tool challenged.)
Regards,
Marlena
PS David Wasley (UCal) is the person most responsible for the creation of
these flows. He got assistance from (in alphabetical order): Steven
Carmody (Brown), Marlena Erdos (Tivoli), Keith Hazeltine (UWMadison),
RL Bob Morgan (UWashington). All of us have participated in creation
of the model -- and we've gotten help from other Shibboleth participants,
notably Michael Gettes (Georgetown), Ken Klingenstein (Internet2), and
Scott Cantor (OhioState).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC