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
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
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
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
I was tasked last week with learning how to install SharePoint 2010 as part of our SharePoint IT Training Module. It’ll be easy they told me, or maybe they didn’t tell me that and I told myself that. It’s only an installation, how hard can it be? Famous Last words. Well after a long time […]
Blog Post by: Chris Magrane
There is no perfect cloud platform. Shocking, I know. Organizations choose the cloud that best fits their values and needs. Many factors go into those choices, and it can depend on who is evaluating the options. A CIO may care… Read More ›
Blog Post by: Richard Seroter
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.
- Authentication and requesting token
- Authentication against AD
- Login authenticated
- ADFS token response
- ADFS token based authentication
- 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
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.
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
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 (
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.
<message clientCredentialType="UserName" establishSecurityContext="false"/>
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.
Finally we need to provide the username and password to authenticate ourselves to the ADFS server.
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
As out service also uses SSL for encryption we need to tell the binding to use
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.
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.
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
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
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