Monday, December 08, 2014

INTEGRATE 2014 – Journey to next generation of integration

The beginning of december I visited the Microsoft Campus (Building 92) for the 3rd global BizTalk Summit, which was branded as Integrate2014. The event was organized this time by BizTalk360  along side with Microsoft itself and core partners like Quicklearn, Nevatech, Codit, and LogicalTech SysTalk. It was a three day event filled with numerous sessions by Microsoft themselves, a few MVP’s and partners.

WP_20141202_16_45_03_Pro__highres

The first important message to me, partners and end-users I believe was that BizTalk Server is going to play an essential role for integration systems and applications on-premise. Besides that its also provide support with connectivity to cloud (Azure with adapters that support SB-connectivity, and relay). That means BizTalk Server can also provide enterprises the ability to build cloud to ground or ground to cloud based solutions (see also Richard Seroter’s course on Pluralsight called Cloud Integration Patterns).  The product group explicitly shared that there will be future platform upgrades (full version, or R2). See also my post on the TechNet Wiki Blog: The Future of Integration.

WP_20141204_013

Second even more important message was the new direction for BizTalk Services. MABS 1.0 will change course to adopt architecture called MicroServices. This means that MABS 2.0 will fundamentally change to support this architecture. What the architecture basically boils down to is that granularity will increase. A BizTalk Service solution can consist of many small services like connectors (called triggers and actions), mediation (that supports VETER pattern we know from MABS 1.0), BPM, Mappings, and Business Rule Engine (BRE). During the event we have seen different sessions on MicroServices from different speakers. All sessions were recorded and will be made available soon.

WP_20141205_009

Finally the number of attendees and partners (sponsors) showed me that ecosystem of Microsoft Integration is very alive. Microsoft will continue to innovate it’s on-premise product BizTalk Server and it’s cloud based offering BizTalk Services, which will be named Azure BizTalk Microservices (MABS 2.0). We stand before the door to the next generation of integration solutions. We slowly we move (migrate) integration solution to Azure Platform and build new solutions to communicate with distributed systems (anywhere, anyplace, anytime) and devices.

WP_20141205_069

Other blog post on INTEGRATE 2014 definitely worth to checkout are:

It has been an amazing event and it was awesome to meet with people like Microsoft Integration MVP’s present, Microsoft BizTalk Product Group, Biztalk360 Team, Quicklearn Team, Andrew Slivker (Nevatech), Jason Sander, Dwaine Gilmour, Mandi Ohlinger, Richard Broida, Tom Canter, Rob Fox, Jean Paul Smit, Martin Peters, Rene Brauwers, JoAnn Een, Michael Shea, Koen van Oost, Eldert Grootenboer, Rex van der Laan, Bart Scheurweghs, Rajesh Kolla, Howard Edidin, and list goes on.

WP_20141204_022

BizTalk360 as event organizer have done an outstanding job taking the BizTalk Summit (Integrate) to the next level!

Cheers,

Steef-Jan

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