[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Artifacts : a slightly different (Shibboleth) perspective
I have scheduled a discussion of the Shib browser profile for our con-call on Thursday, August 9. Here are some notes from Marlena. -----Original Message----- From: Marlena Erdos [mailto:marlena@us.ibm.com] Sent: Tuesday, July 17, 2001 10:16 PM To: security-services@lists.oasis-open.org Subject: Artifacts : a slightly different (Shibboleth) perspective Dear SAMLers, I've been reading the bindings work on "artifacts" with interest. Shibboleth also has an artifact -- but its semantics are slightly different. And while Shibboleth covers a much narrower space than SAML needs to, I think the Shibboleth model may have some use in furthering the bindings works. Here is a discussion of Shibb and the Shibb artifact -- what it means and how it is used. Along the way I'll point out some differences from the current bindings model. A much fuller discussion of Shibboleth's use of artifacts can be found in the Shibboleth architecture document (draft!). The URL for that doc is: http://middleware.internet2.edu/shibboleth/docs/draft-erdos-shibboleth-archi tecture-01.pdf Firstly, Shibboleth only has a "web browser profile" -- and no other. Our model is of a user accessing a web resource over http(s). The user logs into their "home organization". The home organization hosts an attribute authority which issues attribute assertions in response to attribute queries. Shibboleth doesn't include an authentication authority or authentication assertions -- more about this shortly. Since Shibboleth has a large emphasis on user privacy, we had a conundrum: How can a relying party (RP) "securely" associate an attribute assertion with a user who is not identified to the RP? Our solution was for the home organization to send an "attribute query handle" in a secured package to the RP via a redirect through the user's browser. (We have two "paths" to get to this redirect. I don't want to make this note even longer, so please see the Shibb Arch doc for details.) The RP then uses the attribute query handle (which I'll just call a "handle" henceforth) to make request for an attribute assertion at the home organization's AA. That is, the handle serves as the "subject" of the request. Of particular note, is that the handle can *not* be said to refer to an existing assertion. Since Shibboleth allows a user to choose what attributes get released to each RP (including "name"), the AA will create different attribute assertions about a given user depending on the RP that is making the request. In Shibboleth, the handle refers to the user (albeit in an opaque way). The "secure package" for the handle, is akin to the SAML "artifact". We however have a specific format rather than an artifact framework. Also, the contents of our artifact are specifically aimed at foiling impersonation rather than eliminating replay per se. I'll send along an example of the handle package in a separate note. I'll also include an explanation of the impersonation attacks we try to defeat. To wrap up this note ... About authentication assertions: we don't have them in Shibboleth. The RP by virtue of receiving a valid handle package can infer that the user authenticated to their home organization. But that is it. It is possible for "login method" to be included as an attribute in the attribute assertion, though thus far we've been thinking about longer-lived attributes. About the "artifact": Thus far the documentation of the artifact says that the "assertion id" is used to get an authentication assertion. Is there any reason that the "id" couldn't be used to retrieve an attribute assertion? About anonymity: We achieve anonymity by using the opaque handle as the subject for the attribute query. SAML doesn't yet allow this (though Phill seemed amenable when I talked with him late last week). The returned assertion may or may not contain the user's identity. It depends on what the user has allowed the attribute authority to release. Comments? Questions? You can send them to me but I'll unfortunately be away from July 19 until Aug 5. (You might wish to refer Shibboleth-specific questions to Bob Morgan as he too is a Shibb designer.) Regards. Marlena ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: security-services-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC