locked
40103: Invalid authorisation token signature RRS feed

  • Question

  • BizTalk 2016, WebHttp-adapter, calling notification hub rest api.

    Using BizTalk 2016 and the WebHttp-adapter I'm trying to send a toast-message to the Azure Notification Hub using the REST API. I've configured the notification hub in Azure and have a SAS key name and value. I've used the values to configure WebHttp-adapter and are trying to call with POST a Rest api method to send a WNS Native Notification (https://msdn.microsoft.com/en-us/library/azure/dn223272.aspx).

    In BizTalk the call generates error (System.Net.WebException: The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was ''). When I examine the call in Fiddler the actual error is "40103: Invalid authorisation token signature" but from fiddler I can see that the Authorization -header is present and the format is the same as in the documentation.

    Still, using example code for generating the SAS token, I can generate a SAS signature with the same information that I can use to call the rest api from Chrome using Postman.

    I just cannot figure out what I'm doing wrong in BizTalk or is BizTalk generating an invalid SAS token?
    Any help appreciated!

    Wednesday, December 21, 2016 12:24 PM

Answers

  • Thanks for the suggestion, I did this and compared the headers in Fiddler.

    The main difference is that the headers are in a different order but otherwise the same. The exception is the Authorization -header with the SharedAccessSignature -information. It looks the same except that the sig-part is different.

    For SOAP-UI I generated the SharedAccessSignature -using code found here:
    https://code.msdn.microsoft.com/Shared-Access-Signature-0a88adf8

    The sig-parameter looks different when generated by BizTalk but I suspect that is because the generation time is different(?).

    So, I used the code in the link to generate a new Authorization -header with the SharedAccessSignature -information, copied that as static header in the WebHttp -adapter Message -tab settings and disabled SAS on the Security -tab.

    And it worked! I got the same response as when sending using Soap-UI or Postman.

    Is there a bug in the BizTalk WebHttp -adapter implementation or what's going on?

    • Marked as answer by DotNetLarry Sunday, February 17, 2019 9:09 AM
    Wednesday, December 21, 2016 2:58 PM

All replies

  • Try your tests from SOAP UI via Fiddler and note the traffic headers .

    Run the same test via BizTalk via Fiddler and note the headers. Compare those. You will definitely be finding some differences. 


    Pi_xel_xar

    Blog: My Blog

    BizTalkApplicationDeploymentTool: BizTalk Application Deployment Tool/

    Wednesday, December 21, 2016 2:07 PM
    Answerer
  • Thanks for the suggestion, I did this and compared the headers in Fiddler.

    The main difference is that the headers are in a different order but otherwise the same. The exception is the Authorization -header with the SharedAccessSignature -information. It looks the same except that the sig-part is different.

    For SOAP-UI I generated the SharedAccessSignature -using code found here:
    https://code.msdn.microsoft.com/Shared-Access-Signature-0a88adf8

    The sig-parameter looks different when generated by BizTalk but I suspect that is because the generation time is different(?).

    So, I used the code in the link to generate a new Authorization -header with the SharedAccessSignature -information, copied that as static header in the WebHttp -adapter Message -tab settings and disabled SAS on the Security -tab.

    And it worked! I got the same response as when sending using Soap-UI or Postman.

    Is there a bug in the BizTalk WebHttp -adapter implementation or what's going on?

    • Marked as answer by DotNetLarry Sunday, February 17, 2019 9:09 AM
    Wednesday, December 21, 2016 2:58 PM