OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

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

(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

(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"

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC