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
--
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
|
|
Oracle is committed to developing practices and products that
help protect the environment |
