Top 5 authorization security considerations in Business Process Management
MartinKeen 1200007VU3 Comments (2) Visits (8124)
All users are not created equally. Authorization is the process of ensuring that a user (or other computer system) has permission to perform a given act. IBM Business Process Manager defines a very fine-grained authorization model. Getting this model right – ensuring that only the right people have access to certain resources – is key to securing your Business Process Management environment. Using excerpts from J Keith Wood and Jens Engelke's new IBM Redbooks publication IBM Business Process Manager Security: Concepts and Guidance, here's the top 5 authorization security concerns we are seeing in Business Process Management today.
1. Overuse of administrator privileges
In the Process Center for IBM Business Process Manager, you can grant Admin access simply by selecting users with a check box. There are a lot of implicit permissions granted when you enable this check box. Enable this option only for a few trusted users. Enabling this option grants the user or group the permission to read, edit, create snapshots, and deploy snapshots of any process application. These users can also grant /ProcessCenter Admin rights to any IBM Business Process Manager user and to any process application. Let's be clear - the enabled check box next to a user's name grants them super-user status. Enable this option sparingly.
2. Failure to map participant groups
When a new swimlane is introduced to a IBM Business Process Manager process definition, the default participant group defaults to All Users. It is too easy to just leave the default of All Users in place, or to use already-existing LDAP groups and call it a job well-done. This is an important point: if All Users is allowed to stay, then you are effectively, completely turning off authorization for all tasks in this swimlane. Use a rigorous review process to ensure that each and every swimlane or participant group is mapped to an IBM Business Process Manager private group that includes only those users who should have authority to execute the steps within the swimlane.
3. Overpopulation of groups
Be careful of defining private groups that will be close-but-not-quite exactly what the process definition requires. Use fine-grained groups for each functional role that your process application can conceive.
4. Overuse of tw_authors, tw_admins
The process of ensuring that an author or developer has adequate authorization to create and deploy applications is rather a daunting task. As a result, we see many organizations simply adding their authors and developers into the default groups of tw_authors or tw_admins. Membership in these all-encompassing groups grants these accounts super user status -- and visibility to all process applications that are installed in your environment. This approach is almost universally undesirable. Access to /ProcessCenter and Process Designer should be granted in small, highly related chunks. Create project team groups that closely reflect the roles that these authors or developers play in the processes being modeled.
5. Faith in firewalls
Do not underestimate the amount of information that can be gathered by a curious, motivated, or perhaps mischievous user. If a user can sniff the network traffic, then they can analyze it. If they can analyze it, they can spoof it. It is a short path from unencrypted network traffic to unauthorized access. Specifically, given IBM Business Process Manager’s ability to perform instance-based authorization based upon run-time criteria, it is certainly conceivable that someone might be able to sniff an in-flight process and alter its authorization criteria. Encrypt all communication links between IBM Business Process Manager and LDAP servers, databases, web or proxy servers, and any web services hosts. Also encrypt communication between Process Center and Process Server, Process Designer, and Integration Designer. Finally, encrypt communication between Process Servers and users. It's simply not enough to rely on these communications occurring behind your firewall.
For much more, consult the IBM Redbooks publication called IBM Business Process Manager Security: Concepts and Guidance.
Martin Keen is an IBM Redbooks Project Leader. He leads publications on many areas of IBM software, including WebSphere, Messaging, and Business Process Management. Follow Martin on Twitter at @MartinRTP.