I agree with you that for
an SSO Response, this is handled differently
-- with a non-Success response. I think this is ok
and that the top level status should be Requester (and
[RSP] IMO, “Requester” is what we should use,
but the spec is non-specific on what the top-level code should be. It
just says the top-level code should be an “error <Status>”.
As Scott was saying on the call yesterday, whether it’s Requester or
Responder could be a matter of your point of view. If a Requester sends a
validly formatted subject but it can’t be processed by the Responder
because the identity isn’t present in the repository, is it the Requester’s
fault? What it the identity exists, but the responder just temporarily
can’t connect to the authority/repository to locate it? The
Requester sent the right subject, but the Responder couldn’t handle it. Should
the top level code in this case be Responder?
I wish we’d spent a bit more time debating the error
responses to be sent under these various scenarios and really nailed them down.
If we end up creating a specification conformance testing program for
SAML 2.0, we’ll end up having to do this.
Sent: Tuesday, March 29, 2005 6:59
To: Thomas Wisniewski; firstname.lastname@example.org
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
"In response to an
attribute query, a SAML authority returns assertions with attribute statements
- Rules given in Section 3.3.4 for matching against
the <Subject> element of
the query identify the assertions that may be returned.
- If any <Attribute>
elements are present in the query, they constrain/filter the attributes
and optionally the values returned, as noted above.
- The attributes and values returned MAY also be
constrained by application-specific policy considerations."
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
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.
From: Thomas Wisniewski
Sent: Monday, March 28, 2005 11:44
Status Code Response for an Invalid Principal
Hi, I wanted to ask what the consensus
was on the status code response value for an
Attribute Query where the Principal (NameID) is
recognized by the Attribute Authority but it is
"invalid" at the present time (e.g., the
account is suspended, deleted, locked, etc...) Should
the status codes returned be:
Requester -- UnknownPrincipal
Requester -- RequestDenied (seems like the
appropriate one given the options)
Requester -- <one of the others listed>
Requester -- <implementation specific