I was setting an ADFS 3.0 lab setup and thought I would share couple of gotchas – nothing particularly new here but could save someone some time.
Gotcha #1: Use Different Federation Service Name
In my case, I wanted to set my federation service on the same domain controller machine. This is of course not realistic in a production setup, but it’s common in a lab setup as you’d be preparing a POC or just playing around with stuff.
In this case, you cannot have the Federation Service name the same as the server name. In other words, my machine FQDN is “dc1.lab1.local”. Therefore I cannot have my federation service URL as: https://dc1.lab1.local/adfs/ls.
Instead I need to create a different service name; say for example “fs1.lab1.local”. So the URL will be https://fs1.lab1.local/adfs/ls.
In this post we will examine some of the techniques used to build the Payment Upload process. You will see transactions, debraching messages, streaming and using XLANGMessages.
The Business Process
In the previous post we saw the main bill upload process. What I left out was the process that handles failed message routing.
The Famous Failed Routing Error
In the previous post, I showed you how correlation is vital for the correct operation of a business process. However, this correlation – being based on matching field values – is subject to failure.
For example, in our process, say that the bank sent the Bill Confirmation Rq, with a wrong AsyncRqUID. Using correlation BizTalk will try to route the message to running Ox instance but it won’t be able to do so.
In order to see this, drop a bill request message into the folder. Now while the process is waiting for the confirmation rq message, edit the asyncrqid. Now drop the message in the confirmation request folder. If you examine now the event log you will see the famous error: “The published message could not be routed because no subscribers were found”. This happened because BizTalk was not able to match the correlation and no other subscribers were found for the message.
The Business Process
The first process is the Bill Upload Process:
This starts a series of articles about a BizTalk business process scenario. The entire solution can be downloaded from here:
The Scenario is a modification of a real business case for a payment gateway.
The gateways acts as a medium between vendors and banks:
DTC and the 2 Phase Commit Protocol
Atomic Transactions rely on automatic commit and rollback actions. Therefore they need a system to manage these actions implicitly. The name of this system is Transaction Manager.
There are multiple kinds of transaction managers, each used for a certain transaction protocol. For a detailed discussion check my WCF Transactions Pluralsight course. But for the sake of this discussion, we care about the WS-AT protocol, and a particular Transaction Manager – called the Distributed Transaction Coordinator – or DTC.
DTC is familiar to most developers, and is capable of managing transactions across process and machine boundaries.
DTC and Atomicity
So DTC has a tough challenge: while the Consisteny, Isolation, and Durability attributes are managed by Resource Managers (RMs), DTC must preserve the atomicity attribute, and it must do this over multiple participants that are most probably distributed over multiple machines.
In the previous article we understood WS-Trust and WS-Federation and saw briefly how they are used with WCF. Now let’s see an example of how to configure a WCF service to delegate authentication to an STS.
Here I will configure my WCF service to delegate authentication to ADFS. The federation service namespace is “fs1.lab1.local”.
The following section sets the service certificate; the one that will be used to access the service over SSL (this is a self-signed certificate using makecert):
Course Serialization in .NET 4.5 has been released.
This course equips viewers with essential knowledge about serialization in the .NET Framework. No matter what .NET technology developers are using – whether it’s ASP.NET, WCF, Web API, or desktop applications – they will definitely encounter situations where serialization is needed. This course helps them understand the different alternatives and what is the best choice in each scenario.
Watch it here:
The need for WS-Trust
In a previous article I talked about how clients use WS-Security to authenticate themselves to services using variety of tokens. So if authentication is covered by WS-Security, what exactly does WS-Trust bring to the table?
To answer this, let’s consider the simple scenario of a client wanting to authenticate to a service. As you have seen before, the client will have to present its token to the service. So the first clear disadvantage is that the authentication logic is actually part of the service. Services should satisfy business needs only, and service developers should worry about business only. Anytime spent creating authentication logic is a wasted time from the perspective of business.
Now, what if the service – who used to accept username tokens for authentication – had its policy changed, and now requires client certificates? This requires change to the service policy and code because authentication logic is actually part of the service.
To run the samples download this solution:
I will point out what each project in the solution does in corresponding section.
Steps Overview to configure WS-Security in WCF
Bindings and Behaviors
In general WCF security can be configured using Bindings and Behaviors.
- Using Bindings you can configure message protection and authentication types.
- Using Behaviors you can configure credentials to be used for message protection and authentication as well as credential validation settings
Security Configuration settings – just like the majority of WCF configurations – can be set in the configuration files or programmatically. There are some exceptions to this rule where some configuration can be set only by code; for example, setting usernames and passwords can only be done programmatically in order not to allow developers to hard code these values in the configuration file.
Overview of steps to configure WS-Security
WCF provides a configuration model to set every aspect of WS-Security. This configuration can be achieved in 3 steps:
In Step1, we set the Basic Message Security Settings:
- First, you configure the service to use a binding that supports WS-Security. As is the case in most examples in this course, I will be using the WSHttpBinding
- You then set the service to use Message security. For some bindings, this is the default security mode anyway, but explicit configuration is required when you need to edit the default settings.
- Then you select the sensitive data you want to secure. Recall that a main advantage of message security over transport security is the ability to selectively secure parts of the message, thus reducing overhead.