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] | [List Home]

Subject: JIRA SECURITY-6 PE: Conflict with core in SSO profile on returningerror Responses to SP

My apologies for missing the April 6 call, but something in the minutes caught my eye:


SECURITY-6 in the JIRA instance is an issue that came up in the 

Kantara profiling work.  There have been many requests regarding 

making IdP's respond better to SP's with SAML status errors, rather 

than holding up the user at the IdP.  There is questionable language 

in the specs that is somewhat mutually contradictory, and Scott wants 

to clean up the language with a little more guidance for implementers 

to encourage developers to get the user back to the SP.  This would 

better reflect the intent of the original specification.


Bob Sunday had some wording that Scott softened in order to make sure 

it didn't introduce new normative requirements.  Unless there are any 

objections to that text, Scott will consider the errata accepted, and 

it will make its way into the next errata working draft.




After some debate with Scott via the JIRA entry, it appears this item may need further discussion on the list before a resolution is reached. My comments:


In my opinion the proposed change to the SAML 2.0 Profiles text introduces language that obscures what I consider to be an important distinction between the circumstances in which an IdP should make every effort to return the user to the SP and circumstances in which it should not. Specifically, when the IdP cannot or will not satisfy the AuthnRequest (due to policy restrictions, user login failure, internal error condition, etc.) , the IdP should be strongly encouraged to get the user back to the SP for error handling.


However, when the IdP finds a fatal problem with the AuthnRequest message itself, such as signature verification failure and/or inability to verify the ownership of an included AssertionConsumerService URL, then the IdP should not respond to what may very well be a rogue or hacked SP. The language "under any circumstances within its control" blurs this distinction, and compromises the intent of security-related processing rules described in SAML 2.0 Core.


I think that if deployers want the option to prioritize user experience over protocol security, that should be taken up between deployers and implementers in the context of product feature requirements, not via the SAML 2.0 Profiles spec.


I agree that there is a conflict between the current texts in Core and Profiles in terms of MUST vs. SHOULD, but if that can be resolved without changing the underlying nature of the guidance to implementers, I think that would be a cleaner result.





Ari Kermaier | Senior Software Development Manager
Phone: +1 212 508 7912
Oracle Oracle Identity Management Product Development
520 Madison Avenue, 30th Floor | New York, NY 10022

Green Oracle

Oracle is committed to developing practices and products that help protect the environment


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