BizTalk: Securing endpoints leveraging Sentinet API Management (Part 2)

Article
1/17/2024

Introduction

In this article I would like to continue where I left off in the previous one, and demonstrate how to set up another endpoint in the virtual service. This time I want my BizTalk application to make use of a different security mechanism based on the client X.509 certificate. Digital certificates are often used in an application-to-application communication scenarios that require the strongest security tokens based on the digital certificates PKI infrastructure. As in all cases with Sentinet, I will not have to change anything in my BizTalk application. All I have to do is to remotely configure Sentinet virtual service with an additional endpoint.

Securing Endpoint scenario

The scenario is similar to the one in part 1 article.

Creating the X509 Endpoint

First I will use Sentinet console to create a new virtual endpoint that is configured with the WsHttpBinding (Mutual Certificates) policy:

The WsHttpBinding (Mutual Certificates) policy requires client X.509 certificate, so I described it with the following WCF binding:

<bindings>
<wsHttpBinding>
<binding name="defaultBinding">
<security mode="Message">
<message clientCredentialType="Certificate" negotiateServiceCredential="false" establishSecurityContext="false" />
</security>
</binding>
</wsHttpBinding>
</bindings>

Note, that this binding configuration uses the flavor of standard WCF wsHttpBindingthat requires consumer of the virtual service to present its client X.509 certificate, while the service will also authenticate itself to the client with its own X.509 certificate - hence the mutual X.509 certificates message-level security over HTTP.

Setup the Access Rule

Managing X.509 certificates can be a tedious task. I could use the makecert.exe command line tool to create client X.509 certificate, however Sentinet comes here with an additional feature. Sentinet offers optional X.509 certificates management infrastructure that allows remote and secure issuance and management of certificates issued by Sentinet as if it is a Certificate Authority. Therefore, I will request Sentinet to generate a client X509 certificate for me.

A window will pop-up where you can specify the settings for the certificate.

When you click OK you can download complete certificate (with its Private Key) as a PFX password protected file. You can also download only the public part of the certificate as a CER file.

PFX file will be used by the client application as its X.509 identity (client needs complete certificate with its Private Key). At the same time, public part of the certificate in CER file format can be used in the Sentinet Console to create an Access Rule for the virtual service. In my case the access rule will require this particular client certificate to be present as an identity of the service caller. In other words, no other client certificate (even if it is valid and trusted) will be allowed to use the virtual service (hence, I will have authorization).

You can now go ahead and create an Access Rule, which can be applied to the new virtual service endpoint. In Access Rules designer I create a new access rule, MyCertificate Access Rule.

Select Add Access Rule, drag and drop X509 certificate. Click Browse button and navigate to the CER certificate file you just saved.

You can now apply newly created access rule to the RunningX509 virtual endpoint. Go to the virtual service and select Access Control tab, click Modify button and drag and drop the access rule on the desired endpoint. The endpoint is now secured with an access rule that requires very specific client X.509 certificate for authorization. Note that the access rule can be modified to allow many different client certificates, not just one.

At this point I added to my existing virtual service a new endpoint that requires client authentication based on its X.509 certificate. I also secured endpoint with Access Rule that requires very specific client certificate for authorization. This all looks pretty straight forward. The whole process takes only few minutes of time with easy to navigate drag-and-drop Sentinet user interface and no coding.

Testing the endpoint

Now I want to build consumer application and call my virtual service through the new endpoint. For this post I will use Microsoft WcfTestClient utility that will act as a consumer of the virtual service. I start the utility and import the WSDL of the virtual service using URL to the WSDL provided to me by the Sentinet console. I select my GetResultsRaceNameNumber operation that the WcfTestClient utility shows under IVirtualInterface(RunningX509) element.

I filled in the sample request data, click Invoke button and get the following error:

WcfTestClient was automatically configured (from the WSDL provided by Sentinet) to use security that requires client certificate, but the certificate was not configured with this client application. So I need to do some additional configuration in the WcfTestClient to provide its client endpoint with the client certificate.

Right click on the Config File entry and select Edit with SvcConfigEditor menu option. In the SvcConfigEditor tool expand Advanced element, right click Endpoint Behaviors element and select New Endpoint Behavior Configuration. This will create NewBehavior0 endpoint behavior. Add clientCredentials, select clientCertificate element and then paste the thumbprint of the client certificate in FindValue field, select the correct store location and its name.

Finally you navigate to the RunninX509 endpoint and select NewBehavior0 from the BehaviorConfiguration drop down.

Click Save in the SvcConfigEditor, and click OK in the WcfTestClient tool when it asks to reload its configuration. Now the NewBehavior0 is attached to the RunningX509 endpoint where behavior specifies client certificate. Select the GetResultsRaceNameNumber operation, fill in request data and Invoke button. Now you will see the result of a successful call to my virtual service.

In Sentinet you can examine this call from the Monitoring screen with all the tracking details where you can see messages coming in and out of the virtual service.

I can also review details of the messages recordings where request and responses can be shown in original wire representation (encrypted) form and in clear text (decrypted). Below is an example of a client request message recorded by the virtual service once request’s body is decrypted and shown in XML format.

Below is the recording of the response message that comes back from the virtual service to the client application. The virtual service’s response message shows the content of the original response generated by my BizTalk application. Recorded response message is shown here in clear text just before it is encrypted for the wire transmission. Note that I can also review recorded requests and responses in encrypted form exactly how they are transmitted over the wire, as well as the same message exchange between the virtual service and my BizTalk service (in addition to described here messages exchange between the WcfTestClient application and the virtual service).

Wrap Up

In this article I demonstrated how I can secure my internal BizTalk services application with X.509 certificates security (that might represents hypothetical B2B application-to-application scenario). For that, I did not have to change anything in the way my internal BizTalk application is deployed or configured. I simply virtualized BizTalk service through a Sentinet virtual endpoint that requires X.509 certificate security. Sentinet also provided additional managed access control (authorization) and messages exchange monitoring.

Share via