OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Title: Message

From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com]

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.



-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Tuesday, March 29, 2005 6:59 PM
To: Thomas Wisniewski; security-services@lists.oasis-open.org
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 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

From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com]
Sent: Monday, March 28, 2005 11:44 AM
To: security-services@lists.oasis-open.org
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]