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.

 

http://tools.oasis-open.org/issues/browse/SECURITY-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

 

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