[OPENAM-5260] Provide option to only sign Response when using HTTP-POST binding Created: 09/Dec/14  Updated: 20/Nov/16  Resolved: 23/Dec/14

Status: Resolved
Project: OpenAM
Component/s: SAML
Affects Version/s: 10.0.0, 10.0.2, 11.0.0, 11.0.2, 12.0.0
Fix Version/s: 10.0.3, 11.0.3, 12.0.1, 13.0.0

Type: New Feature Priority: Major
Reporter: Jonathan Thomas Assignee: Jonathan Thomas
Resolution: Fixed Votes: 0
Labels: release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to OPENAM-475 SAML2 HTTPPOST Profil: Assertion not ... Closed
is related to OPENAM-7055 Improved logic for POST binding Asser... Resolved
Support Ticket IDs:

 Description   

For HTTP-POST binding to when sending a response to SP the current behaviour is:

1) Sign the Response based on the signResponse (SP>Assertion Content >Post Response Signed) flag.
2) Always sign the Assertion.

This was based on original ``4.1.4.5 POST-Specific Processing Rules`` in SAML profiles spec saml-profiles-2.0-os.pdf states

Current https://www.oasis-open.org/committees/download.php/35389/sstc-saml-profiles-errata-2.0-wd-06-diff.pdf states

If the HTTP POST binding is used to deliver the <Response>, each assertion MUST be protected by a digital signature. This can be accomplished by signing each individual <Assertion> element or by signing the <Response> element.

Need to update behaviour in IDPSSOUtil.sendResponse() (POST-Binding) to
1) If signResponse = true sign the response and also sign the assertion only if signAssertion = true.

2) If signResponse = false the assertion must be signed (SP>Assertion Content > Artifact Response Signed)



 Comments   
Comment by Jonathan Thomas [ 09/Dec/14 ]

Introduced current behaviour.

Comment by Jean-Luc Le Corre [X] (Inactive) [ 23/Dec/14 ]

Hi,

Fix received and applied. Works now as expected.

Thanks,

Jean-Luc Le Corre

Comment by Jonathan Thomas [ 23/Dec/14 ]

Fixed with r12007 trunk, r12008 12.0.x, r12009 11.0.x, r12010 10.0.x

Generated at Sat Oct 24 00:35:19 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.