Thursday, July 03, 2014

Going down under–BizTalk Summit 2014

There will be another BizTalk Summit event in august in Australia. The early bird tickets are on sale now until the end of this month! The event will take place in three different cities: Melbourne, Sydney and Brisbane.

image

I will be speaking at each of the events together with fellow MVP’s Saravana Kumar, Michael Stephenson, Bill Chesnut, Mikael Hakansson and Mick Badran on various topics around integration with the Microsoft technology stack: Microsoft Azure, BizTalk Service, BizTalk Server 2013 R2, Mobile, Office365, and BizTalk360.

My talk will specifically go into Microsoft Azure BizTalk Service, what it offers today, what scenarios can be supported, development-, deployment-, and operation perspective of this cloud service. Session is called:

Hitchhiker's guide to integration with Microsoft Azure BizTalk Service

and the actual abstract:

Microsoft Azure BizTalk Service (MABS) is almost available to us for a year. It is a newcomer in the world of integration Platform as a Service (iPaaS) and promising contender for the sweet-spot in the Gartner's Magic Quadrant. This service in Azure has a great deal to offer and can provide different means of integration in the changing IT world of on premise ERP systems, services, cloud and devices. In this session the audience will learn where the Microsoft Azure BizTalk Service stands in the middle of the iPaaS world, what it has to offer today and what the road-map will look like in the future. During the session there will be various demo's showcasing the service features from a development, deployment and operations perspective.

You will find the agenda, other speaker bio’s, sessions and abstracts on the site, where you can register.

Looking forward to speak there and meet people in Australia. I have not seen this part of the world yet so it will be quite an adventure. See you there!

Cheers,

Steef-Jan

Tuesday, July 01, 2014

Microsoft Integration MVP 2014 – 5th Time in a row!

Today I have received an e-mail from Microsoft with exciting news that my MVP status has been renewed again!

[MVP_Horizontal_FullColor%255B4%255D.png]

For me this is the fifth time to receive this award. The fourth year in the program has been an awesome experience, which gave me the opportunity to do great things and meet inspiring, very skilled people. I have had some interesting speaking engagement, which were fun to do and were very fulfilling. I learned a lot through speaking thanks to the community and fellow MVP's. I was able to share my experiences through these speaking gigs and other channels like this blog, MSDN Gallery, and above all the TechNet Wiki.

I would like to thank:
  • My MVP leads William Jansen.
  • The BizTalk Product Team, Mark Mortimore, Guru Venkataraman, Karthik Bharathy, Ed Price, Nitin Mehrota, Mandi Ohlinger, Allesandro Teglia, Paolo Salvatori, Clemens Vasters and all other Microsoft employees involved.
  • People at my former employer motion10: Rene Brauwers, Eldert Grootenboer and many others. 
  • At my current company Inter Access: Fellow MVP Edward Bakker.
  • The BizTalk Crew: Saravana Kumar (BizTalk360), Nino Crudele, Sandro Pereira, and Tord G. Nordahl
  • Fellow Microsoft Integration MVP's: Richard Seroter, Kent Weare, Mikael Håkansson, Johan Hedberg, Stephen W. Thomas, Mick Badran, Micheal Stephenson, Jon Fancey, Tomasso Groenendijk, Dan Rosanova, Ben Cline, Sam VanHoutte, Bill Chesnut, Leonid Ganeline, Ashwin Prabhu and Maheshkumar S Tiwari, who I got learn even better and supported me in this program.
  • The BizTalk community: Mikael Sand, Lex Hegt, Colin Meade, Naushad Alam, Howard S. Edidin, Johann Cooper, Mitch VanHelden, Jérémy Ronk,  Maxime Labelle, Jean-Paul Smit, Dean Robertson, João Pedro Martines, Martin Abbott, and many others that make the BizTalk community strong! 
  • Andrew Slivker from Sentinet.
  • Finally my wife Lian and children Stan, Ellis and Cato for their support.
I’m looking forward to another great year in the program.

P.S: Four years ago when I first received this award the Netherlands did not win the World Cup final. Hopefully this time in 2014 they will reach the final and win.

Cheers,

Steef-Jan

Sunday, June 22, 2014

Sentinet – Service Virtualization Part 7 - BizTalk Server

