Forefront Identity Manager (FIM) 2010 R2 SP1 Released

FIM 2010 R2 SP1 now supports (among other things) the following so that the customers can now run FIM on the latest and greatest Microsoft platform

  1. Windows Server 2012
  2. SQL Server 2012
  3. Visual Studio 2012
  4. SharePoint Foundation 2013
  5. Exchange 2013
  6. Internet Explorer 10
  7. Windows 8
  8. Outlook 2013

For more details check this out:

Leave a comment

Posted by on January 18, 2013 in FIM


Sliding Window Session for your Relying Party

Here is a quick code that you need to include in your relying party’s global.asax file to setup a sliding window session for your federated / claims aware application.

        void SessionAuthenticationModule_SessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e)


           DateTime now = DateTime.UtcNow;

           SessionAuthenticationModule sam = sender as SessionAuthenticationModule;

           e.SessionToken = sam.CreateSessionSecurityToken(e.SessionToken.ClaimsPrincipal, e.SessionToken.Context, now, now.AddMinutes(1), e.SessionToken.IsPersistent);

           e.ReissueCookie = true;


The above code set the sliding window to 1 minute.


Tags: , , , , , , , , , ,

Retrieving the original RP context (wctx) at the IdP, after passing through ADFS as the FP / R-STS

In some cases, you may need to retrieve the context of the RP at the IdP end after passing through the FP.

For example, your IdP may want to know the name of the RP for which the token is being sought (although this may not a good design). In such cases it is possible to retrieve the context of the RP if you are using ADFS as the federation provider.

By default, the ADFS server encodes all the original context information about the relying party within a cookie when redirecting the user to the IdP. However, if you go the web.config file of ADFS and change the following context element to false, you will see now that the url when accessing the IdP contains a huge queryString  (about half a page long).

<context hidden=true />

What has happened is, ADFS instead of putting the original RP context into a cookie has stored it on the URL itself, but the original query sting is nested within another queryString, so if you are using a custom STS as your identity provider, you can use the following code to retrieve the original context.

string wctx = Request.QueryString["wctx"];

string baseUrl = System.Web.HttpUtility.ParseQueryString(wctx).Get(“BaseUrl”);

Uri uri = new Uri(baseUrl.Replace(“\\”, “?”));

string wtRealm = System.Web.HttpUtility.ParseQueryString(uri.Query).Get(“wtrealm”);


Tags: , , , , , , , , , , , , , , ,

Automating Home Realm Discovery (HRD)

In most common Identity Federation scenarios, there are multiple external Identity Providers (IdP), but the relying party (RP / claims aware app) depends and trusts only one STS (Security Token Service) to provide the claims.

This STS is known as the Federation Provider (FP) or R-STS (Relying Party STS). So when you access the relying party application, it will redirect you to the R-STS (the only STS it knows) to get authenticated, now since (typically) R-STS / FP is not an Identity Provider (IdP), it will (typically) provide you a list of trusted identity providers so that you can choose the one you wanted to get authenticated with.

But in some cases, especially if you are using the application frequently and you know which IdP you wanted to get authenticated with, you would like to avoid that annoying extra step / screen where you need to choose the IdP and wish the system knew it instead of asking every time.

Well there are multiple ways of achieving the same, below are some of the options:

 1.       The (default) cookie based approach

The default behaviour is that, the first time you select the Identity Provider and get successfully authenticated, a persistent cookie is created that is valid for 30 days. This means you don’t need to worry about selecting the identity provider for the next 30 days, however this can have the following issues:

a.        Every time you clean up / clear the cookies, you will need to set it up again

b.       If you want to change to another Identity Provider, you will need to clear the cookies or for temporary purposes use an “In Private” browser session

This default behaviour can be modified, in ADFS’s web.config located (default) at C:\inetpub\adfs\ls

 <persistIdentityProviderInformation enabled=true lifetimeInDays=30 />

You can either modify the lifetime of the cookie or make it a non-persistent cookie in which case, it will ask you for home realm discovery on every new browser session (not what we want)


2.       Using the WHR parameter within the queryString / URL

Another approach is to use the WHR parameter in the URL / queryString when accessing the relying party as shown below:

ADFS by default understands the WHR parameter, however, you need a paste a little code in your global.asax of the relying party for WIF to go the magic. Here is the code that will do the trick:

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e)


            string strWhr = HttpContext.Current.Request.QueryString["whr"];

            if (strWhr != null)


                   e.SignInRequestMessage.HomeRealm = strWhr;




What you are doing here is basically hooking up your code to the event WIF raises just before it calls out / redirects to the FP. In the code snippet above you are checking to see if the URL contains a querystring with a WHR parameter, if so you assign the value of that parameter to the HomeRealm property of the SignInRequestMessage.


