Re: [security-services] proposed change to POST profile: send Responseinstead of Assertion

["Eve L. Maler" <eve.maler@sun.com>]

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