This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here. Download a PDF version of this article. Why do we need this feature? Being a middleware product, BizTalk Server is often going to sit right in … Continue reading Why did we build User Access Policy to Manage BizTalk Server Security?
This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here
Why do we need this feature?
Being a middleware product, BizTalk Server is often going to sit right in the center of the organisation. All your critical backend systems like SAP, CRM, Oracle, SQL, and so on are connected to each other via BizTalk Server. So in theory, if someone has full access to your middleware platform like BizTalk Server, technically they can also get access to any of the underlying systems.
When it comes to security or performance, it is determined by the weakest point in the link chain. You might have created a highly protective security wall for each one of those critical backend systems, but when there is a punch whole for an external system (BizTalk Server) to get through, it’s important to protect the security of that external system to the same strength as your backend system.
We felt the current Administrative Security capabilities of BizTalk Server is very limited (will see in detail) and hence the birth of Advanced User Access Policy & BizTalk Server Security feature in BizTalk360.
What is the current limitation in BizTalk Server?
When it comes to day-to-day BizTalk Server Administration and Security, currently the scenario is like this. The Administrator will access the BizTalk Environment using the BizTalk Admin Console, depending on whether he/she belongs to either “BizTalk Server Administrators” or “BizTalk Server Operators” Window NT Group. Certain features will be enabled or disabled in BizTalk Admin Console based on these user roles.
There are few challenges in this approach. If you are a member of the BizTalk Server Administrators group, you have all the access required wide open. However, if you are a member of the BizTalk Server Operators group, your options are limited and the rules are hard coded by Microsoft in terms of what you can and cannot do.
The table below shows the actions that can and cannot be performed by members of BizTalk Operators Group
|View service state and message flow
||Modify the configuration for BizTalk Server.
|Start or stop applications (Send Ports, Send Port Groups, Orchestrations, Receive Locations)
||View message context properties classified as Personally Identifiable Information (PII) or message bodies.
|Terminate/Resume Service Instances
||Modify the course of message routing, such as removing or adding new subscriptions to the running system, including the ability to publish messages into the BizTalk Server runtime.
In pretty much every case, those rules are not practical for the day-to-day administrative work and pretty much within days every single person supporting/administering the BizTalk Server environment will be working with Administrative privileges.
Common challenges in BizTalk Server security
Let’s highlight some of the common day-to-day challenges that are not addressed by the out of the box BizTalk Server security mechanism.
Application Level Security:
Your BizTalk Server environment will be a shared environment in many organisations. For various practical and cost reasons, you are not going to have many BizTalk Server environments. However, many business units in the organisation will be deploying their integration solutions into the platform. In such scenarios, for example Team A might need access to Applications A,B,C and Team B might need access to Applications X, Y, Z. You cannot set this level of Application isolation security using the standard BizTalk Server security mechanism.
Read Only Access:
In some cases, you might want to give read-only access to your BizTalk Server environments. Example: It’s very common to allow few developers who worked on the project to have access to production environments. You wanted to make sure developers do not modify or deploy anything without change control. This is not possible with the standard BizTalk Server security mechanism.
Mixed Privilege Scenario:
For practical reasons, there will be scenarios where you wanted the support person to have some level of mixed privilege. Example: They might need to start and stop the BizTalk Host Instances periodically, they may need to turn on/off tracking settings, or you may NOT want them to terminate or resume service instances etc. If you want to achieve this, there is no other option than making that person (or team) part of BizTalk Server Administrators group. This basically results in no security. As you can see, hard coded rules are not practical and it results in elevated privilege. Sadly this is the scenario with most organisations.
Security for different tools:
The default security mechanism only covers the BizTalk Admin console and WMI access. However, when you are working with BizTalk Server, there are at least 5-8 other tools you’ll be using such as BAM Portal, ESB Portal, Event Viewers, Azure Services etc. Currently they all need their own security mechanisms, making it super complex and often vulnerable.
Multiple BizTalk Environments:
Typically, organisations will have 2-3 BizTalk Server environments. Example: Production, DR, QA (System Integration, User Acceptance) etc. You can simply multiply the above mentioned problems by number of BizTalk Server environments you have.
How does BizTalk360 solves these problems?
From the above points discussed, it is pretty clear and obvious that a better security mechanism is required when it comes to day-to-day BizTalk Server Administration and Operations. Let’s take a quick look at how BizTalk360
addresses the challenges in a seamless way.
The below screenshot shows how you can add BizTalk Administrator/Operator to your BizTalk environment. There are few things to note — in the first place, BizTalk360 supports multiple BizTalk Server environment management from a single console; so you can set up security and access rights from a single place. You can either configure security for individuals or as team (ex: Create an NT Group called “BizTalk Production Support”)
In the second screenshot below, you can see that you do not need to give access for the administrator to complete BizTalk Server environment. You can carefully choose required BizTalk Applications for which a BizTalk Server administrator requires access. The entire BizTalk360 application is context aware, for example, if you have given permission for Application A,B,C and they depend on specific Host and Host Instance, only those related host/host instances will be visible for the user.
In the final screenshot, you can see how BizTalk360 provides full flexibility in terms of what level of permission you wanted to assign for the user. There are no hard coded rules; this makes it practical to give the correct level of permission to BizTalk Administrators/support people. BizTalk360 also comes with pre-defined security templates which you can apply as shown below. The “Can Action” section basically allows users to take some actions in the BizTalk Server environment, for example, if you do not want the user to terminate/resume service instances you can simply uncheck the check box “Service Instances”.
What is the Business Benefit?
Every business likes to run their systems in a secure way. You do not want your critical business systems like BizTalk Server to run with security challenges. This particular feature in BizTalk360 was one of the first key feature built in the product after the original web based BizTalk Admin Console functionality is completed.
Get started with a Free Trial today!
If you are not using BizTalk360, it is pretty clear that you are compromising on certain Administrative security aspects in your BizTalk Environment. So, why don’t you download and try BizTalk360 on your own environment. We provide 30 days free trial
of the fully functional product.