Title: Message
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 3.3.2.3 Element <AttributeQuery>:
“In response to an
attribute query, a SAML authority returns assertions with attribute statements
as follows:
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 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.
Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:
From: Thomas
Wisniewski [mailto:]
Sent: Monday, March 28, 2005 11:44
AM
To:
Subject: [security-services]
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
or NONE>
Thanks, Tom.
