Thursday, October 23, 2014

BizTalk360 – An easy way to evaluate

BizTalk360 is a full featured BizTalk Server Monitoring & Operations product. The product has matured from a small web based monitoring tool to a full blown feature rich product for monitoring BizTalk Server. The product includes features for BizTalk Operation support people like the Throttling analyzer, Topology Viewer, and Backup DR Monitor. Recently a new version 7.8 has been released with another set of valuable features:
  • Advanced Process Monitoring and dashboard
  • EDI reporting capabilities in line with BizTalk Admin Console.
  • System Profile: Ability to remove features you don’t want in BizTalk360.
  • User Profile: Flexibility to set custom time zone and date/time format for each user.
  • Removed Orphaned artifacts from Monitoring: Ability to remove old orphaned artifacts like Applications, which no longer exist in the environment.
If you haven’t heard of BizTalk360 than you will like this blog post as it will explain how you can easily evaluate the tool by yourself and witness the great value this product can offer. Now this will be not an extensive post to showcase each feature. I will focus on how you can leverage the features: Graphical Flow (Tracking), Business Activity Monitoring (Portal), and the Tracking Manager.

Easy way to see these features in action is by deploying the BamEndToEnd example you can find in the <Samples Path>\BamEndToEnd\Input folder of the installation of your BizTalk Server. This sample stems from version 2004 and can be used from 2006 up to 2013 R2. The demonstrations in this post is the BamEndToEnd example with BizTalk Server 2013 R2, and the latest BizTalk360 Version 7.8.

After deploying the BamEndToEnd example you will need to create the tracking profile yourself and deploy it. Next you will to add/verify the tracking is enable on the send, receive ports and the orchestrations.

Note that tracking can be very useful for troubleshooting and traceability in general. However in production environments you beware that extensive tracking can influence performance. For best practices for tracking see blog post on BizTalkAdminsBlogging Best Practices for Tracking. With regards to orchestration tracking is that Event Tracking is enabled by default. This can be helpful during development, testing and troubleshooting with the Orchestration Debugger. In Production, these tracking events should be disabled, because these events are written to the TrackingData_x_x tables in the BizTalkMsgBoxDb database and then moved to the dta_DebugTrace table in the BizTalkDTADb database by the Tracking host. If the TrackingData_x_x tables (BizTalkMsgBoxDb database) and/or the dta_DebugTrace table (BizTalkDTADb database) get too large*, performance will be impacted, see How to maintain and troubleshoot BizTalk Server databases.

clip_image002

After deployment and configuration is done you can drop the test messages in the folder belonging to the receive location. In SQL Studio Manager you can execute the query below to examine if data is present in the BAMPrimairyImport database tables belonging to the BamEndToEndActivity.

clip_image004

When that is in order you can switch to BizTalk360 product. The product is available for free trail. The installation is straightforward described on the site on this page. Once you have installed and configured BizTalk360 you can start looking at some of the features. One is the Graphical Flow (Viewer). You can select this viewer and leave everything default and click Execute Query.

clip_image006

Next you can select one of the tracked service instances.

clip_image008

On right hand side you can see the properties of the third orchestration of the BAMEndToEnd example. You can click the blue dot (where the message is received) and see a line going from the green dot (message being send from a location) of the second orchestration. Now you can click in the right hand pane the context and/or content tab. You will see the context of the message going from Orchestration 2 to 3 and the content.

clip_image010

You can click the blue dot again and reach orchestration 1 the first orchestration message are flowing through. This feature is a very valuable feature in case you need to troubleshoot a process that for instance consists of multiple orchestrations. From a messaging perspective you can look at messages coming in and out of BizTalk. In the dashboard you can select Tracked Message Events instead of Tracked Service Instances. Select one of the Send Type the eye icon.

clip_image012

A dialog will appear for the message you selected. You can see the general properties, context properties and the content. Note this depends on how tracking is configured. For both Tracked Message Events and Tracked Service Instances you add filters that can enhance search ability for a certain message(s) and instance(s).

Next we will look at the Business Activity Monitoring. BizTalk360 offers a view/dashboard for BAM that is similar to the BAM Portal. One of the concepts of BizTalk360 is offering a single operation and monitoring experience. This means one product for accessing data and user experience (UI) for BizTalk, BAM, BRE, EventViewer, BizTalk databases and ESB Toolkit.

clip_image014

If you go to Business Activity Monitoring Dashboard in BizTalk360 you can do similar things one can do in the BAM Portal. In The BAM Dashboard you can select a BAM View. In this case the BAMEndToEnd View. Select columns and execute a query.

clip_image016

As you can see the data can be viewed from the dashboard. There is no need to go to a separate Portal in case your BizTalk solutions include BAM. The BAM Dashboard in BizTalk360 will also give you a view of the sizes of the BizTalk BAM Databases.

clip_image018

Sizes of your BAM databases matter. In case BizTalk system is under a huge load a significant amount will be persisted to the BAM database. Therefor information on size and growth are valuable. You can monitor this by setting alarms in BizTalk360.

The final feature I like to discuss in this context is the Tracking manager. For the BAMEndToEnd example you can enable tracking on send/receive ports and the orchestrations. By selecting the Tracking Manager in BizTalk360 you can examine how tracking is enable on the receive ports, send ports and orchestrations.

clip_image020

You can select different applications in this dashboard, examine if global tracking is enabled and how per application the tracking is set on receive/send ports and orchestrations. This manager or dashboard if you like gives you a quick view on how tracking is set up in your BizTalk environment. This can be useful in cases you have not direct insight of the bindings of the applications that are being deployed. The bindings can contain tracking settings, see for instance binding collection of a receive port on MSDN.

In this post I quickly showed three powerful features in BizTalk360. However, there are many more which you can examine by yourself or by reviewing the feature tour on the BizTalk360 site. In case you like to further explore the features BizTalk360 offers you can do so by using the BizTalk out-of-the box examples on a VM and the evaluation edition of the product.

Cheers,

Steef-Jan

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