Home > BizTalk Server > Authentication and Authorization of Incoming SOAP Requests to BizTalk

Authentication and Authorization of Incoming SOAP Requests to BizTalk

I’ve been meaning to write a blog on this subject for quite some time…  this blog will explain authentication and authorization of incoming SOAP messages to BizTalk.  Although it might seem like a simple subject to some, I’ve seen enough web apps deployed w/o authorization that I figure it’s worth writing about…

Here’s the short answer to how BizTalk authenticates and authorizes incoming SOAP messages: IIS. When I was first exposed to BizTalk I was disappointed to find that the BizTalk books I owned didn’t have a section in their index on authorization (perhaps this is the reason so many apps don’t use it).  I needed to be explicit as to who could access a particular web service.  I didn’t find anything in the BizTalk Admin Console under any of the receive locations/ports, and as a newbie to IIS, I wasn’t sure what exactly was available there.  I saw in IIS an easy way to provide authentication, but authorization wasn’t as clear to me.  So hopefully this will help the next IIS-newbie.

Let’s first talk about authentication.  Here is the authentication methods screen of the IIS Manager found by right-clicking on the deployed web app and choosing Properties:

IIS Authentication

IIS Authentication

As you can see, you have the option to allow anonymous access, Integrated WIndows Authentication (will only work SOAP callers using Windows), Digest authentication (also only for Windows), Basic authentication (very common when working w/non-Windows systems; simple – only use w/HTTPS since the username/password is sent in the clear), and .NET Passport authentication (also for Windows).  I won’t explain each of these here because I’m sure it’s explained well on MSDN.

Now, for that part that I couldn’t find in the indices of BizTalk books… authorization.  Authorization for incoming SOAP messages into BizTalk is also implemented via IIS.  I was pleased to see it’s pretty simple and thorough, once I actually found it.  The trick is not to look at the properties of the web app, but rather right-click and choose permissions.

Authorization in IIS

Authorization in IIS

IIS Authorization/Permissions

IIS Authorization/Permissions

Now, here’s where permissions (authorization) are set.  Grayed out boxes indicate that the permissions are being inherited by a parent.  In the case of BizTalk, the default setting for web apps is to be deployed under the Default Web Site, listening on port 80.   If you stick with this default, you’ll want to be sure to use the minimal set of permissions at the parent, and be more specific for each web app underneath.  For example, if A and B are children of Default Web Site, you may likely want to have one set of permissions for A and separate permissions for B, meaning that you’ll want to limit the common permissions set by default at the parent.  And, if you didn’t guess already, you can’t use authorization (permissions) unless you authenticate a user using one of the methods described earlier (hence authorization w/anonymous access makes no sense).

Good luck!

Advertisements
Categories: BizTalk Server
  1. No comments yet.
  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: