[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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]