Sentinet – Service Virtualization Part 4 - BizTalk Server
In the previous post I have discussed the protocol mediation between SOAP and REST services by the Sentinet product. I also demonstrated how Sentinet provides monitoring capabilities for service and API message exchanges. In this post I would like to continue my exploration of the Sentinet and share my experiences of using Sentinet together with the BizTalk Server.
In this scenario I want to expose the data of my LOB systems through the BizTalk Server. The BizTalk Adapter Pack includes WCF LOB Adapters that will give me 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, I can provide BizTalk with inbound endpoints that will expose my LOB data as a SOAP or REST service. I can expose BizTalk service endpoints using regular BizTalk WCF Adapters with bindings for HTTP or SOAP protocols. The access to these endpoints must be secured with authentication and authorization – and 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. In this scenario 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 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.
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 the previous posts I have demonstrated how to create a Sentinet virtual service. To provide end users with more ways to access LOB data through a virtual service, you need to create multiple inbound virtual endpoints like indicated by the Sentinet screenshot below. Each inbound virtual endpoint will be configured with its own security, while they all route messages to the same BizTalk endpoint.
Now I will walk through creating multiple endpoints with various bindings and security mechanisms to demonstrate the capabilities Sentinet offers. In this and the upcoming posts I will create five different virtual endpoints configured with different bindings and security mechanism. All five virtual endpoints will route messages to the same single BizTalk endpoint.
In this post I will start with a simple (unsecured) endpoint configured with SOAP 1.2 over SSL and no user credentials. Then I will add a secure endpoint configured with SOAP 1.1 over SSL that requires username/password client credentials. In the next posts 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.
![clip_image002[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4-UaxQQDKSaS9fVW14Ld34YhRXeSuZh1eXdiG3bmiTThXcAm7FOkPbnHtBG_HiSHHBSvSrDhGAMV6EegR4R0wujP_ZomeqoGEE7o0mGpYDNKX3CQsA9r0vG-qZ7MQK2zKNG6Y/?imgmax=800 "clip_image002[6]")
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. Policy configuration is visualized by another Sentinet screenshot below.
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 like it is shown in the screenshot below.
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 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>
So far 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. In the next part I will continue with X509 virtual endpoint followed by parts on SAML/Claims and Service Bus virtual endpoints.
Cheers,
Steef-Jan
In this scenario I want to expose the data of my LOB systems through the BizTalk Server. The BizTalk Adapter Pack includes WCF LOB Adapters that will give me 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, I can provide BizTalk with inbound endpoints that will expose my LOB data as a SOAP or REST service. I can expose BizTalk service endpoints using regular BizTalk WCF Adapters with bindings for HTTP or SOAP protocols. The access to these endpoints must be secured with authentication and authorization – and 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. In this scenario 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 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.
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 the previous posts I have demonstrated how to create a Sentinet virtual service. To provide end users with more ways to access LOB data through a virtual service, you need to create multiple inbound virtual endpoints like indicated by the Sentinet screenshot below. Each inbound virtual endpoint will be configured with its own security, while they all route messages to the same BizTalk endpoint.
Now I will walk through creating multiple endpoints with various bindings and security mechanisms to demonstrate the capabilities Sentinet offers. In this and the upcoming posts I will create five different virtual endpoints configured with different bindings and security mechanism. All five virtual endpoints will route messages to the same single BizTalk endpoint.
In this post I will start with a simple (unsecured) endpoint configured with SOAP 1.2 over SSL and no user credentials. Then I will add a secure endpoint configured with SOAP 1.1 over SSL that requires username/password client credentials. In the next posts 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.
![clip_image002[6]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFd_hngCrJVAQ4TW9i8ZO1a4Tfa-oxqNXU0LMfXu3OSQodsDjfeRTAA4f9O8fnjRIPmBPaSxXa3HhUUON_Vu2vRQc2Z8pA8x_XzaN1w8-dyM5NYw0-dcHgE5CV-Lg2r5b6dbIr/s1600-h/clip_image002%25255B6%25255D%25255B4%25255D.png "clip_image002[6]")
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. Policy configuration is visualized by another Sentinet screenshot below.
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 like it is shown in the screenshot below.
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 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>
So far 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. In the next part I will continue with X509 virtual endpoint followed by parts on SAML/Claims and Service Bus virtual endpoints.
Cheers,
Steef-Jan
Comments