[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] proposed change to POST profile: send Responseinstead of Assertion
This sounds pretty good at first blush. I hate to ask about this, but: It seems to create a limited sort of HTTP protocol binding for at least the back half of a SAML request-response protocol exchange; do we need to cover this in the bindings doc? Eve At 10:19 AM 1/29/02 -0800, RL 'Bob' Morgan wrote: >As we were developing the POST profile there was discussion about whether >features in the SAML assertion are sufficient to provide countermeasures >for the various threats that we recognize, or whether additional >"packaging" (to use Marlena's term) is needed. There were good reasons >why "packaging" would be useful but I think there was resistance to >developing some new structure just for this purpose. Hence we decided to >add the TargetRestriction condition to the Assertion, and to use a short >validity period in the Assertion, as major mechanisms to deal with >threats. > >This had been simmering with me before, but Stephen Farrell's comment: > > > - Inclusion of both Audience and Target conditions is pointless and > > broken. Delete one, or show they're different. > >pushed me over the edge; also recent changes to the Response object. In >this note I propose that we change the POST profile so that a SAML >Response object is sent rather than just an Assertion. This is in the >spirit of the former "packaging" idea but uses a standard already-defined >object (with one proposed change). I think those of us who care about the >POST profile would like to see this change be made. > >The details of the proposal are that (sorry no actual text yet): > >(a) the POST profile be modified so that the object sent in the POST is a >SAML Response > >(b) that this Response always be XML-DSIG-signed, and the contained >Assertion(s) need not be signed (but could be); > >(c) the TargetRestrictionCondition be removed from the Conditions element >in the Assertion and instead be made an optional element of the Response >object; > >(d) the new IssueInstant element of the Response be checked by the POST >receiver to ensure that the Response is recently-generated; > >(e) the InResponseTo attribute of the Response object be set to some >distinguished value indicating "not in response to a request", eg the >empty string. > >This would have the benefits of (at least): > >(1) This clarifies the distinction between Target and Audience, since >they're now attached to different objects. IMHO Target is more >appropriately applied to a Response object rather than the Assertion >anyway, since it's really a restriction on how-the-thing-was-sent rather >than the thing itself. > >(2) For both target-checking and timestamp-checking, having values in a >well-known single place in the single Response object is much more clear >than having to rely on Target/Validity values in the potentially many >Assertions that might be sent, which might have ambiguous values. > >(3) The validity period in a POSTed Assertion (or set of Assertions) can >be (somewhat) longer, hence it could be pre-generated; though we may still >want to suggest some short limit for the end of the Assertion validity >period. > >(4) A Response can be generated by the inter-site transfer site even when >an Assertion can not be (eg "user cancelled login operation") and can >communicate error conditions via Status, which otherwise can't be done. > >(5) POST and Artifact will both result in Responses being received by the >target, which permits much more consistency in their handling, greatly >easing implementations that want to support both. > >Possible objections (and responses to them) might be: > >(i) The proposed Response is not issued in response to a Request. This >doesn't seem like much of an argument to me. If the structure is useful, >let's use it; I think there are lots of existing protocols where >"unsolicited responses" exist for this same sort of reason. > >(ii) The IssueInstant which is to be added to the Response schema only >specifies what could be thought of as a start time for a validity period >for the Response, rather than both start and end as Assertion Validity >does. I do not think that this is a concern, because ultimately the >decision on length of time that the receiver is prepared to accept this >Response is up to the receiver; that is, if (under the current format) an >asserter puts in a Validity of, say, a 24-hour duration, a reasonable >receiver will still reject this after just a few minutes. So having only >an IssueInstant and letting the receiver base its decision on this seems >fine to me. Alternatively, if folks felt strongly, another value could be >added to the schema to express the end-of-validity time (but I think this >is unnecessary). > >Given the lateness of this I'm not going to suggest that this hold up Last >Call, but I think it needs to be considered ASAP. I will be working on >revised text (mostly for the Binding/Profile document) in any case. > > - RL "Bob" -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC