One of my colleagues Aravindh came to me on Thursday to tell me that he could not get HTTP basic authorisation working using the WCF-WebHttp adapter. My first response was you have got to be joking! I was astonished at the edge case that he showed me. This article highlights this gotcha that you might run into if you are posting to REST endpoint with BizTalk Server and a workaround. The rest of the discussion is based on the behaviour we have seen with BizTalk 2013 R2 CU5. We have not checked BizTalk 2016.
Setting up basic authorisation starts with configuring the adapter on the screen below.
Clicking on configure, selecting the security tab you can then configure the security mode as shown.
Clicking the Edit button you get to a screen to add the username and password. Saving through all the screen adds the send location to the runtime.
This is how Aravindh had configured his send port. He proceeded to show me that Postman could successfully post a message to the REST endpoint because it added a authorisation header. On the other hand sending the same message from his BizTalk WCF-WebHTTP adapter did not add the authorisation header and the a send failure occurred. This is shown in the Postman screenshot and the Fiddler capture from the WCF-WebHttp adapter.
Header content from Postman:
Header content from BizTalk(WebHTTP Adapter):
What is going on here? I thought about for awhile and then the penny dropped. I suggested that Aravindh should try the old classical HTTP adapter. Indeed the fiddler trace shows that an authorisation header is added as required.
Header Content from BizTalk (Classic HTTP Adapter):
Enabling SSL on the endpoint made no difference to the behaviour of the WCF-WebHttp adapter. Finally adding the authorization header to the OutboundHttp headers as shown below, allowed us to send a request to the endpoint using the WCF-WebHttp adapter.
In summary configuring client credentials on the WCF-WebHttp adapter does not send an authorisation header whereas the classical HTTP does. Although you could workaround this behaviour by adding the Authorization header to the Outbound HTTP header we decided to use the HTTP adapter instead. Furthermore the username and password could be stored securely in SSO in the case of the HTTP adapter.
Thanks to Aravindh Kathiresan for bringing this to my attention.
Note added 1/6/2020 – The above was probably because the service did not implement basic authentication properly. See https://www.connected-pawns.com/2017/04/09/wcf-webhttp-adapter-basic-authorisation/ for a explanation.