In the previous blog post I demonstrated how I can secure my internal BizTalk services application with requirements for Federated Security based on SAML tokens. The goal was to enable my BizTalk service to be a “claims-aware” application. Just like with all other cases of virtualizing BizTalk services through Sentinet, turning the BizTalk service application into a “claim-aware” application did not require any coding or configuration changes, the existing BizTalk application remained deployed and configured as is.

In this post I would like to continue where I left off in the previous post, and demonstrate how to set up yet another endpoint in the virtual service. This will be the endpoint that leverages the Microsoft Azure Service Bus so that my internal BizTalk services application can be accessible from outside of the internal network through the Azure Service Bus Relay Service.

The Microsoft Azure Service Bus Relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose services and APIs that reside within a corporate enterprise network to the public cloud, without having to open up a firewall connection or requiring intrusive changes to a corporate network infrastructure.

Sentinet allows any service, in this case a service hosted in BizTalk, to be on-boarded onto the Microsoft Azure Service Bus infrastructure without any reconfigurations, redeployments or potential security keys compromises. By configuring the Sentinet Node, which I will show in this post, you can dynamically open and manage Microsoft Azure Service Bus endpoints and authenticate virtual services with the Microsoft Azure ACS service. See the diagram below that shows my objective of this post.

clip_image002

The high level flow of interaction is as follows:

  1. Client sends a request to the relay endpoint hosted by the Azure Service Bus relay service.
  2. The request is forwarded (“relayed”) to the Sentinet Node that sits in front of the BizTalk hosted service. Both Sentinet Node and BizTalk server are behind the corporate firewall.
  3. The request received by the virtual service hosted in the Sentinet Node will be authenticated, authorized and forwarded to the BizTalk service that internally routes the request to the WCF-SQL Send Port. Send Port is configured to select records from the SQL Server database.
  4. The SQL Server database handles SQL statements and returns datasets to the WCF-SQL Send Port.
  5. WCF-SQL Send Port forms response message from the received datasets.
  6. Response message flows all the way back to the client.
