BizTalk360 version 7.8 released – EDI reporting, System Profile and User Profile

In the first part of the 7.8 release article, we covered in detail about BizTalk Server “Advanced Process Monitoring” capabilities we added in 7.8 release. In this part 2 article let’s take a deep look at the other new features we bundled in 7.8 EDI reporting capabilities inline with BizTalk Admin Console System Profile : […]

The post BizTalk360 version 7.8 released – EDI reporting, System Profile and User Profile appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

BizTalk360 version 7.8 released – Advanced Process Monitoring

We are still maintaining the agile way of building BizTalk360, listening to customers feedback and bring 4-5 key features in every release once in 4 months. Our last major release 7.5 was back in July,2014. You can view our complete release history here. In this version we are adding the following key capabilities Advanced Process […]

The post BizTalk360 version 7.8 released – Advanced Process Monitoring appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

MABS – BizTalk Portal Supports Organizational Accounts

MABS – BizTalk Portal Supports Organizational Accounts

For some time now, one of the top customer request has been the ability to manage BizTalk Portal with corporate (Active Directory) identities rather than just the Microsoft accounts (Live IDs). With the latest update you can now also use Organization accounts to manage your BizTalk Service from BizTalk Portal.

Associating Azure Active Directory with BizTalk Portal allows you to centralize identity management, enable single sign-on across a broad array of cloud services, enforce multi-factor authentication.

What you need to know:

When the first user logs into the BizTalk Portal and registers for BizTalk Service by providing the ACS issuer name and issuer key one of the following happens:

–       You register for a BizTalk Service deployment using an organizational account in an Azure Active Directory (like FirstName.LastName@microsoft.com or FirstName.LastName@contoso.com).
In this scenario, only Azure Active Directory users can manage the BizTalk Service using the BizTalk Services portal. A Microsoft account or a guest user in the associated Active Directory cannot be used.

–       You register for a BizTalk Service deployment using a Microsoft account (like FirstName.LastName@live.com). In this scenario, only Microsoft Account users can manage the BizTalk Service using the BizTalk Services portal. An organizational account cannot be used.

Important: We do not yet support changing association of BizTalk Services from Microsoft Account to Active Directory and vice versa. Thus an existing BizTalk Service would continue to be associated with Microsoft Account.


Blog Post by: BizTalk Blog

1 month, 3 events – The story

1 month, 3 events – The story

This last few days were quite busy in terms of speaking engagements. In less than 1 months I was invited to speak in 3 events: BizTalk Innovation Day Oslo, LIX Edition of SQLPort Community (Porto – Portugal) and in SQLSaturday #341 – Porto, Portugal. BizTalk Innovation Day Oslo 2014 The first one was in September […]
Blog Post by: Sandro Pereira

Calling an on premise Microsoft Dynamics CRM using BizTalk and Active Directory Federated Security (ADFS)

Calling an on premise Microsoft Dynamics CRM using BizTalk and Active Directory Federated Security (ADFS)

Federated security is a great way of accomplishing single-sign-on (SSO) security for your applications. It’s also a technique that is becoming increasingly relevant as things move to the cloud and we’re starting to get more hybrid situation with some applications on premise and some in the cloud.

Active Directory Federated Security (ADFS) is an implementation of federated security and is used by a number of Microsoft Applications, Microsoft Dynamics CRM being one of them.

Windows Communication Foundation (WCF) has a few techniques to simplify federated security communication and this post will show an example of using Microsoft BizTalk Server and WCF to communicate with an ADFS secured CRM installation.

What is federated security?

Federated security at its core is pretty simple. In our scenario BizTalk Server (client) wants to login in and authenticate itself with the CRM system.

Traditionally the CRM system then had to manage the credentials for the client and verify these as login happened. There a number of drawback to this, the main one being that it doesn’t scale that well when we’re getting many separated systems that need access to each other as login information and login logic is spreads out across a number of systems.

When using federated security each part instead chooses to trust a common part (in this case the ADFS and AD), and as long as someone provide a token that can be validated with the trusted part, the CRM system will trust that it already has been authenticated and that everything is ok.

Data flow

  1. Authentication and requesting token
  2. Authentication against AD
  3. Login authenticated
  4. ADFS token response
  5. ADFS token based authentication
  6. Response from CRM

So basically a federated security model allows for separating all authentication and authorization out to a separate system.

As mentioned ADFS is just an implementation of federated security were Active Directory acts as the main repository with a Security Token Service implementation on top of it.

BizTalk and ADFS

As BizTalk has great WCF support we can use the WCF stack to handle all of communication with ADFS and CRM. But it does involve a fair bit of configuration. BizTalk and Visual Studio will help in most mainstream WCF scenario where one can point Visual Studio at the WSDL location and a basic binding file is generated for us. However, in the case of and ADFS based WSDL this will just result in an empty binding file that doesn’t help much.

Lots of projects I’ve seen makes the decision at this point to use custom code and create a facade to solve authentication. As Microsoft Dynamics CRM comes with a nice SDK including a C# library to handle authentication is easy to understand how one would end up using that. The problem is however that this creates another code base that again needs to be maintained over time. One could also argue that using custom code that is called by BizTalk further complicates the overall solution and makes it harder to maintain.

So let’s configure the authentication from scratch using Windows Communication Foundation.

Choosing the right WCF binding

First thing to do is to choose the right WCF binding. Let’s create a WCF-Custom Static Solicit-Response send port and choose the ws2007FederationHttpBinding.

Choose binding

Adding the Issuer

First thing we need to add is information on how to connect to the Issuer. The Issuer is the one issuing the ticket, in our case that’s the ADFS.

Issuer details

First we need to add information about the address of the Issuer. The WSDL tells us that the mex endpoint for the ADFS server is located at https://adfs20.xxx.yy/adfs/trust/mex.

Mex file

Browsing the WSDL for the ADFS server shows a number of different endpoints. Which one to use depends on what kind of authentication being used when requesting the token. In our case we’re using a simple username and password so we’re using the usernamemixed endpoint (https://adfs20.xxx.yy/adfs/services/trust/2005/usernamemixed).

Secondly we need to add information about the binding and the binding configuration for communication with the ADFS service.

What this basically means is that we need to add information to a second, or an inner, binding configuration. The BizTalk Server WCF configuration GUI doesn’t provide a way to set this so the only way is to configure this is to use one of the relevant configuration files (“machine.config” or the BizTalk config) and ad a binding manually.

<bindings>
 <ws2007HttpBinding>
  <clear/>
  <binding name="stsBinding">
   <security mode="TransportWithMessageCredential">
    <transport clientCredentialType="None"/>
    <message clientCredentialType="UserName" establishSecurityContext="false"/>
   </security>
  </binding>
 </ws2007HttpBinding>
</bindings>

Once this is setup we can point our BizTalk Server WCF configuration to the correct URL and reference the WCF inner binding we just configured.

Issuer configured

Finally we need to provide the username and password to authenticate ourselves to the ADFS server.

Login details

We now have communication setup to the ADFS service and should be able to get a valid ticket that we then can use to authenticate ourselves to the CRM system!

We now however also need to provide information on how to connect to the actual CRM system.

Configure communication to CRM

The rest is easy. Let’s start with adding the URL to the end service we want to call. As with any other service call we’ll also add the SOAP Action Header that in this case is the Update service (http://schemas.microsoft.com/xrm/2011/Contracts/Services/IOrganizationService/Update) of the OrganizationService service.

Service details

As out service also uses SSL for encryption we need to tell the binding to use TransportWithMessageCredentials.

Transport encryption

Establishing a Security Context – or not

Finally there is a little tweak that is needed. WCF supports establishing a Security Context. This will cache the token and avoid asking the STS for a new token for each call to the CRM system. BizTalk Server however doesn’t seem to support this so we need to turn it off.

Security Context

Conclusion

Understanding federated security is important and will become increasingly important as we move over to systems hosted in the cloud – federated security is the de facto authentication standard used by hosted systems in the cloud. Avoiding custom code and custom facades is a key factor in building maintainable large scale BizTalk based systems over time. BizTalk has great WCF support and taking full advantage of it is important to be able to build solutions that easy to oversee and possible to maintain not just by those familiar and comfortable in custom code.

Serializing Custom .Net Types for use with the Azure Redis Cache

Serializing Custom .Net Types for use with the Azure Redis Cache

In my previous post I looked at a real-world example of using the new Azure Redis Cache. One thing that was missing was the storing of custom .Net Types as cache values, which we’ll look at here. The RedisValue Type The Microsoft Azure documentation recommends using the StackExchange.Redis API for accessing the Redis Cache. This […]
Blog Post by: modhul

Exam 70-499 MCSD:ALM Recertification exam prep

To keep the Microsoft Certified Solution Developer: Application Lifecycle Management (MCSD:ALM) certification current you must complete a recertification exam every two years. Since the release of the MCSD:ALM certification, many of our students have taken our TFS courses to help … Continue reading →

The post Exam 70-499 MCSD:ALM Recertification exam prep appeared first on QuickLearn Blog.

Blog Post by: Anthony Borton

BizTalk 2013 Solution Template

BizTalk 2013 Solution Template

The mad coder has blogged about a BizTalk 2010/ Visual Studio 2008 Solution template based on Dan Rosanova’s book – BizTalk Patterns 2010 If you try to install this on BizTalk 2013/ Visual Studio 2012 you get this error. After modifying the source.extension.vsixmanifest as described here and recompiling the mad coder solution gives a VSIX, […]
Blog Post by: mbrimble