Home > BizTalk Server > BizTalk R2 Authorization using WCF

BizTalk R2 Authorization using WCF

As some of you may have noticed, I gave a rather scathing review of how WCF implements authorization (and hence how R2 implements authorization for WCF services).  To see that post, click here.  Although I’m still very disappointed, I’d like to share an approach that accomplishes the goal I had in mind: being able to dynamically specify, via means of configuration, the users that should have access rights to the service.  This approach was built by Vijay Naidu, a colleague of mine.

Vijay read my first blog, and took the time to “code” authorization into his web service.  With a little tuning, the solution you’re about to see resulted, which I think is much better than the out-of-the-box solution.  This solution leverages the SSO database to store the authorized users (the code example you’ll see in this post is written to authorize a single user, but hopefully you wouldn’t have trouble using a delimited list of users).  In addition, Vijay’s solution creates a shared component that can be leveraged by multiple projects without recoding the initial setup.  When mixed with Richard Seroter’s SSO storage tool (I use the variant by Paul Petrov), you’ll find that you can set up authorization dynamically.  Hence, I figured you might be interested.  Here were the steps involved:

First, the machine.config file was modified adding this entry:

<add name=”AcmeWCFCustomAuth” type=”Acme.WcfServiceBehaviors.CustomBehaviorElement, Acme.WcfServiceBehaviors, Version=, Culture=neutral, PublicKeyToken=02ae73d8d306f338″ />

Secondly, this code was written and added to an assembly (the one mentioned above in the machine.config file).

if (context.PrimaryIdentity.IsAuthenticated)
userName = context.PrimaryIdentity.Name;
//Get the application name for parsing the Endpoint Uri Absolutepath (ex: /Acme.GlobalSafety.EnsureSafety/ImportantAuth.svc)
ApplicationName = operationContext.EndpointDispatcher.EndpointAddress.Uri.AbsolutePath.ToString();
WcfUriAbsolutePath = ApplicationName.Split(‘/’);
ApplicationName = WcfUriAbsolutePath[1].ToString();(ex: Acme.GlobalSafety.EnsureSafety)
//Get the SSO Config entry for the user to authenticate (ex: domain\LoginUser).  This call refers to the SSO tool mentioned earlier
wcfAuthUserName = Acme.SSO.Utility.SSOConfigHelper.Read(ApplicationName, “WCFClientAuthUserName”);
if (string.Compare(userName.ToUpper(), wcfAuthUserName.ToUpper()) != 0)
return false; //this returns an access denied error

This assembly was then compiled, installed in the GAC, and the BizTalk host was restarted. Next, using the BizTalk Administrator, a Request/Response WCF-Custom receive location was created.  Under the Service Behavior tab the AcmeWCFCustomAuth binding was added.

Next, the WCFClientAuthUserName property was added to the SSO Config database (using the tool mentioned earlier).

That’s it.  It may have seem like a bunch of work (and I admit that I don’t want developers redoing this entire thing), which is the beauty of this solution.  Subsequent applications that want to leverage this solution only need to repeat the steps in the last two paragraphs, which isn’t bad.  The other advantage of this approach, as opposed to putting the username in some configuration file out on disk, is that the SSO databases are part of the BizTalk daily backup job.  In the event of a disaster, they will be recovered, along with all of your beautiful authorization configurations.  🙂

Categories: BizTalk Server
  1. Myles
    October 7, 2009 at 2:18 am

    Hi Victor. Thanks for this very interesting article. What is the benefit of this approach over the “traditional” approach I am considering using: restricting access to the web services with IIS & Windows groups.

    That is, the access control is managed by IIS itself, checking that the authenticated Windows user has rights to the web service before BizTalk is even called.



    • October 7, 2009 at 8:30 am

      The traditional approach can only provide authentication and authorization with ASMX services, but with WCF, this can’t be done within IIS (this is unfortunate as pointed out by my earlier blog). You’ll find that if you use the “Permissions” capability of IIS, it has no affect on WCF services. Similarly, you must enable anonymous authentication for WCF services or it just doesn’t work! Give it a try – try restricting access to a particular user in WCF only using IIS and Windows groups; you should find it impossible. Of course, if I’m wrong – please be sure to let me know!

  2. Myles
    October 7, 2009 at 9:58 am

    HI Victor. Thanks for your feedback. I’ll let you know how I get on.



  3. March 2, 2010 at 6:03 am

    I guess one of the reasons the IIS settings wont apply is because WCF can be hosted outside IIS (eg) if you use TCP bindings, then IIS isnt going to be of any use. A custom approach seems the only logical answer because the product group cannot predict how you want to control access (ie) what granularity. All they can do is make things extensible. The approach you have outlined here is reasonable. You could also consider using things like Windows Identity Foundation. (http://msdn.microsoft.com/en-us/magazine/ee335707.aspx) Maybe in future, if the community broadly agrees on an approach , there maybe some merit in including it in the product. I also think that having services hosted in AppFabric linking to BizTalk will be a catalyst for a uniform authorization approach.


  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: