Subject: RE: [security-services] Status Code Response for an Invalid Principal
We really should clean this up a bit in the future as we have introduced some inconsistencies between processing behavior for queries and for web sso.
After going back and reviewing our current text, I believe the appropriate response for such an attribute query is a <Response> message with a Success status but no assertion. I’ve drawn this conclusion based on lines 1865-1871 of section 22.214.171.124 Element <AttributeQuery>:
“In response to an attribute query, a SAML authority returns assertions with attribute statements as follows:
The first bullet refers to the section 3.3.4 on Subject matching. All of the SAML-defined subject-based queries refer to this section. Tom indicates that the principal in his use case is “recognized” but is “invalid”. Lines 1962-65 of 3.3.4 state that:
“If the SAML authority cannot provide an assertion with any statements satisfying the constraints expressed by a query or assertion reference, the <Response> element MUST NOT contain an <Assertion> element and MUST include a <StatusCode> element with the value urn:oasis:names:tc:SAML:2.0:status:Success.”
I contend that, at least for queries, this is the proper response, according to the spec. This is consistent with the operational behavior that we’ve stated numerous times for SAML 1.x as well. I’m not saying we shouldn’t change it, but I believe that based on how the spec is currently written, this is the section that pertains to this scenario.
The use of the “UnknownPrincipal” secondary status code is described only within the AuthnRequest/Response processing rules. There, we state that if the responder doesn’t recognize the subject, then it MUST return an error <Status> and MAY return a secondary status of “UnknownPrincipal”. While it might be descriptive of this condition in a query, it is not prescribed in our spec for use in the Assertion Query/Request Profile and is not discussed in the core spec description of query processing. So we’ve introduced an inconsistency between queries and SSO.
Note that, AFAIK, if is permissible to pass a secondary status code with a top-level “Success” status. Thus if you wanted a reason why there was no assertion in the successful response, you could provide the secondary code.
No implementation should rely on the presence of a secondary code in either the success or error case. This is necessary since, as described on lines 1631-33, responders MAY omit secondary codes to prevent probing attacks using known to be erroneous queries.
Well, that’s my perspective anyway.