RE: [security-services] Status Code Response for an Invalid Principal

Title: Message

From: Thomas
Wisniewski [mailto:] 

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?

[RSP] That is how I currently interpret the text of the
spec.  Can anyone point to contrarian text that takes priority in this
scenario?

 

I would contend that they should be
treated the same and that sending back a Success with
no assertions is reasonable.

[RSP] I agree.

 

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).

[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.

 

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.