BizTalk Environments User Access Policy/Security Best Practices using BizTalk360

Published on : Oct 7, 2012

Category : BizTalk Server



One of the largest oil company in the world purchased BizTalk360 purely to stream line their BizTalk environments user access policy.  We been working with this company for nearly last 11 months, with various meetings, demos and POC and finally they decided BizTalk360 will solve their current challenges and save them lot of time as well as money. Above all get rid of managing custom tools that’s not core part of their business.

Current Challenges:

  • Support team have more rights than required. Pretty much administrator rights on live environments
  • They have access to SQL environments to run bunch of custom queries
  • They were spending substantial amount of money custom building management tools
  • Support team were able to see all the applications and the data, even the ones they are not interested in.
  • Their support teams are big and it’s difficult to manage their access rights
  • There is no easy way to share knowledge between support team members.

What we have done?

The company is in the process of migrating from BizTalk Server 2006 to 2010 and they are going live by end of this year.  Last week they invited me and their core architects from US, UK and India to their London office to discuss in detail about the strategies they are going to put in place. After couple of hours brain storming and understanding their current challenges we came up with the solution.  Since it’s very generic and nothing revealing the companies internal usage, I thought I’ll share it here, so it will be beneficial to our existing customers and new ones coming on board. biztalk migration biztalk server migration As you can see from the white board session, we simplified the user access policy into 4 high level groups
  • Level 1
  • Level 2
  • Level 3, and
  • Super user
The first 3 levels will be completely managed by BizTalk360 user access policy capabilities. Three NT groups will be created. Ex:
  • g_BTS2010_PROD_LEVEL1
  • g_BTS2010_PROD_LEVEL2
  • g_BTS2010_PROD_LEVEL3
and support team members will be added to appropriate NT groups. Please note the support team members only need a valid Windows AD account, they don’t need to belong to any special groups like BizTalk Operator, BizTalk Administrator, SSO Administrator etc., which was one of the challenges they are facing. The final super user group will have access to BizTalk administration console. Because they do activities like deploying MSI’s, changing configuration, importing binding files etc. We estimated it won’t be more than 5-6 people (compared to 10’s before). This just drastically reduced the number of people having administrator rights and increasing the security.

Access rights for g_BTS2010_PROD_LEVEL1

The users in this group will have very limited access rights.
  • Read only access to environment
  • Access to Advanced event viewer
  • Access to Query instances
  • Access to Tracking Data/Message flow
  • Access to Message Content/Context (this one was debated, but they need to see the content to check for malformed messages sometimes)
  • Can execute Custom SQL Query
biztalk user access policy

Access rights for g_BTS2010_PROD_LEVEL2

The users in the group will have all the rights of LEVEL1 users and in addition they will have following rights
  • Resume and Terminate service instances,
  • Start/Stop application artifacts (receive locations, send ports and Orchestrations)
  • Can edit the knowledge base articles
  • Access to Platform settings, so they can view things like Host, Host Instances, Message Boxes etc..
user access for production application

Access rights for g_BTS2010_PROD_LEVEL3

The final level users are simply super users in BizTalk360. This allows them do all kind of day-to-day operational tasks. But the users will be restricted from doing deployment and infrastructure changes like  MSI import/export, binding files import/export, creating host, message boxes, configuring adapters etc.. adding new super user

Super Users

The final group super users group will have full access via the BizTalk Administrator Console. The supers users will be part of BizTalk Administrators Group, SSO administrators group, and they will have additional rights like Local administrators in BizTalk Servers, access to SQL server instances etc. In the past most of the normal users had this level of permission in the production environment(s) and now it’s restricted to just 5-6 people in the whole company.

Future Improvements

To stick with our principle of not having a road map and build the product purely on customer feedback and address their pain points, the outcome of the meeting was bunch of neat features we need to start working on in vNext. Here are the list

Pre-Defined roles:

It’s clear the above set of guiding principle will apply to large number of customers. So BizTalk360 can come with the pre-defined roles and customers simply map their NT groups to existing roles.

Can Create KB article:

At the moment, only super users can create KB article and you can assign “Can Edit” permission to the user, but in the future it will  be useful to have “Can Create” permission.

Separate Start/Stop, Resume/Terminate operations:

At the moment, those permissions are tied together. Example If you assign “Can operate on Application” permission, then the user will have the ability to do both start and stop operations. But in bigger companies they want users to have the ability to only start (if they see the artifact  in stopped state), but not stop it.

Granularity on SQL Query execution

At the moment when you assign can execute “Custom SQL Query” permission, the users are able to execute all the stored queries. In the future it will be nice to assign only certain queries to each group.