Introduction

A team of Microsoft consultants developed Managed Services Engine (MSE) as an open source project a few years ago. End of December 2009 it was the final CTP release. MSE was meant to facilitate service virtualization to support versioning, abstraction, management, routing, and run-time policy enforcement for Services. It used a service repository to provide easier and faster deployment of services, change management, and reuse.

Service Virtualization

The power of this concept in its non-intrusive nature. Services that are “virtualized” (or exposed) to ultimate consumer applications through brokers (or network agents). Business Services are fully decoupled from consumer applications. Business Services can be implemented and deployed using unified security and deployment models, while being exposed using ultimate requirements imposed on consumer applications. Changes in business services will not affect consumer applications, and vice versa, changes in consumer-facing requirements will not affect currently deployed services. All the common SOA infrastructural challenges are addressed by the virtual services hosted in the broker application that takes full responsibility to handle these challenges on behalf of Business Services. Read more on Sentinet product through the TechNet Wiki article BizTalk Server and Sentinet - Protocol Mediation REST to SOAP.

Securing Endpoint scenario

In this article, I will demonstrate how to expose the data of a LOB systems through the BizTalk Server. The BizTalk Adapter Pack includes WCF LOB Adapters that will give users access to LOB systems like SAP, Oracle eBusiness suite, and databases like SQL Server or Oracle. After BizTalk Send Port is configured with the WCF LOB Adapter to interface with LOB system, you can provide BizTalk with inbound endpoints that will expose the LOB data as a SOAP or REST service (see also Protocol Mediation). You also expose BizTalk service endpoints using regular BizTalk WCF Adapters with bindings for HTTP or SOAP protocols. In case the access to these endpoints must be secured with authentication and authorization than that can be challenging! In case when BizTalk Server resides behind a DMZ, but access to the LOB data is meant to be provided externally from the outside (which is a very typical case), you will need to think about using a reverse proxy.

You could mitigate these challenges by using service virtualization concept implemented in the Sentinet. By placing a Sentinet Node in front of the BizTalk WCF service endpoints you can delegate most (if not all) of the authentication/authorization logic to a virtual service hosted in the Sentinet Node. By using Sentinet you can also make use of the other service virtualization features it offers, like protocol mediation, routing, and monitoring.

In the diagram below you see a Sentinet Node in front a BizTalk hosted endpoint that accepts messages and routes them a send port that communicates with a LOB system (in this case just a SQL Database).

You can setup security of the service endpoint hosted in BizTalk by configuring WCF Adapter. However, you can delegate external security (authentication /authorization of the end users) to the virtual service hosted in the Sentinet Node and keep BizTalk endpoint configured with any WCF Adapter you want regardless of the required external security (for example, you can use WCF-WSHttp adapter with internal windows integrated security). By means of using a virtual service you can now leverage the diverse security capabilities offered by Sentinet, where security of the virtual service can be controlled dynamically and remotely via Sentinet browser-based console. You can also make use of multiple identity types such as Username/Password, Kerberos/NTLM, X.509, SAML, binary security tokens and custom identity types over message-level or transport-level security models. Authorization can be enforced by using Sentinet Access Rules designer.

What Sentinet has over BizTalk is that when you have to change BizTalk endpoint security, you have to reconfigure it with a different WCF Adapter, or at minimum you have to reconfigure adapter itself. Sentinet provides BizTalk services with far more flexibility by offering many different authentication/authorization schemes without any need to reconfigure BizTalk artifacts. Besides that, you can configure multiple virtual endpoints with different bindings to provide access to a single BizTalk endpoint, while BizTalk endpoint itself provides access to an LOB system or a database. Basically, Sentinet Node acts as a special gateway that can host any number of diverse virtual services. Once you have exposed your data and/or process through a BizTalk endpoint you will never have to change it to provide access to it for different consumers. The Sentinet will provide that for you through its configuration without any code. You can also create multiple virtual services with multiple endpoints supporting various bindings, authentication and authorization methods exceeding the capabilities of a single BizTalk adapter.

In this article and upcoming articles, I will walk through creating multiple endpoints with various bindings and security mechanisms to demonstrate the capabilities Sentinet offers. There will be five different virtual endpoints configured with different bindings and security mechanism. All five virtual endpoints will route messages to the same single BizTalk endpoint.

SSL Transport (HTTPS)

A relative simple security mechanism is providing secure transport using HTTPS with or without authorization (credentials). You can create a simple (unsecured) endpoint configured with SOAP over SSL and no user credentials or a secure endpoint configured with SOAP over SSL that requires username/password client credentials. In the upcoming articles I will continue with the endpoint that requires client X509 certificate, SAML Token (Claims), and yet another endpoint configured with the Microsoft Azure Service Bus. Note, that while I will be complicating use cases by adding and changing security scenarios, I will not be “touching” my BizTalk Server configuration that will remain configured with the same single endpoint and the same single BizTalk Adapter. In other words, my BizTalk application will be given agility to adapt for continued changes, and it will be provided with new capabilities (such as to be a "claims-aware” application) with no configuration or code changes. Hence the management is all delegate or provided if you will by Sentinet. The first endpoint will be an endpoint that uses transport security (https) with SOAP 1.2 binding. 

I named this endpoint SearchTimes and I applied to this endpoint the policy that I named Secure HTTPS. The second endpoint will be configured with basicHttp and transport-level security (https) that requires username/password client credentials. I named this endpoint RunningResults and I applied to this endpoint the policy that I named Steef. Policy configuration is visualized by another Sentinet screenshot below.  After both virtual endpoints are created, I add an Access Control that will manage authorization of the messages sent to these endpoints. Access Control in the Sentinet is driven by the Access Rules that are created in the Sentinet Access Rules Designer. I will use Everyone Access Rule that will provide access to anyone who sends messages over HTTPS to SearchTimes endpoint, while SimpleAuth access rule will require specific username/password. The latter can be created by adding a new access rule in the Sentinet Repository, then using drag and drop of the Username/Password element from the Identity conditions of the Sentinet Access Rules Designer. Provide specific username and password and save your access rule.

Note that Sentinet Access Rule can be configured with many username/password combinations, where specific username/password identities may be stored in the Sentinet Repository, or in Active Directory, or in your own custom database, or in any other external identity system. After you created Access Rules you assign them to the virtual service Access Control. You simply drag and drop the Access Rule on the virtual endpoint and hit the Save button. You will now see Access Rules applied to virtual endpoints SearchTimes and RunningRules.

Test the Endpoints

To test both virtual endpoints I will use SoapUI. You export the WSDL of your virtual service and save it on disk. Open SoapUI and create a new SOAP Project, specify the project name and navigate to the WSDL file saved on disk. Click Ok and the project will create operations for each web service endpoint. Double click the SearchTimes endpoint, click Request 1 and fill in the parameters. Hit the green play button and the request will be sent to the endpoint of the virtual service. Request will be sent through the virtual service to the BizTalk endpoint (receive location). 

You can see all the details of this message exchange through the Sentinet Monitoring and optional messages recording. You will see request message sent by the SoapUI and recorded by the Sentinet virtual service. You can also see complete response that is returned by the virtual service to the SoapUI client application.

The SearchTimes endpoint is using HTTPS transport to encrypt and digitally sign messages on the wire. This does not really mean the use cases represents secure communication because the client identity is not required for this message exchange and anybody can send a message to the SearchTimes endpoint. By adding the RunningRules virtual endpoint I make it a secure endpoint by forcing the user of the service endpoint to provide credentials. In SoapUI navigate to the RunningRules endpoint, double click the endpoint, click Request 1 and fill in the parameters. Hit play and you will see SOAP Fault coming back to SoapUI client.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">

 <s:Body>

  <s:Fault>

    <faultcode xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:InvalidSecurity</faultcode>

    <faultstring xml:lang="en-US">An error occurred when verifying security for the message.</faultstring>

   </s:Fault>

  </s:Body>

</s:Envelope>

In the monitoring of Sentinet I will see recorded request and response. Moreover, you will be able to see that virtual service did not even try to forward request to the BizTalk endpoint, rather it immediately generated SOAP Fault and returned it to SoapUI. The reason for that is clear - I did not provide username/password in the SoapUI. As a result of that, Sentinet virtual service rejected my request with the SOAP Fault, and it did not even “bother” my BizTalk endpoint.

So I have to provide credentials when making my request to the virtual service. This can be specified in the SoapUI behind the Auth tab. If I hit the Play button now I will receive a response with the data I want. In the Sentinet monitoring I can see the message (request) sent to the virtual service endpoint. What’s interesting is in the Usernametoken element:

<wsse:UsernameToken wsu:Id="UsernameToken-9">

  <wsse:Username>user</wsse:Username>

  <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">test</wsse:Password>

<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">O11AOMFb+wfUqTn9nB7CBQ==</wsse:Nonce>

   <wsu:Created>2014-03-26T09:58:28.550Z</wsu:Created>

</wsse:UsernameToken>

Wrap up

In this article I have demonstrated two different endpoints of the virtual service that sits in front of the BizTalk application. As you can see I did not create any code. Everything is done through Sentinet configuration. As you can see Sentinet clearly provides the benefits of the service virtualization concept for BizTalk applications that have to provide many alternative endpoints configured with different security requirements. Sentinet provides easy means to achieve this goal where I configured Sentinet virtual service with two endpoints that route messages to the same single BizTalk Receive Location. Both endpoints provide secure HTTPS access to the BizTalk application with one endpoint configured with anonymous access, and the second configured with the username/password authentication and access control based on specific username/password credentials.

See Also

Another important place to find a huge amount of Azure BizTalk Services related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.