Scope MQ Console / REST authorization per queue manager, so one Console can serve several environments

Role assignment for the MQ Console and administrative REST API is application-wide. A user mapped to MQWebAdmin holds administrative rights over every queue manager the mqweb server is connected to via setmqweb remote. There is no way to grant administrator on development queue managers and read-only on production, or to segregate queue managers by application team.

This means development, QA and production cannot sit behind one Console: any user with MQWebAdmin would hold production administrative rights in the same session as development. That fails environment separation at the access-control layer even when the network layer is separated, and it is a significant operator-error risk when queue managers from several environments appear in one selector. Under REST API v3 the exposure is wider still, because a single role confers arbitrary MQSC through POST /admin/action/qmgr/{qmgrName}/mqsc.

The result is one mqweb deployment per environment — more infrastructure, more certificates and OIDC clients, several URLs, and no single pane of glass.

WHAT WE ARE ASKING FOR

Let role evaluation consider the target queue manager. {qmgrName} is already a path parameter on every administrative and messaging resource, including the v3 mqsc endpoint, so no new API surface is needed.

The smallest useful form would be role bindings per setmqweb remote connection, so a directory group maps to MQWebAdmin on one connection and MQWebAdminRO on another. That alone would resolve environment separation. Queue manager groups, or a policy keyed on queue manager and action, would be more general.

Scoping GET /ibmmq/rest/v*/admin/qmgr would also hide out-of-scope queue managers from the Console selector, removing the operator-error risk rather than limiting its consequences.

We are also filing a companion idea for an intermediate role between MQWebAdmin and MQWebAdminRO.