[security-services] FW: considering proposing a change to POST profile

["Mishra, Prateek" <pmishra@netegrity.com>]

Details of proposed changes to the Form POST profile. 
Please note we have agreed to the changes in principle,
these are the actual proposed changes.

- prateek


My note a couple of weeks ago:

  Date: Tue, 29 Jan 2002 10:19:03 -0800 (PST)
  From: RL 'Bob' Morgan <rlmorgan@washington.edu>
  To: OASIS Security Services TC <security-services@lists.oasis-open.org>
  Subject: [security-services] proposed change to POST profile: send
           Response instead of Assertion

http://lists.oasis-open.org/archives/security-services/200201/msg00238.html

proposed some changes, and below I offer text for this purpose.  I think
there has been consensus to make these changes.  Note the changes are
based on core-25 and bindings-09.  Possibly controversial points are:

 * I changed the name of the attribute from "Target" to "Recipient", since
   there was confusion with TARGET in the http: URL.  Could be that
   "Intended-Recipient" would be better ...

 * When it was part of Conditions, Target could be multiple.  As an
   attribute of the ResponseAbstractType there's only one Recipient.  I
   can't see why you'd need more than one Recipient URI, but maybe someone
   else can.

We have said that these changes could wait until after Last Call to be
made.  Given the current state of things I'm hoping they can be put in
for this week's doc revs, but I'll understand if they don't make it.

 - RL "Bob"

---

Updates to core-25 for modified POST profile

* in TOC, line 59:  remove

* in section 2.3.3.1.4, lines 491 - 510:  remove

* in section 3.4.1., insert after line 1067:

Recipient [Optional]
The intended recipient of this response.  This is useful to prevent
malicious forwarding of responses to unintended recipients, a
protection that is required by some use profiles.  It is set by the
generator of the response to a URI that identifies the intended
recipient.  If present, the actual recipient MUST check that the URI
identifies the recipient or a resource managed by the recipient.  If
it does not, the response MUST be discarded.

* in section 3.4.1., insert after line 1076:

  <attribute name="Recipient" type="anyURI" use="optional">

---

Updates to bindings-09 for modified POST profile

* lines 653-654 replace with:

Step 2: Generating and Supplying the Response

In step 2, the source site generates HTML form data containing a SAML
Response which contains an SSO assertion.

* line 665 replace with:

<INPUT TYPE= hidden  NAME= SAMLResponse  Value= B64(<response>) >

* lines 672-678 replace with:

Exactly one SAML Response MUST be included within the FORM body with
the control name SAMLResponse; multiple SAML assertions MAY be
included in the Response.  A single target description MUST be included
with the control name TARGET.  The notation B64(<response>) stands for
the result of applying the base-64 transformation to the assertion.
The SAML Response MUST be digitally signed following the guidelines
given in [section 5 of SAML-Core].  Included assertions MAY be
digitally signed.

* lines 683-685 replace with:

Step 3: Posting the Form Containing the Response

In step 3, the browser submits the form containing the SAML Response
using the following HTTP request.

* lines 691-700 replace with:

This consists of the form data set derived by the browser processing
of the form data received in step 2 according to 17.13.3 of
[HTML4.01].  Exactly one SAML Response MUST be included within the
form data set with control name SAMLResponse; multiple SAML assertions
MAY be included in the Response.  A single target description MUST be
included with the control name set to TARGET.

The SAML Response MUST include the Recipient attribute (SAML-Core,
section 3.4.1) with its value set to <assertion consumer host name and
path>.  If assertions are included in the Response, at least one
assertion MUST be a SSO Assertion.

* lines 722-723 replace with:

  <INPUT TYPE="HIDDEN"  NAME="SAMLResponse"
   VALUE="response in base64 coding">

* lines 766-769 replace with:

Countermeasure: The destination site MUST check the Recipient
attribute of the SAML Response to ensure that its value matches the
<assertion consumer host name and path>. As the assertion is digitally
signed, the Recipient value cannot be altered by the malicious site.

* lines 772-774 replace with:

Countermeasure:  The browser/POST profile requires the SAML Response to
be signed, thus providing both message integrity and authentication.
The destination site MUST verify the signature and authenticate the
issuer.