3.      Hardcode the IdP’s endpoint within RP’s web.config

I would like mention here that the last two approaches we saw are useful for the end-user or the client browser to customise the behaviour, where each end user might want to choose a different identity provider for the same relying party. However, if you have a scenario where the users of your relying party can be authenticated by a particular identity provider, then you may have to resort to the technique mentioned in this section.

You might ask…, “…well, if the RP can be authenticated by one identity provider only, then why are we even providing a HRD page and choice of multiple Identity Provider?…”. Well you should be conscious of the fact that in a real production environment the Federation Provider may not be dedicated to your relying party alone, maybe it is an Org-wide FP and multiple RPs are using it to federate with various identity providers, but your scenario might demands that the FP redirects the user to a particular IdP only and not provide an option to choose from.

You can configure your relying party to automatically pass through the FP and get redirected to the designated IdP by assigning the IdP endpoint using the HomeRealm attribute of the <wsFederation> node in the <federationConfiguration> of the web.config as shown below:



      <cookieHandler requireSsl=true />

      <wsFederation homeRealm=





passiveRedirectEnabled=true />




4.      Customise the HRD page.

Finally (for ultimate flexibility) you can modify the HomeRealmDiscovery.aspx file and the associated HomeRealmDiscovery.aspx.cs file and provide your own custom logic.

Or you can leave them intact as is, and provide your own custom HRD page and point to it from the ADFS web.config by modifying the element shown below.

<homeRealmDiscovery page=HomeRealmDiscovery.aspx />



Tags: , , , , , , , , , , , , ,

A SignInResponse message may only redirect within the current web application

If you have developed  a claims aware federated application (relying party) using Windows Identity Foundation (WIF), you may have noticed that when you type the URL of your application, you get redirected to the configured STS, get authenticated and all that token dance and when finally everything is working and you the redirect you get back to the relying party application boom!… you get the following error…

ID3206: A SignInResponse message may only redirect within the current web
application: ‘/xxxxx’ is not allowed.

Turns out (after wasting enough time figuring out what happened and searching for answers on the internet if you are a newbie), you missed the trailing slash ‘/’ at the end of the URL to your relying party…

Frustrating isn’t it? There are multiple ways to fix this problem… here is a quick way to solve this…

You can check for the trailing slash ‘/’ and redirect in the Application_BeginRequest method of global.asax as shown below

    private void Application_BeginRequest(object sender, EventArgs e)


        if (String.Compare(Request.Path, Request.ApplicationPath, StringComparison.InvariantCultureIgnoreCase) == 0 && !(Request.Path.EndsWith(“/”)))
Response.Redirect(Request.Path + “/”);


Leave a comment

Posted by on November 17, 2012 in Windows Identity Foundation


Tags: , , , , ,

BizTalk Server 2013 Beta Released

The BizTalk product group decided to do a major release… instead of BizTalk 2010 R2, announced the release of BizTalk Server 2013 Beta yesterday…

Download here :

BizTalk now supports the latest and greatest in Microsoft technologies including .NET 4.5, Visual Studio 2012, SQL Server 2012 among others…

Other much sought after features include:

  • Integration with Cloud Services – BizTalk Server 2013 Beta includes new out-of-the box adapters to send and receive messages from Windows Azure Service Bus.
  • RESTful services – BizTalk Server 2013 Beta provides adapters to invoke REST endpoints as well as expose BizTalk Server artifacts as a RESTful service.
  • Enhanced SharePoint adapter – Integrating with SharePoint using BizTalk Server 2013 Beta is now as simple as integrating with a file share.
  • SFTP adapter – BizTalk Server 2013 Beta enables sending and receiving messages from an SFTP server.
  • ESB Toolkit integration – With BizTalk Server 2013 Beta, ESB Toolkit is now fully integrated with BizTalk Server. Also, the ESB Toolkit configuration experience is vastly simplified to enable a quick setup.
  • Dependency tracking – The dependencies between artifacts can now be viewed and navigated in Admin console.
  • Improvements in dynamic send ports – BizTalk Server 2013 Beta provides the ability to set host handler per adapter, instead of always using the default send handler of the adapters
Leave a comment

Posted by on November 6, 2012 in BizTalk, Integration


Tags: , , , , , , , ,

Static code analysis for BizTalk using BizTalkCop

