BizTalk 2006 Business Rules Authorization Manager Tool

  • Article

I was recently inspired to spend some time digging into artifact-level security in the Business Rules Engine, and wanted to release
a first take of my Rules Authentication Manager (RAM) tool.

This post will dig into how it all works. I've included a link at the bottom to the current executable. Once I get a bit further along,
I'll throw the source code into GotDotNet or CodePlex. For
now, I'd love your feedback so that we can make this a tool that administrators have in their management arsenal. I've included a quick
gotchas section below, as well as an upcoming enhancements section.

Here's the screenshot of the tool so far. It's divided into two tabs: one for defining the rule authorization groups, and another
for applying a particular to group a specific business rule policy.

I didn't want to have to figure out where your SQL rule store was, so I used the RuleSetDeploymentDriver class which grabs the
configured rule store. I store off a pointer to the rule store, so that I can later do things like check to see if authorization
has been turned on or off.

//grab the rulestore from the deployment settings

RuleSetDeploymentDriver driver = new RuleSetDeploymentDriver();

activeStore = driver.GetRuleStore() as SqlRuleStore;

//check box indicating if authorization is turned on or off

chbAuth.Checked = activeStore.IsAuthorizationEnabled();

What is the "authorization" I speak of? By default, the BRE ships with no browsing security turned on. You need to be a member of the
Administrators group to do deployments, but anyone could query and view the rules. When you flip authorization on, you force the
Engine to validate the caller and see what permissions they have. We'll see some of that below.

A key thing I use over and over are AuthorizationGroups. An AuthorizationGroup is a BRE-specific role that a administrators can define.
At the launch of the RAM, I pull all the existing roles that have been defined, using the code here ...

AuthorizationGroupCollection authColl = activeStore.GetAllAuthorizationGroups();

//add groups to listbox

if (authColl.Count > 0)

{

foreach (AuthorizationGroup currentGroup in authColl)

{

lbAuthGroups.Items.Add(currentGroup.Name);

}

}

I then let you create new authorization groups. You choose the group name, and its permission level. Your BRE approved choices
are: Full Access, Modify/Delete, Read/Execute, or No Access. We'll see the role of each as we move further along.

After you create a group, you naturally need to add users to that group. Using the BRE API, you can add users of four types:
Windows User, Windows Group, SQL User, SQL Group. At this point, I've only implemented the Windows user and group. Shown below,
you'll see the ability to add Windows users/groups to the BRE authorization group.

For demonstration purposes, I've shown the creation of a Read/Execute group, and Modify/Delete group. Let's switch over to the
Policy Authorization tab. Here I show you all the policy artifacts (each version) in your rule store. When you select one, I show
you the details of the policy and any Authorization Groups currently associated with that artifact.

Of course from here you can create new policy-->group associations. When you click the Add button, I show you all the available
Authorization Groups, and you can choose one to add to the policy.

How about testing this. Easiest way I found was to launch the Business Rules Composer as the user you've added to the Authorization
Group. So, I do a simple "Run as ..." on the Composer, and log in as the TestUser account. Because I haven't checked that box
at the top of the RAM tool ("Authorization is Enabled"), I'm able to see all the policies in the store.

If I go back and check that box in the RAM, and refresh my Composer view, all the policies disappear, except for the one that I've given
Read/Execute rights on. Neato!

If I take that policy version, and try and do anything to it (say, publish it), I get the following error:

So what behavior can you expect in the Composer and at runtime for each AuthorizationGroup type?

  • Read/Execute. Be able to browse the policy, pull it in via API request, and execute it at runtime.
  • Modify/Delete. By default you cannot browse the rule (only if you are also in a Read/Execute group) but you can
    change, publish and delete the ruleset.
  • Full Access.
  • This group lets you browse, change and delete the policy.

Now let's say you've set up a policy to have No Access for a particular user/group. If you try and execute that
rule from an application, the API call results in an exception like this ...

If add permissions for Read/Execute, the rule fires fine. If with those current permissions I try and delete the
rule in my application, I get an error stating access denied. Also, if no groups have been assigned to that policy,
I'd get that above error if I try to call the rule. If I add a group with Modify/Delete permissions, then I can successfully
remove a policy using my sample application. Good stuff.

I was about to start throwing some code here, but this post is already getting long. Needless to say, the (barely documented)
BRE API classes I use gratuitously throughout this application include:

  • RuleSetInfo
  • AuthorizationGroupCollection, AuthorizationGroup, AuthorizationGroupEntry
  • SqlRuleStore (SetRuleSetAuthorizations(), GetRuleSetAuthorizations(), SaveAuthorizationGroups())

If you interested in seeing where these permissions are stored, open up SQL Server, expand your BizTalkRulesEngineDb and check
out the following tables in the picture here. You'll see each authorization group, users, and links between artifacts and groups.

Gotchas

Few things to be aware of. First, the user account you're adding to these groups MUST be in the BizTalk Application Users group. I also
stuck my guys into BizTalk Server Operators. Secondly, deployment permissions cannot be set via the API. Only users in the
RE_ADMIN_USERS SQL role (which includes the BizTalk Server Administrator) has permissions to the stored procs that do deployment.
It makes sense, but it still screwed me up for a bit. You probably want deployment rights sitting with a very select group of folks
who also act as the BizTalk administrators. Finally, note that I built this for BizTalk 2006 and .NET Framework 2.0.

Upcoming Enhancements

Couple things I have to add before having this really be viable. First, gotta add the ability to also add Authorization Groups to
vocabulary items. Should be easy, just haven't gotten to it yet. Also need to handle both SQL users and groups as valid Authorization
Group members. Finally, I want to clean up the navigation and general usability.

I look forward to you folks trying this out, seeing what breaks. You can download the RAM here. Enjoy. Don't say
I never give you anything.

Technorati Tags: BizTalk