The interesting part here is the interaction between external clients and the internal Sentinet Node through the Azure Service Bus. Virtual service hosted in the Sentinet Node will be configured to enable automatic registration of its endpoint with the Azure Service Bus. The Sentinet Node will walk up to the Service Bus namespace and it will reserve for its virtual service an external address relative to the Service Bus namespace address (with scenario in this post the relative address reserved for my virtual service endpoint is RunnerCloud (1 in the diagram below). The Service Bus namespace is created through the Microsoft Azure Portal. The namespace address and the relative address form a worldwide unique external address. In my case the namespace address is sltn2014.servicebus.windows.net while the relative address is RunnerCloud, so that the combined address sltn2014.servicebus.windows.net/RunnerCloud can be now turned into an actual http, https or native sb address that is accessible anywhere in the world, while the actual internal service endpoint is behind Microsoft Azure infrastructure and internal corporate firewall.

To send a message to that endpoint a client will create a connection to the front end node on the Service Bus, where it connects to a forwarder (2 in the diagram below). The forwarder will communicate with the routing fabric to learn who owns the address (3 in the diagram below). It will send a control message to the address that will flow to the receiver (i.e. receive location) and will then rendezvous with the forwarder (4 in the diagram below). Now the relayed connection is realized and regular web service traffic will flow through it. Client applications can use http, https or sb outbound connections and no firewall ports need to be open for the service inbound traffic.

clip_image004

The setup of the virtual service endpoint and the security configuration consists of the following steps, which I will be covering in more details later in this post:

  • Setup a Sentinet Node Base Addresses for Microsoft Azure Service Bus
  • Create the endpoint for the Sentinet virtual service.
  • Write a test client to access the virtual service endpoint.
The first step is to add Microsoft Service Bus address to the Sentinet Node Base Addresses. Basically, all the Node’s base addresses inherit their base addresses from the IIS server configuration, since the Sentinet Nodes always run inside IIS server. As a result of this inheritance, all Sentinet virtual services have their addresses derived from the Sentinet Node base addresses.

clip_image006

This is not true however for the virtual services connected to the Service Bus Relay service since these virtual service addresses are derived from Microsoft Azure Service Bus itself. For the Azure Service Bus specifically, IIS Server is simply a process that hosts Sentinet Node applications. IIS server provides Sentinet Nodes with the reliability of its infrastructure such as application pools isolation, scheduled app pools recycling, etc., but IIS server does not provide Sentinet Node applications with its own listening capabilities because they are irrelevant to the Azure Service Bus architecture. That means that Microsoft Service Bus addresses are configured straight from the Sentinet Administration Console rather than from the Node Configuration Wizard embedded in the IIS Manager console. Below are the steps to add the Microsoft Service Bus base address to the Sentinet Node:

  1. Select the Sentinet Node tree item in the Repository tree-view and click the Modify toolbar button.
  2. Click the Add Addresses button for the Microsoft Service Bus base addresses.
  3. In the Add Microsoft Service Bus Address wizard:
    • Select address transport scheme that will be used by the consumers of the virtual services hosted by the Sentinet Node. Transport schemas available for Microsoft Service Bus external addresses are http, https or sb. Provide [namespace] that matches the Microsoft Azure Service Bus namespace associated with your Microsoft Azure account.
clip_image007

The Address is formed from the selected protocol, the Azure account namespace and the default DNS, servicebus.windows.net. In my case the new Microsoft Service Bus base address added to the Sentinet Node will be sb://sltn2014.servicebus.windows.net

    • Select Service Bus Credentials Type (Shared Secret is the common credential type that is supported since early versions of the Microsoft Azure Service Bus).
    • Click Next.
    • The Shared Secret credentials are obtained from the Microsoft Azure Portal. Through the Portal you can navigate to the Service Bus and select the appropriate namespace and click connection information in the bottom pane.
clip_image008

    • Default Issuer and Default Key credentials captured from the above screen, use in the next step of the Sentinet wizard to configure new Sentinet Node base address with the Azure Service Bus credentials.
clip_image009
    • Click Finish. The base address will now be added, and it shows up in the Node Base Addresses list.
Note that more Service Bus base addresses can be added to the same Sentinet Node. These addresses can be associated with different transport schemes, different Service Bus namespaces and different Service Bus credentials. Existing Service Bus address and its credentials can be changed at any time by clicking the Modify button located next to each Service Bus address entry. What is important to emphasize here, is that this step effectively provides central and remote configuration of the Sentinet Node with your Azure Service Bus account(s) and its namespace(s). This is a one-time user action. Once Sentinet Node is configured with your Azure Service Bus namespace, the Node gets the capability to dynamically open (or close) any number of Service Bus endpoints in your Azure Service Bus namespace. Ultimately it means that the Node gets the capability to dynamically connect any number of its virtual services to the Azure Service Bus relay service making them accessible from outside of the corporate networks.

In the previous step we have set up Sentinet Node with connection to the Azure Service Bus namespace (in the Sentinet terms, we have added Microsoft Service Bus address and its configuration to the list of the Node base addresses). Our next step in this sample is to set up an endpoint for our virtual service that is configured with the Service Bus (i.e. relay). In other words, we have just configured Sentinet Node with the generic capability to connect its virtual services to Azure Service Bus, and now we want to use this new capability, and we want to add a new endpoint to our existing virtual service. New service endpoint will be called ServiceBus. It will be used to expose externally (through Microsoft Azure cloud) our existing internal virtual service. In the Sentinet Console we use the same drag-and-drop steps as if we used to create any other virtual service endpoint (those steps are repeatedly described in my previous parts of this blog article series). This time, however, we also have the sb://sltn2014.servicebus.windows.net in the drop-down list of available virtual service base addresses. We will choose this address and type RunnerCloud in relative part of the endpoint address, so that the consumer facing full address now becomes sb://sltn2014.servicebus.windows.net/RunnerCloud. Note, we could have used the same process to expose our service via http or https protocol.

clip_image010

Next we will configure, the endpoint with a policy compatible with sb protocol. We will use the following binding:

<bindings>
    <netTcpRelayBinding>
        <binding name="defaultBinding">
            <security relayClientAuthenticationType="None" />
        </binding>
    </netTcpRelayBinding>
</bindings>


In this scenario we choose the netTcpRelay binding with no further authentication. However, we still need to assign an access rule to the endpoint. For simplicity in this sample the access to the service will be for anyone. The Everyone Access Rule is available with the default product installation. The Access Control is driven by the Access Rules located under the Access Rules folder in the Repository tree. You can expand the Access Rule folder in the Repository view. Drag-and-drop the Everyone Access Rule on the root of the Virtual Service tree and it will be assigned to your service with the Permit permission.

Our final step in this sample is too test the endpoint. We will write a simple test client (console app) to access the service endpoint. In Visual Studio we create a new console application, set a service reference to the virtual service with the newly created endpoint. Note the immediate benefit for developers of using Sentinet Repository here. When we build the client application in Visual Studio we select Add Service Reference and provide virtual service’s WSDL URL from the Sentinet Repository. Sentinet virtual service was configured with the binding that has everything in it. All we need to do is to write the actual code to call the service, while all configurations for our test client will be automatically generated off the Sentinet Repository.

The code in our client looks like below:

clip_image011

Below is the generated binding in the app.config:

clip_image012

When we run the client it calls the virtual endpoint and we can view how the call to the virtual endpoint is made through the monitoring feature of the Sentinet. You can examine this call from the Monitoring screen with all the tracking details, where you can view messages coming in and out of the virtual service. Below is the screenshot of the recorded message in clear text after it is received, decrypted and decoded by the virtual service.

clip_image014

The response message before encryption and encoding is also visualized below.

clip_image016



Note that Sentinet provides here monitoring, tracking and optional recording of the messages that arrive from the Azure Service Bus relay service. This communication leg between cloud-based relay service and on-premises Sentinet virtual services represents that “firewall tunneling” effect that is so special to the Azure Service Bus technology. All messages coming through this channel are always encoded using Microsoft-specific, non-interoperable binary serialization. Nevertheless, Sentinet decodes these messages and shows them on the screens above in a human-readable XML representation.


In this post I have discussed and demonstrated how to create a Sentinet virtual endpoint that is exposed through the Microsoft Azure Service Bus. Effectively, the objective of this use case was to enable my BizTalk service to be a “cloud-aware” application supporting hybrid connectivity (i.e. between the cloud and on premise) with no coding or any changes in how my existing BizTalk application is deployed and configured. BizTalk application was also extended to service calls monitoring and could have been easily extended with additional authentication and authorization (which I avoided for the sake of simplicity of this article). At the same time, as a developer of a client application, I leveraged Sentinet Repository and Visual Studio to quickly build my test client application with the minimum effort.



In the next post I will discuss and demonstrate another interesting use case exploring the combination of Sentinet and Microsoft Azure BizTalk Service (MABS).

Cheers,

Steef-Jan

Friday, June 06, 2014

Sentinet – Service Virtualization Part 6 - BizTalk Server

In the previous post I have demonstrated how I can secure my internal BizTalk services application with X.509 certificates security (that might represent a 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 accomplished that by simply virtualizing the BizTalk service through a Sentinet virtual endpoint that requires X.509 certificate. I also showed how Sentinet provides additional managed access control (authorization) and messages exchange monitoring.

In this post I would like to continue, where I left off in the previous post, and demonstrate how to set up my virtual service with yet another endpoint that will enable my BizTalk application with a different security mechanism based on SAML claims. I will use a SAML token to demonstrate a Federated Security scenario. Effectively, the objective of this use case will be to enable my BizTalk service to be a “claims-aware” application with no coding or any changes in how my existing BizTalk application is deployed and configured. See the diagram below that shows my objective in this post.

clip_image002[4]

The flow of interaction is as follows:

  1. Client application provides user credentials (username/password in my sample setup), to the external Security Token Service, the Windows Azure Access Control Service (ACS) in my sample setup (it can also be an on-premises Microsoft ADFS service).
  2. The Windows Azure ACS maps provided client credentials to a set of business claims, and issues a SAML token for the client application.
  3. The client application sends a request message with attached issued SAML security token.
  4. A virtual service hosted in the Sentinet Node validates the SAML token and processes the SAML claim(s) to provide authorization based of the claim(s) and their value(s).
  5. The virtual service forwards the request message to the BizTalk service using internal security (for example using Windows integrated internal security).
The setup of the virtual service endpoint and the security configuration consists of the following steps, which I will cover in more details later in this post:
  • Setup a trust relationship between Sentinet Node and Windows Azure ACS. This step will configure Sentinet Node with the Windows Azure ACS specific instance as an issuer of SAML tokens that will be trusted by the Sentinet Node.
  • Configure a Security Token Service (Windows Azure ACS in our sample) with:
    • Username/password mappings to custom SAML claim(s).
    • Sentinet virtual service as a relying party that receives SAML claims.
  • Create the endpoint for the Sentinet virtual service.
  • Configure the endpoint with the security policy that requires a SAML token.
  • Assign Access Rule and Access Control to the endpoint (assign authorization rules). Access Rule will require a business claim issued by the specific claims issuer and with specific claim values.
  • Write a test client to access the virtual service endpoint.
The first step is to configure Sentinet Node with the Windows Azure ACS instance as a trusted issuer of the security tokens. STS Server (Windows Azure ACS in this case) issues SAML tokens signed by its own Issuer Identity. By default, this is an X.509 digital certificate of an STS itself, and that certificate is the actual Issuer Identity that has to be configured with the Sentinet Node as an identity of a Trusted Issuer. Therefore we have to add a Trusted Named Issuer to the Sentinet Node (SteefNode in my case). Navigate to the Sentinet Node properties, click the Modify toolbar button and subsequently the Add Identity button located next to the Trusted Named Issuers list.

clip_image003

In the Add Trusted Issuer Identity dialog box we specify an Issuer friendly name, select the X.509 certificate thumbprint choice and choose Next.

clip_image004

The Windows Azure ACS signing certificate’s thumbprint can be retrieved from the Microsoft ACS portal in Windows Azure. We enter that thumbprint in the Sentinet dialog box and click Finish. We have now configured the Sentinet Node with the specific instance of the Windows Azure ACS as a Trusted Named Issuer of security tokens. Any virtual service hosted in that Sentinet Node may now be further configured with a specific Access Rules to accept tokens issued by the ACS. Note, that Sentinet Node may be configured with more than one STS Server as a trusted issuer, which makes it possible to host virtual services that require different token issuers.

clip_image006

The next step is to configure the ACS itself to issue security tokens. We will configure the ACS to issue a custom SAML claim about the user when a user presents to ACS his username and password. Note that there are other means of issuing security tokens by ACS, besides those that are based on the username and password credentials.

The following sequence of steps describes the setup of the ACS to issue claims based on the username/password credentials:
  • Add Service Identities.
A service identity is a credential that is registered with an Access Control namespace and is intended for use by autonomous applications or clients (username/password credentials in our case). In other words, service identities are credentials that are configured globally for the Access Control namespace that allow applications or clients to authenticate directly with ACS and receive a token. An Access Control namespace may contain many service identities.
  • Create Rule group.
A rule group is a named set of claim rules that define which identity claims are passed from identity providers to your relying party application. In ACS, rule groups are associated with relying party applications, where in our case relying party application is the virtual service hosted in the Sentinet Node.
  • Add Rule to Rule group.
Rules describe the logic of how ACS transforms input claims into output claims. Rules are contained within rule groups, which are associated with relying party applications and are run through whenever a token is issued by ACS for an application.

  • Add Sentinet virtual service as a Relying party application.
Relying party applications are your services for which you want to use ACS to implement federated authentication. Relying party applications consume claims from identity providers to make authentication and authorization decisions.

First you need to log into the ACS portal in Windows Azure. Under the Service settings section in the left pane we select Service identities. Here we need to setup the identity of the service that will be configured with a username/password credentials for authentication with ACS in exchange for a security token. In Service Identities we click Add and specify a name (example: UserTest). Subsequently in this page we also click Add to create a specific username/password credential for authentication of our client.

clip_image007

In the next step we will select Rule groups under the Trust relationships in the left pane. In the Rule Groups we select Add, specify a rule group name and click Save. Subsequently, we click the newly created rule group and edit the rule group by adding a new rule. We click Add and Add Claim Rule page will appear. In this page we specify few properties like Input Claim Issuer, Claim Type, and Input Claim Value. Beside input, we also specify the Output Claim Type and Value, and optional Rule Information. Effectively this page is where we configure ACS with the actual mapping between the original username/password credentials (Input Claim) and an Output Claim (which is what will be a custom SAML claim of type http://steefjan.com/running/racename with the value of Berlin Marathon 2014).

clip_image009

Our client application will authenticate directly with ACS, therefore we choose ACS as our Identity Provider. We select a standard nameidentifier as input claim type with the Input claim value UserTest, which is the name of the Service Identity that we created earlier. Note that there is no password credential on this page because it is being configured behind the Service Identity itself. The output claim type will be a custom URI, http://steefjan.com/running/racename. The claim value will be Berlin Marathon 2014. Think of a business service that only needs to know the business specific claims about the user (thus it is a “claims-aware” application), and does not care about the original user identities. This is where we just configured ACS with these business-centric claims and the ACS’s responsibility to issue these claims as long as the ACS can authenticate user based on his username/password credentials. When we specified all the required fields and values we click Save.

The final step in ACS is to create a relying party application, which is the Sentinet virtual service that will receive claims issued by ACS. Under the Trust relationships we select Relying party applications. Next we click Add to create a relying party application.

clip_image011

We specify the Name, Realm, Token format and Token encryption policy. Next we specify the authentication setting, which is the previously created Rule group and specify a certificate for encryption of the Token. Issued SAML token will be signed by the ACS certificate (which was previously configured with the Sentinet Node as an identity of a Trusted Name Issuer), but the SAML token will also be encrypted using recipient’s public certificate (which is the public certificate of the Sentinet Node that receives SAML tokens). We upload the Sentinet Node’s public certificate to the ACS portal as a Token Encryption Certificate configured with the relying party. Note that Sentinet console provides a link to download the Sentinet Node public certificate from the Node Summary screen.

clip_image013

We have now specified all the required settings for the relying party application:

clip_image015

Our next step in this sample is to setup an endpoint in our virtual service that is configured with security that requires SAML token. We will use the Sentinet console to create a new virtual endpoint that is configured with the following binding:

image


The binding itself actually defines two bindings, where one of them references another. The “outer” binding is for the virtual service endpoint itself, while the “inner” binding is for the client application to request SAML token from the ACS. Note that as far as the virtual service concerned, it only needs the outer binding, so that the inner binding does play any role in the virtual service runtime. But remember that Sentinet is also a design-time governance tool and a generic SOA Repository. As such, it plays many roles and among its benefits it gives client applications easy access to all information (specifically service metadata) that clients have to know about the service. In this case not only Sentinet Repository configures virtual service with the proper security, but it also gives clients a “hint” on how to talk to the external STS server.

Therefore the first binding named IssuedToken specifies that the virtual service has to be configured with the requirement to expect SAML claim (authenticationMode property). It also provides address with the additional information (metadata) of the issuer of the SAML Token, and the address of the issuer service endpoint with the reference to that endpoint’s binding. The issuer address tells the client where to go to receive the SAML token from ACS. The second binding named AcsBinding tells the client how to communicate with the ACS through this endpoint, specifically that the client has to provide username/password credentials. Basically the binding contains the requirements for the client to talk to ACS.

clip_image017

Now that we have created the endpoint we need to assign an access rule to the endpoint. Although we have configured the endpoint with the SAML token requirement, we have not specified which specific claim is expected from the client application. Without the specific access rule Sentinet will only check validity and the trust of the SAML token, which would be typical for any default configuration of a claims-aware WCF service. Academically speaking, SAML token validation is all about caller authentication. As I was writing in all my previous posts about Sentinet, it also provides remote configuration and management of the access rules (thus Sentinet adds authorization on top of authentication). We will add authorization by assigning a claim based access rule to the virtual service endpoint.

We go to the Access Rules in Sentinet and click Add. Next we specify a name for the rule and drag and drop a Claim expression. We specify the Claim Type, Value and Issuer.

clip_image019

For the Claim Type and Claim Value we enter those specific values that we previously configured ACS mapping with. The Claim Issuer is the name of the Trusted Named Issuer we setup earlier for the Sentinet Node. Last step here is to apply the created access rule to the SAML virtual endpoint. We return to the virtual service and select the Access Control tab, click the Modify button and drag and drop the access rule on the desired endpoint. The endpoint is now secured with the access rule that requires very specific claim for authorization.

Our final step in the sample is to test the endpoint. We will write a simple test client (console app) to access the service endpoint. In Visual Studio we create a new console application, set a service reference to the virtual service with the newly created endpoint. Note the immediate benefit for developers of using Sentinet Repository here. When we build the client application in Visual Studio we select Add Service Reference and provide virtual service’s WSDL URL from the Sentinet Repository. Sentinet virtual service was configured with the binding that has everything in it. All we have to write is the actual code to call the service, while all configurations for our test client will be automatically generated off the Sentinet Repository.

The code in our client looks like below:

image

Below is the auto-generated binding in the app.config:

image

When we run the client it will authenticate with ACS first to get the SAML token before it can call the virtual endpoint. We will see how the call to the virtual endpoint is made through the monitoring feature of the Sentinet. In Sentinet Administration Console 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.

clip_image021

In the Consumer Identity section you can see the exact claims received and recorded by the Sentinet virtual service. You can see the claim type that we configured with ACS claims mapping, and the claim value of Berlin Marathon 2014. This was also configured as the expected claim type and claim value in the Sentinet Access Rule that we set on our virtual endpoint. If we change claim value in the Sentinet access rule and run out test client again, we will see an access denied SOAP fault generated by the virtual service (which demonstrates how Sentinet provides authorization based on specific claims and their values).

clip_image023

In this post I have discussed and demonstrated a new virtual endpoint that required a SAML token (Federated Security scenario). Effectively, the objective of this use case was to enable my BizTalk service to be a “claims-aware” application with no coding or any changes in how my existing BizTalk application is deployed and configured. BizTalk application was also extended with remotely managed authorization and service calls monitoring. At the same time, as a developer of a client application, I leveraged Sentinet Repository and Visual Studio to quickly build my test client application with the minimum effort.

In the next post I will discuss and demonstrate another interesting use case where I will add yet another endpoint to the virtual service. New virtual endpoint will expose my BizTalk server application to the outside world through the Windows Azure Service Bus. Note, that just like in all other cases discussed in all parts of this blog series, I will not change a thing in my BizTalk application to get this external exposure.

Cheers,

Steef-Jan

Tuesday, May 13, 2014

More BizTalk articles on the TechNet Wiki

About two and a half years ago I wrote a post on the TechNet Wiki blog about the BizTalk Server activity on the TechNet Wiki. Back then we (the TechNet Wiki) had about 40 articles on BizTalk Server. Summarized and accessible through the BizTalk Server resources on the TechNet Wiki article that I reckon by now everyone has bookmarked in their browser.

Going forward the TechNet Wiki has seen a tremendous grow of articles and increase in contributors ranging from MVP's, Microsoft employees and BizTalk community members. Besides the increase in content a new version of BizTalk Server (2013) has been released and it's cloud counterpart Microsoft Azure BizTalk Services (before known as Windows Azure BizTalk Services). The best entry point is, no surprise there: Windows Azure BizTalk Services resources on the TechNet Wiki.

Now let's jump into the numbers. End of 2011 around 40 BizTalk articles. Now almost two and half years later around 140 article common to all BizTalk versions, around 15 for 2006 R2/2009 version, around 80 for BizTalk 2010, around 30 for 2013 version and last but not least 20 for BizTalk Services. You can do the math here and see that is more than a sevenfold increase. With the growing numbers of contributors (around fifty people now), and the TechNet Wiki Guru competition we will see an increase to an eight fold easily or more at the end of the year!

I like to say to all contributors of the BizTalk based TechNet Wiki articles:

"Keep them coming!"

From experience I know that a lot of people value the articles. During BizTalk Summits and speaking engagements I get a lot valuable and positive feedback. This recognition and appreciation gets me and the other contributors motivated and inspired to keep on going.

In case you have a good idea for an article then do not hesitate to post it on the TechNet Wiki. Most of the active community members on the Wiki can help you out and provide guidance.

Cheers,

Steef-Jan

Tuesday, April 22, 2014

Sentinet – Service Virtualization Part 5 - BizTalk Server

In the previous post I have discussed the benefits of the service virtualization concept for BizTalk applications that have to provide many alternative endpoints configured with different security requirements. I have demonstrated how 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.

In this post I would like to continue where I left off in the previous post, 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.

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

clip_image001

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 wsHttpBinding that 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.

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.

clip_image003

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

clip_image004

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.

clip_image005

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.

clip_image006

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

clip_image007

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.

clip_image009

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.

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.

clip_image011

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

clip_image013

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.

clip_image014

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

clip_image015

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.

clip_image017

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.

clip_image019

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 clear text.

clip_image020

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).

clip_image022

In this blog post 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.

In the next post I will discuss and demonstrate even more interesting use case where I will add yet another endpoint to the virtual service. New virtual endpoint will require a SAML token (Federated Security scenario). Effectively, the objective of this use case will be to enable my BizTalk service to be a “claims-aware” application with no coding or any changes in how my existing BizTalk application is deployed and configured.

Cheers,

Steef-Jan

Wednesday, April 09, 2014

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).

clip_image002

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.

clip_image004

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]

The first endpoint will be an endpoint that uses transport security (https) with SOAP 1.2 binding.

clip_image007

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.

clip_image008

The second endpoint will be configured with basicHttp and transport-level security (https) that requires username/password client credentials.

clip_image009

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.

clip_image010

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.

clip_image011

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.

clip_image013

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.

clip_image014

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).

clip_image016

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.

clip_image018

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.

clip_image020

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.

clip_image022

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