[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] FW: considering proposing a change to POST profile
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC