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.
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.
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.
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.
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.
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.
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>
<
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</
faultstring
xml:lang
"en-US"
>An error occurred when verifying security for the message.</
</
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.
<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>
wsse:UsernameToken
wsu:Id
"UsernameToken-9"
wsse:Username
>user</
wsse:Password
Type
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"
>test</
wsse:Nonce
EncodingType
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
>O11AOMFb+wfUqTn9nB7CBQ==</
wsu:Created
>2014-03-26T09:58:28.550Z</
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.
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.