[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. Regards, Ari --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]