Question

I’ve created a self-hosted WCF REST service (with some extra’s from WCF REST Starter Kit Preview 2). This is all working fine.

I’m now trying to add Basic authentication to the service. But I’m hitting some rather large roadblocks in the WCF stack which is preventing me from doing this.

It appears that the HttpListener (which self-hosted WCF services use internally at a low level in the WCF stack) is blocking my attempts to insert a WWW-Authenticate header on a self-generated 401 Unauthorized response. Why?

I can get the authentication working if I forget about this WWW-Authenticate header (which it seems Microsoft did as well). But that’s the issue. If I don’t send back a WWW-Authenticate header then the web browser won’t display its standard “logon” dialog. The user will merely be faced with a 401 Unauthorized error page with no way to actually log on.

REST services should be accessible to both computers and humans (well at least on the GET request level). Therefore, I feel that WCF REST is not complying with a fundamental part of REST here. Does anyone agree with me?

Has anyone got Basic authentication working with a self-hosted WCF REST service? If so, how did you do it?

PS: Obviously my intentions to use unsecure Basic authentication are on the premise that I’d also get HTTPS/SSL working for my service too. But that’s another matter.

PPS: I’ve tried WCF REST Contrib (http://wcfrestcontrib.codeplex.com/) and that has exactly the same issue. It appears this library has not been tested in self-hosted scenarios.

Thanks.

Answer 1

Unfortunately I have determined (by analysing the WCF reference source code and the help of the Fiddler tool for HTTP session sniffing) that this is a bug in the WCF stack.

Using Fiddler, I noticed that my WCF service was behaving unlike any other web site which uses Basic authentication.

To be clear, this is what SHOULD happen:

1. Browser sends GET request with no knowledge that a password is even needed.
2. Web server rejects request with a 401 Unauthorized status and includes a WWW-Authenticate header containing information about acceptable authentication methods.
3. Browser prompts user to enter credentials.
4. Browser resends GET request and includes appropriate Authentication header with the credentials.
5. If the credentials were correct, the web server responds with 200 OK and the web page.
   If the credentials were wrong, the web server responds with 401 Unauthorized and includes the same WWW-Authenticate header that it did in Step #2.

What was ACTUALLY happening with my WCF service was this:

1. Browser sends GET request with no knowledge that a password is even needed.
2. WCF notices there is no Authentication header in the request and blindly rejects request with a 401 Unauthorized status and includes a WWW-Authenticate header. All normal so far.
3. Browser prompts user for credentials. Still normal.
4. Browser resends GET request including the appropriate Authentication header.
5. If the credentials were correct, the web server responds with 200 OK. All is fine.
   If the credentials were wrong however, WCF responds with 403 Forbidden and does not include any additional headers such as WWW-Authenticate.

When the browser gets the 403 Forbidden status it does not perceive this to be a failed authentication attempt. This status code is intended to inform the browser that the URL it tried to access is off limits. It doesn’t relate to authentication in any way. This has the terrible side affect that when the user types their username/password incorrectly (and the server rejects with 403) then the web browser doesn’t reprompt the user to type their credentials again. In fact the web browser believes authentication has succeeded and so stores those credentials for the rest of the session!

With this in mind, I sought clarification:

The RFC 2617 (http://www.faqs.org/rfcs/rfc2617.html#ixzz0eboUfnrl) does not mention anywhere the use of the 403 Forbidden status code. In fact, what it actually has to say on the matter is the following:

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.

WCF does neither of these. It neither correctly sends an 401 Unauthorized status code. Nor does it include a WWW-Authenticate header.

Now to find the smoking gun within the WCF source code:

I discovered that in the HttpRequestContext class is a method called ProcessAuthentication, which contains the following (excerpt):

if (!authenticationSucceeded) 
{
   SendResponseAndClose(HttpStatusCode.Forbidden);
}

I defend Microsoft on a lot of things but this is indefensible.

Fortunately, I have got it working to an “acceptable” level. It just means that if the user accidently enters their username/password incorrectly then the only way to get another attempt is to fully close their web browser and restart it to retry. All because WCF is not responding to the failed authentication attempt with a 401 Unauthorized and a WWW-Authenticate header as per the specification.