Title: Message
Rob, are you saying that applying
the processing below (of sending a Success status
with no assertions) should be the same for both an "invalid"
subject and a subject that is not found?
I
would contend that they should be treated the same and that
sending back a Success with no assertions is
reasonable.
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
not Responder).
Tom.
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Tuesday, March 29, 2005
6:59 PM
To: Thomas Wisniewski;
Cc: Philpott,
Robert
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 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.