The Problem
If you have been a BizTalk developer long enough, you will know that application lifecycle management has always been a pain point when it comes to managing BizTalk projects.
The Out-of-Box support available in BizTalk Server is not too great for things like automated builds, continuous integration, code analysis, code coverage, unit testing… I can go on and on, but I am sure you get the picture.
Thankfully, most of these are set to improve with the upcoming release of BizTalk Server i.e. BizTalk Server 2009, but there are still improvement areas that I hope the product group will address soon.
One of the other hard things (IMHO) that one needs to do early-on in a BizTalk project is to decide on the naming convention and projects structure for modular deployment. Sometime this is dictated by your customer and sometimes you just follow what has been decided by your company, simple isn’t it? Wish life was that easy :)
In reality you will find that customers want you to use their own guidelines that are often not complete or not fully thought-out, and you end up using that and try to fill the gap or modify it by adding your own stuff.
Is this so bad?… not if you have gone through this exercise and got it frozen and signed off before you start your development / coding, else, this can turn out to be the cause for endless frustrations for you and your team.
This is especially true for BizTalk projects, where you know that small changes to things like namespaces or typenames can cause a rippling effect across the project, and you end up rebuilding / reconfiguring all of the artefacts.
I have been on multiple projects in the past where naming conventions changed almost every week while the project was halfway through the development phase, so this is not an uncommon thing; however you need to be aware of this and take measures to avoid getting into such situations.
Another challenge is in sticking to the guidelines or conventions that you have so painstakingly chosen and frozen. If you have a large team, you will often see that not all developers are fully aware of the guidelines and conventions that are being followed in the team, especially when developers are constantly moving in and out of the team.
So what can be done in such situations? One of the things you can do on your BizTalk project is to run a static code analyser as part of your daily builds. I have always been a huge fan of build automation and the niceties that come along with it like automated testing, static code analysis report, code coverage report etc. There is nothing that makes you happier than getting up in the morning gazing at your PDA / mobile device to see that there were no errors or build breaks on the nightly build, especially when you are the Dev Lead / Architect on the project.
You must be thinking… “all this is great… but isn’t this is a BizTalk Solution?… how do you automate checking naming conventions?… especially on things like orchestration shapes, map names, physical ports etc…”. well you are in luck, you can now do static code analysis on BizTalk solutions too, thanks to Elton Stoneman for this cool new tool/plug-in called BizTalkCop available on codeplex.
Check out the links:
BizTalkCop is essentially a set of FxCop rules that will allow you to inspect BizTalk assemblies for structure and naming convention of your BizTalk artefacts such as Orchestrations, Pipelines, Schemas, Maps etc. It can even look into the deployed solutions inside BizTalk Server (using BizTalk Object Model and BizTalkMgmtDB) to validate the names of your physical ports and receive locations on your deployed BizTalk Server application.
If you are already familiar with FxCop, BizTalkCop provides you the same experience since it is just an extension of the FxCop ruleset.
BizTalkCop is currently is release 1.0 and contains a set of rules based on Scott Colestock’s naming conventions, but they’re (mostly) configurable so you can modify them to suit your own standards. You can create your new custom rules as well, since the full source code is provided with base classes and frameworks.
Another thing to note is that since BizTalk (2006/R2) projects are not integrated with Code Analysis tool in Visual Studio 2005, you need to download and install FxCop separately before installing BizTalkCop (even if you are using the Team Suite edition of Visual Studio 2005). I have not tried it with BizTalk 2009 Beta yet since I have it on Professional edition of Visual Studio 2008 installed on my VPC (Code Analysis is available only on Visual Studio Team Suite).
The link above provides instructions on how to install and configure BizTalkCop so I am not going to detail it out here.
Demo – The Bad Project
Let me illustrate the usefulness of BizTalkCop by running it on a badly done solution. I created a very simple BizTalk application a la “Hello World” in BizTalk (I call it the ‘BadProject’) without giving much attention to the project structure or naming convention (just used the default names, like we do most of the time). The application basically receives an inventory replenishment request; the request is transformed into a purchase order request and is sent out. For simplicity sake, both the receive port and the send port use FILE adapters.
So essentially, my BizTalk project consists of a single BizTalk project within which there are two Schemas, a Map and an Orchestration as shown in the solution explorer screenshot below:
The orchestration, transformation and schemas are all very elementary as shown below (notice the naming of the artefacts highlighted).
After I have built and deployed the solutions, I fire up FxCop, load the target BizTalk application assembly and hit the Analyze button. I selected only BizTalkCop rules and unchecked others
Note: You also need to make sure that BizTalkCop is configured to point to the right BizTalk application so that it can validate the application level artifacts like the physical post names etc.
You see from the screenshots that many errors (about 28 of them) are generated for such a simple application.
Here are the errors:
The errors are pretty self explanatory so I don’t want to go through each of them.
1.     Port names should be prefixed with their direction – start ‘ReceivePort1′ with ‘Receive.’
2.     Port names should be prefixed with their direction – start ‘SendPort1′ with ‘Send.’
3.     Receive Location names should be prefixed with their Receive Port name – start ‘Receive Location1′ with ‘ReceivePort1′
4.     Receive Location names should be suffixed with their transport type – end ‘Receive Location1′ with ‘.FILE’
5.     Artifacts should be declared in modules with the correct suffix – consider module name ‘BadProject.Schemas’
6.     Schema names should end with the data format. Format: ‘inventoryRequest’ is unknown
7.     Schema names should begin with the root node. Start: ‘inventoryRequest’ with: ‘Root’
8.     Artifacts should be declared in modules with the correct suffix – consider module name ‘BadProject.Transforms’
9.     Map names should have the format “SourceSchema_DestinationSchema”
10. Artifacts should be declared in modules with the correct suffix – consider module name ‘BadProject.Orchestrations’
11. Orchestration members should be Camel cased. Replace Message name: ‘InvReqMsg’ with: ‘invReqMsg’
12. Orchestration members should be Camel cased. Replace Message name: ‘PurchaseOrderMsg’ with: ‘purchaseOrderMsg’
13. Orchestration members should be Camel cased. Replace Port name: ‘Port_1′ with: ‘port1′
14. Orchestration members should be Camel cased. Replace Port name: ‘Port_2′ with: ‘port2′
15. Orchestration shapes should be correctly named – replace ‘ConstructMessage_PurchaseOrder’ with ‘Construct_PurchaseOrderMsg’
16. Orchestration shapes should be correctly named – replace ‘Transform_InvToPurchaseOrder’ with ‘Transform_inventoryRequest_purchaseOrderSchema’
17. Orchestration Shapes should have the correct prefix – start ‘MessageAssignment_1′ with ‘Assign_’
18. Orchestration Shapes should have the correct prefix – start ‘Receive_InvRequest’ with ‘Rcv_’
19. Orchestration Shapes should have the correct prefix – start ‘Send_POMsg’ with ‘Snd_’
20. Orchestration types should be Pascal cased. Replace Port Type name: ‘PortType_1′ with: ‘PortType1′
21. Orchestration types should be Pascal cased. Replace Port Type name: ‘PortType_2′ with: ‘PortType2′
22. Orchestration Types should have the correct suffix – end ‘PortType_1′ with ‘PortType’
23. Orchestration Types should have the correct suffix – end ‘PortType_2′ with ‘PortType’
24. Orchestration Types should have the correct suffix – end ‘Port_1′ with ‘Port’
25. Orchestration Types should have the correct suffix – end ‘Port_2′ with ‘Port’
26. Artifacts should be declared in modules with the correct suffix – consider module name ‘BadProject.Schemas’
27. Schema names should end with the data format. Format: ‘purchaseOrderSchema’ is unknown
28. Schema names should begin with the root node. Start: ‘purchaseOrderSchema’ with: ‘Root’
You can also save the FxCop project and use it in the command line option to generate a pretty cool report as show below.
Demo – The Good Solution
Now I took the same solution and made changes by following the naming conventions and also restructuring the solution to be suitable for modular deployment. You see from the illustration below, I have split the application into three separate projects so that it is not only easier to maintain and saves time during development, but it is absolutely critical that it is broken in this manner from an administration point of view when the solution is in production. Any seasoned BizTalk developer / administrator will understand what I mean here, it’s a whole different topic and don’t want to get swayed into that.
You also see in the solution explorer above that the name of some of the artefacts have also been changed in accordance with the naming convention. For example, the schema names indicate the data format and the root node name of the schema. I also made sure that the physical ports confirm to the naming standards.
The orchestration, map and the schemas below show that changes have been made in the names of the artefacts.
You can see from the below screenshots that the errors have been reduced to just one error.
To sum it all up, I feel FxCop / BizTalkCop makes a great tool to have in your arsenal for that next BizTalk project you are waiting for or even in your current project. Saves you (or the SQA team) a lot of time from having to check for the naming conventions manually on a routine basis and provides you reports on demand.

It can be used both on the individual machines as well as on the build server. You can integrate it with your build scripts so that your application health report now also includes static code analysis among other things. This way you can be assured and can sleep peacefully knowing that the code drop you just sent to the customer conforms to all the naming conventions without having to manually review it at the eleventh-hour, not to mention the amount of time saved. I hope to see many more new rules and improvements from Elton in future releases of BizTalkCop.

Leave a comment

Posted by on March 1, 2009 in BizTalk, BizTalkCop, Integration


Tags: , ,


Get every new post delivered to your Inbox.