A Brief Tutorial on Secure User Access in BMC MainView Middleware Administrator
A Brief Tutorial on Secure User Access in BMC MainView Middleware Administrator
There have been considerable discussions regarding BMC’s MainView Middleware Administrator Secure User Access to IBM MQ and TIBCO EMS objects and messages. This feature is also known as “Role Based Access” and “Secure Self Service”. The Secure User Access feature allows for different users to perform specific operations against a subset of middleware objects and messages in them based on their role within the business.
Proper configuration of this feature combined with appropriate procedures may reduce the workload on administrators by offloading certain middleware administrative activities (such as changing the properties of objects and verifying messages) in test environments to developers or troubleshooting production issues to application support experts. These practices can also reduce the elapsed time required to get new applications or changes to existing ones into production. In this blog, we’ll take a high-level look at this security feature.
End users access a central Administrator Server through the User Console of the MVMA Web Interface instead of invoking connections to IBM MQ (IMQ) queue managers and/or TIBCO EMS (EMS) Servers. MVMA connects, as a client, to those middleware resource managers and issues commands to them on behalf of the users.
Behind the scenes, the MVMA end user is authenticated and access granted to IBM MQ and TIBCO EMS objects by the MVMA Server upon logging in through the MVMA Web interface. These authentication and authorization (access control) security operations involve the MVMA Project artifact with which the User is associated, either explicitly or indirectly through Groups to which the user belongs. Each Project is associated with at least one MVMA Connection to an IBM MQ queue manager or EMS Server as well as one or more User(s) and/or Group(s). Each Connection may have one or more Filters associated with it which limits the middleware objects that can be viewed through the MVMA User Console. (All objects defined to that middleware resource manager can be viewed if no Filters are associated with the Connection.)
Each User and Group has one or more permission(s) granted to it which determine which operations (create, alter, query, or delete objects; as well as browsing, creating, and deleting of messages) are allowed as part of its association with a Project. Please note that the security checks involved with the MVMA Secure User Access are performed within the MVMA Administrator Server. This implies that the MVMA Secure User Access is completely independent of the EMS and IMQ (i.e. Object Authority Manager or Security Managers accessed through SAF on z/OS) security services.
Each Project, as well as the Connections, Filters, Users and/or Groups associated with it, must be configured by the MVMA Administrator through the Administration Console in the MVMA Web Interface. This role is separate from that of all MVMA users, including IMQ and EMS Administrators, which access MVMA services through the User Console.
Let’s consider a hypothetical example of establishing MVMA Profile for the development and testing of a Payroll application for the ACME Company, which has three pre-production environments (development (Unit Test), test, and Quality Assurance (QA)) as well as a production one. The MVMA Administrator would create the following MVMA artifacts for the three pre-production environments (assuming the IMQ/EMS Administrator will support the production environment):
- One Filter (PayRollQueues) allowing all the IMQ queues that start with characters PAYROLL to be viewed through the User Console. (This assumes a name convention in which the first of characters in an object name identifies the application suite which will be accessing the object.)
- One or more User(s) for each pre-production environment:
- PayRollDev for developers,
- PayRollTest for testers, and
- PayRollQA for QA.
- Optionally, but typically used, one or more Group(s) for each pre-production environment:
- PayRollDevGroup and associate the PayRollDev User with it for developers,
- PayRollTestGroup and associate the PayRollTest User with it for testers, and
- PayRollQAGroup and associate the PayRollQA User with it for QA.
- At least one Connection (WMQ or EMS) to each middleware resource manager (in our case the IMQ queue manager for that environment.)
- ACMEFINDEV for developers.
- AMCEFINTEST for testers.
- AMCEFINQA for QA.
- One Project for each role in each environment allowing the connection to the middleware system with the proper access to the appropriate set of objects:
- PayRollDev with the ACMEFINDEV Connection, PayRollQueues Filter, and PayRollDevGroup Group associated with it.
- PayRollTest with the ACMEFINTEST Connection, PayRollQueues Filter, and PayRollTestGroup Group associated with it.
- PayRollQA with the ACMEFINQA Connection, PayRollQueues Filter, and PayRollQAGroup Group associated with it.
A section of the PayRollDev Project is shown below with the Connection, Filter, and Group associations specified to it.
The permissions for accessing the middleware objects and the messages in them are indicated in the association of the User or Group with the Project. The indicated permissions are additive. In this example, the Users in the PayRollDevGroup are granted “All” permissions which allows them to perform every operation to PAYROLL queues and the messages in them. Testers may be granted permissions to query queue properties as well as browse, create, alter, and delete messages. QA personal may be allowed to only query queue properties and browse messages.
Accesses granted by each of the permissions shown above are as follows:
- All: is a short cut for granting all permissions.
- Inquire: allows users to view all Project objects as determined by the Filter(s). (It does not allow changing object properties or accessing messages.)
- Read: allows users to browse messages.
- Write: allows users to create and modify messages.
- Delete: allows users to delete messages.
- Operator: allows full administrator authority to existing middleware objects with the exceptions of deleting them. It does not permit the creation of new objects.
- Administrator: allows full administrative authority including deleting existing middleware objects as well as creating and importing new ones.
Those are the basics of Secure User Access in BMC MainView Middleware Administrator. Additional questions? Get in touch and we’ll be happy to talk through them.
