[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Artifacts : a slightly different (Shibboleth) perspective
Anders, Your statement >>The SAML solution (BTW, there seems to be two!) >>introduces unnecessary interoperability problems by variant >>structures and dual-party interpretation. is an error both in fact and interpretation. Kindly take the time to read Section 3.1 of bindings 0.4. As it stands your claims are a fact-free opinion. - prateek >>An artitfact should IMO be >>opaque for all "outsiders" while the proper user can typically decode >>a time-stamp and an instance-ID, besides verifying its signature. >> >>3. Artifacts can usually be replaced by the mechanism featured in >>VISA's 3D Secure payment system: >><HTML> >><BODY Onload="javascript:document.forms[0].submit ()"> >><FORM METHOD="POST" ACTION="Destination_Server_URL"> >><INPUT TYPE="HIDDEN" >> NAME="SAMLAssertion" >> VALUE="Base64-encoded SAML Assertion"> >></FORM> >></BODY> >></HTML> >>Going for the "real stuff" has several advantages over artifacts, >>such as room for full XML objects and not only public keys, >>but entire cert-paths. Reduced requirements on Server-state is also >>a factor to consider. >>. >>/Anders >> >>----- Original Message ----- >>From: "Marlena Erdos" <marlena@us.ibm.com> >>To: <security-services@lists.oasis-open.org> >>Sent: Wednesday, July 18, 2001 04:15 >>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-sh >>ibboleth-architecture-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 >> >> >> >>------------------------------------------------------------------ >>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