Publish BizTalk Service over IIS

Article
1/17/2024

BizTalk orchestration published as a service using the WCF publishing wizard:

Secure Service:

To secure the service means the

The communication should be over HTTPS
No Anonymous access should be disabled over the Virtual Directory.

For authentication scheme we would target Windows / Basic Authentication

Now coming back to the stuff - There are two parts to this:

Enabling the Virtual Directory / Application in IIS to communicate over SSL.

1. Hooking a certificate to the Root Web Site to meet the requirement for SSL
2. Making the required changes in the associated web.config of the Virtual Directory.

Configuring the BizTalk Receive Location to set the required Security Level to match that of the Virtual Directory.

The steps would be targeted towards BizTalk Server 2010 / IIS 7.0

Enabling the Virtual Directory / Application in IIS to communicate over SSL

Enabling SSL on IIS

This would be a pretty straight step that we might be doing for enabling communication over SSL for any other website on IIS 7.0 . For more info / help on this refer to http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/#IISManager

Adding User Account to BizTalk Appication Users

This is an important step and often missed by people.

Please do not forget to add the User Account (Under which your client is running. For e.g. AppPool user in case of a Web Application or SharePoint hosted Application ) to the BizTalk Group - "Biztalk Application Users"

Modifying Web.Config

This is the most crucial part of the entire exercise and the one everyone seems to be missing on and face issues ( or at least I faced a lot)

To enable HTTPS following modifications need to be done in the web.config :

Open the web.config of the Virtual Directory

Comment out the 'mex' binding so that finally it looks like this

<services>



 <!-- Note: the service name must match the configuration name for the service implementation. -->



 <service name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance" behaviorConfiguration="ServiceBehaviorConfiguration">



 <!--<endpoint name="HttpMexEndpoint" address="mex" binding="mexHttpBinding" bindingConfiguration="" contract="IMetadataExchange" />-->



 <!--<endpoint name="HttpsMexEndpoint" address="mex" binding="mexHttpsBinding" bindingConfiguration="" contract="IMetadataExchange" />-->



 </service>



 </services>

If we don't comment out 'mex' binding we would get an error like this when we try to browse the service ( The one which killed most of my time)

Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service

2. Modify the *Service Behaviour -> serviceMetadata *section to enable https and disable http ( By Default it's like this httpsGetEnabled="false" httpGetEnabled ="true") so that post modification is should be like the following

 <serviceBehaviors>



 <behavior name="ServiceBehaviorConfiguration">



 <serviceDebug httpsHelpPageEnabled="true" httpHelpPageEnabled="false" includeExceptionDetailInFaults="false" />



 <serviceMetadata httpsGetEnabled="true" httpGetEnabled ="false"/>



 </behavior>



 </serviceBehavior>

With the default settings when we try to browse the service , we would probably be getting the followign error :

Could not find a base address that matches scheme http for the endpoint with binding WsHttpBinding. Registered base address schemes are [https]

Configuring the BizTalk Receive Location to set the required Security Level to match that of the Virtual Directory

Here , assuming that you would have created a Receive Location in your BizTalk Application using the *BizTalk WCF Service Publishing Wizard * while publishing the Orchestration as a Service , all we need to do is open the *Receive Location - > properties *and configure the WsHttpBinding Security settings as shown below .

While here I have selected the credential type as Windows , choice rests with you on what authentication scheme you want to keep , but always remember the fact that whatever scheme you keep here , the same should be set up on the IIS virtual Directory too.

http://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-01-44-13/2337.Capture.JPG

Share via