Background
Recently I was tasked with enriching a WCF web service to supply the originating client Windows Authenticated credentials through to BizTalk for further processing. This is exposed to the public domain and many types of clients may connect, so SSL and the basicHTTPbinding was the preferred approach.
The environment is: BizTalk 2013 R2, .Net 4.0, WCF, SoapUI
How To
Option 1: Here is an approach, which is very cool, yet, not optimal. Read this, then we can get to the easier quick fix.
Traditionally, WCF encrypts the messaging context and much of the HTTP detail becomes unavailable by the time the message reaches BizTalk. A suggested approach would be to create a custom WCF EndPointBehavior or ServiceBahavior. A WCF Custom Behavior solution like this would allow inspection (MessageInspector) of messages within the WCF pipeline, and push certain detail into the WCF Http Headers, which would result in BizTalk having these details in the message context of the InboundHeaders property. Hence, you could rip these properties and use them during processing.
Dean May has a great approach towards this: Securing BizTalk WCF Receive Locations
Option 2: So, now for the easier quick fix.
Nevertheless, there is a much easier way to do this, by utilizing the tools that we are given.
Create the WCF Service on IIS
- This could be by traditional means, WCF Publisher, etc.
- Update the Authentication properties for the WCF Service
- Disable all methods
- Enable Windows Authentication
- Update the SSL Settings
- Require SSL
- Accept Client Certs
Create a new AppPool
- Connect your WCF Service to utilize the newly created AppPool
- The AppPool should be configured for:
- .Net Framework v4
- Integrated pipeline
BizTalk Receive Port Configuration
Assuming that you have been able to create a BizTalk Receive Location to receive messages from this WCF Service. You will need to make the following port adjustments to correlate with the newly added WCF Service adjustments.
- Be sure to utilize the WCF-CustomIsolated Adapter
- Select the basicHttpBinding
- Ensure Security is set to Transport
- Ensure Transport clientCredentialType is set to Windows
- All other defaults are acceptable
Test with SoapUI
Nevertheless, SoapUI can test with Windows Auth
- Be sure to create a new project, and point to your WCF Service
- Before submitting your message set the Auth properties
Verification with BizTalk
Here are the message context properties in BizTalk. You can see WindowsUser is passed as a Promoted property and ready for decision logic within your Orchestration.
In conclusion, there is less need for WCF custom behaviors, and native WCF / BizTalk functionality can provide you the client credentials for further processing.