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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: RE: [saml-dev] SOAP Basic Authentication Handling in SAML 1.1


 


From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Friday, January 14, 2005 6:01 PM
To: Darren Platt; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] SOAP Basic Authentication Handling in SAML 1.1

I’ve got a question about the correct behavior WRT Basic Authentication of the SOAP channel in SAML 1.1.

 

When a relying party and asserting party are configured to use Basic authentication for the SOAP channel, if the relying party sends a SOAP request to an asserting party without the header that includes the username and password, how should the asserting party respond?  Should it return a 401 or a 403?  At the interop event at the RSA show, we found that different implementations acted differently leading to issues with interoperability.   I couldn’t find any mention of the correct behavior in the SAML or SOAP specs.

[RSP] It’s not mentioned in SAML or SOAP specs because they rely directly on the underlying HTTP specs.

I don’t consider myself an HTTP protocol guru, but the relevant RFC’s seem pretty clear to me on this question… Does anyone have info to the contrary? 

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html (HTTP/1.1 Status Code Definitions) and http://www.ietf.org/rfc/rfc2617.txt (HTTP Authentication: Basic and Digest Access Authentication), I believe the correct response is 401. 

First, RFC 2616 describes 401 as:

-----------------------------------

10.4.2 401 Unauthorized:

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].

-----------------------------------

 

According to this, the 401 response is used whether or not the request included credentials to begin with.

 

And it describes 403 as:

-----------------------------------

10.4.4 403 Forbidden:

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

 

-----------------------------------

RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication) only talks about the use of a 401 and never mentions a 403.  When discussing the Access Authentication Framework (Section 1.2) used by Basic and Digest auth methods, it states:

-----------------------------------

 
   The 401 (Unauthorized) response message is used by an origin server
   to challenge the authorization of a user agent. This response MUST
   include a WWW-Authenticate header field containing at least one
   challenge applicable to the requested resource. 
...
   A user agent that wishes to authenticate itself with an origin
   server--usually, but not necessarily, after receiving a 401
   (Unauthorized)--MAY do so by including an Authorization header field
   with the request. 
...
   Both the Authorization
   field value and the Proxy-Authorization field value consist of
   credentials containing the authentication information of the client
   for the realm of the resource being requested. The user agent MUST
   choose to use one of the challenges with the strongest auth-scheme it
   understands and request credentials from the user based upon that
   challenge.
...
   If the origin server does not wish to accept the credentials sent
   with a request, it SHOULD return a 401 (Unauthorized) response. The
   response MUST include a WWW-Authenticate header field containing at
   least one (possibly new) challenge applicable to the requested
   resource. 

 

-----------------------------------

The only place that a SHOULD is mentioned is in the last paragraph.  But that is in response to credentials it doesn’t want to honor.  You asked what happens when the initial request doesn’t contain the Authz header.  I believe it should be a 401.

 <a href="http://www.avidware.net/">Windows 2003 Clustering Server</a>



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