[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Artifacts : a slightly different (Shibboleth) perspective
Prateek, Believe me, I *had* read it through, as well as SAML draft-00 but I may be stupid because I don't get it. Line 497: "The SAML artifact must identify the relevant assertion to the destination site." In my opinion ([not a fact :-)]) this line indeed indicates dual-party interpretation. Then on line 485-490 I get even more puzzled as it says: "The destination site sends a <SAMLQuery> message to the source site, which includes information adequate to indentify a SAML assertion at the source site" Comment #1: The word "adequate" is not compatible with the word "interoperability" Comment #2: Why does a SAMLQuery contain an AssertionID that is only optional (an "implementation" as it is named on line 517) in the SAMLArt? I.e. What is a not-so-elementary SAML Artifact supposed to contain? If I where to design this on my own, I would make the SAMLQuery refer to an opaque, unique, crypto-safe artifact (ticket, reference or whatever it should be called). The artifact may contain an arbitrary byte sequence extension but even that must be a part of the SAMLQuery object. I see no need for type- codes either as it should be a one-party (domain) interpretation scheme. The one-time MUST on line 500 is IMO not a universal requirement. In many situations it is enough that the artifact creater/reader can verify that it is authentic (using HMAC or similar), and has not expired. Such schemes reduce the need for servers to store assertions for future references. CONCLUSION Anyway, after also reading Phills non-normative ticket description, I think that there should be a clear distinction between single-domain opaque artifact objects, and multiple-domain "compact" assertions as they serve *entirely* different purposes. It is either "the" object, or a "pointer" to the object. Anders R >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 >> ------------------------------------------------------------------ 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