This blog explains what a third party must provide if they want to consume a service that implements basic authentication. I will use the example of a BizTalk WCF-Basic HTTP send adapter.
Configuring a WCF-Basic HTTP send adapter
Consider a classic BizTalk Server pattern where a WCF-Basic HTTP adapter posts a message to an external service.
Microsoft describes how to configure a WCF-Basic HTTP send adapter here. Simply without configuring authentication the configuration screens might look like this.
Configuring a WCF-Basic HTTP send adapter to use Basic Authentication
Last week someone came to me asking if BizTalk could send a username and password using basic authentication to this service. I said yes it comes out of the box. Indeed, every BizTalk Server developer knows you configure basic authentication like this.
Surprisingly, on sending a message to the newly authenicated third party service I got this error.
System.Net.WebException: There was no endpoint listening at https://thirdpartyservice/webservice/ediservice.asmx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
A HTTP status of 404 was returned shown in the Fiddler trace below.
At first this was puzzling. Why was the Authentication header missing? Two years ago posting about the same issue with WCF-WebHTTP adapter, I worked around this using the HTTP adapter. This time I dug deeper.
Troubleshooting Basic Authentication
Having recently built a service using basic authentication myself I pointed the WCF adapter to this service, capturing the Fiddler trace. This time basic authentication works and I saw the Authentication header. The 401 unauthorized is expected because I am using an invalid username and password.
More importantly there is a request before this response that also has a 401 HTTP status code. Note this request does not contain the Authentication header.
The Basic Authentication Process
Thus the process of “Basic Authentication” is :
- Client sends out the http request to server
- The server challenges the client by sending back a “401 unauthorized” response.
- If the client wants to authenticate itself it sends an http request with the “Authorization” header to server
- If credentials are valid, then connection succeeds; or failed with a “403” response
The WCF-Basic HTTP adapter does not send an authentication unless the site requires basic authentication. In the case of the third party service it did not send subsequent request with an authentication header because the first the HTTP status of the first response was 404 and not 401. If a 401 response was recieved a subsequent request would have tried include the Authentication header. Following a 200 response was then the adapter will continue to send requests with the Authentication header.
Conclusions
The third party service was not implementing basic authentication correctly and that is why our requests failed. The correct HTTP status codes must be returned, 401 Unauthorized and 403 Forbidden. See https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/basic-authentication. Furthermore this was probably also why the WCF-WebHTTP adapter failed in my previous post.
