- 0 minutes to read

Granting User Access to IBM MQ Monitoring

Understanding Access Control for IBM MQ Monitoring

Nodinite provides a multi-layered security model for controlling who can monitor, manage, and resolve IBM MQ issues. Rather than granting blanket MQ admin rights (dangerous and difficult to audit), you grant fine-grained access via roles, Monitor Views, and alerts.

On this page, you will learn:

  • How Nodinite access control layers protect your IBM MQ environments
  • How to create Monitor Views that filter what users see
  • How to assign Roles that grant specific permissions (view-only, purge, edit thresholds, etc.)
  • Step-by-step examples for common access scenarios
  • How to propagate alerts to users via Alarm Plugins

Access Control Architecture

Nodinite enforces access control at three levels:

Level 1: User Authentication

Every user must log in with valid Nodinite credentials (Windows AD, LDAP, or local). This establishes who is accessing the system.

Recommendation: Integrate with your corporate Active Directory so user accounts are automatically managed; terminating access is as simple as disabling the AD account.

Level 2: Role-Based Permissions

Roles define what actions a user is allowed to perform:

Role Permissions Typical User
Administrator Full access to all features, configuration, user management, audit logs MQ infrastructure team
Monitoring Agent Manager Configure agent settings, enable/disable resources, manage monitoring policies Operations manager
Remote Actions User Execute remote actions (purge, browse, edit thresholds) Operations team, application support
Monitor User View monitoring data, search history, receive alerts (no modifications) Business operations, managers
Custom Role (user-defined) Fine-grained permissions per organization (e.g., "Purge Test Queues Only") Domain-specific access

A user can be assigned multiple roles. Permissions are cumulative (if user has Role A with "view" and Role B with "purge", user can both view and purge).

Recommendation: Create custom Roles matching your organization's teams:

  • Application Support Team – View-only access to application queues
  • Database Team – Manage database-related queues and channels
  • Operations Night Shift – Full purge/browse/edit permissions during night hours
  • Business Analyst – Summary alerts, dashboards, no tactical access

Level 3: Monitor View Filters

Monitor Views are scoped dashboards that control which resources (queues, channels, listeners, etc.) a user can see and manage. Even if a user has "purge" permission (Role level), they can only purge queues in Monitor Views they're assigned to.

Example:

Operations Team Role has "purge" permission
↓
BUT
↓
Operations Team assigned to Monitor View "Production-ORDERS" only
↓
RESULT: Operations can purge ORDERS.* queues but cannot see (and thus cannot purge) INVOICES.* queues

This scope limiting ensures:

  • Operators cannot accidentally affect queues outside their domain
  • Business units see only their applications
  • Compliance teams see only regulated resources
  • Help desk is limited to specific queues they're authorized to manage

Implementing Role-Based Access: Step-by-Step

Prerequisites

Before delegating access, ensure:

  1. IBM MQ Monitoring Agent installed – Agent must be running and monitoring your queue managers
  2. Administrator access – You must have Administrator or equivalent role to configure access
  3. Users created in Nodinite – Each team member must have a Nodinite user account
  4. Queue managers configured – Agent is connected to and monitoring your queue managers

Step 1: Define User Roles

First, create or customize Roles matching your organizational structure.

How to create a custom role:

  1. Log in as Administrator
  2. Navigate to Administration → Access Management → Roles
  3. Click "Create Role"
  4. Name the role (e.g., "Operations - Queue Management")
  5. Select permissions:
    • View Monitoring – ✅ (always enable for active users)
    • Execute Remote Actions – ✅ (allow purge, browse, edit thresholds)
    • Download Reports – ✅ (allow metric exports)
    • Modify Monitor Views – ❌ (not needed for operators)
    • Manage Agents – ❌ (only for infrastructure team)
    • System Administration – ❌ (only for admins)
  6. Save the role

Role template examples:

  • Read-Only Operator – View, Download Reports only. Use for: managers, business analysts who need situational awareness but not tactical control.
  • Queue Manager – View, Remote Actions, Download Reports. Use for: operations team managing queues.
  • Channel Specialist – View, Remote Actions (channels/listeners only). Use for: team managing inter-queue-manager connectivity.
  • Full Administrator – All permissions. Use for: MQ infrastructure team.

Step 2: Create Monitor Views for Resource Filtering

Monitor Views control which resources a user can see and act upon. You'll create one Monitor View per team or application domain.

How to create a Monitor View:

  1. Log in as Administrator

  2. Navigate to Administration → Monitor Management → Monitor Views

  3. Click "Create Monitor View"

  4. Basic properties:

    • Name: (e.g., "ORDERS Application - Operations")
    • Description: "Monitoring and management for ORDERS application queues and channels"
    • Agent: Select "IBM MQ Monitoring Agent"

  5. Add resources to monitor – Use filters to select which queues, channels, listeners to include:

    • Filter by queue name pattern: ORDERS.* (includes ORDERS.IN, ORDERS.OUT, ORDERS.DLQ, etc.)
    • Filter by channel name: ORDERS.*
    • Filter by queue manager: (select specific queue managers)
    • Set expected states (mark test queues as "Expected to be OK" even if full, to suppress alerts)

  6. Assign users/roles:

    • Click "Add Permissions"
    • Select roles (e.g., "Operations - Queue Management")
    • Select users in that role who can see this Monitor View
    • Choose permission level:
      • View Only – Users can see resources and historical data but cannot execute actions
      • View + Actions – Users can view and execute remote actions (purge, browse, etc.)

  7. Configure alert propagation (optional):

    • Enable "Propagate alerts to external systems"
    • Select Alarm Plugins (email, Teams, Slack) to notify users when resources in this view transition to Error state

  8. Save the Monitor View

Example Monitor Views:

Monitor View Name Audience Filtered Resources Permissions
ORDERS-Ops Operations Team ORDERS.*, ORDERS queue manager channels View + Purge/Browse/Edit Thresholds
INVOICES-Accounting Accounting Team INVOICES.*, invoice-related channels View Only
All-Production-MQ MQ Admins All production resources View + Full Remote Actions
Night-Shift-Ops Night Operations Critical-only queues, channels, listeners View + Emergency Actions (purge, restart)

Step 3: Assign Users to Monitor Views and Roles

Now link users to roles and Monitor Views.

How to assign a user to a role:

  1. Navigate to Administration → Access Management → Users
  2. Select the user
  3. Click "Assign Roles"
  4. Check roles this user should have (e.g., "Operations - Queue Management")
  5. Save

How to assign a user to a Monitor View:

  1. Navigate to the Monitor View you created
  2. Click "Manage Permissions"
  3. Add the user or role
  4. Set permission level (View Only or View + Actions)
  5. Save

Verification: Log in as the user (or use "Test as User" feature) and confirm:

  • User sees ONLY the Monitor Views assigned to them
  • User sees ONLY the resources filtered into those Monitor Views
  • Action buttons (Purge, Browse, Edit Thresholds) are visible only if user's role has "Remote Actions" permission

Step-by-Step Examples

Example 1: Delegating Queue Management to Operations Team

Scenario: Your operations team manages ORDERS and PAYMENTS queues in production. They should be able to monitor, purge, and browse messages without accessing MQ Explorer or granting them mqm group membership.

Steps:

  1. Create role "Operations - Queue Management"

    • Permissions: View Monitoring ✅, Remote Actions ✅
    • No system admin access

  2. Create Monitor View "ORDERS+PAYMENTS-Production"

    • Filter: Queue names matching ORDERS.* OR PAYMENTS.*
    • Queue managers: Production-QM1, Production-QM2 only
    • Users: Operations Team members

  3. Assign role to operations team:

    • Add "Operations - Queue Management" role to 5 users (ops team members)

  4. Assign Monitor View to operations team:

    • Set permissions to "View + Remote Actions"
    • Grant purge, browse, edit thresholds permissions

  5. Test:

    • Log in as an ops team member
    • Verify you see ONLY ORDERS and PAYMENTS queues (no INVOICES, REPORTS, etc.)
    • Click Purge on a queue; confirm you can execute the action
    • Check Audit Log shows your action

Result: Operations team can independently manage queue backlog without:

  • Granting MQ Explorer access
  • Requiring MQ admin intervention
  • Exposing queue manager configuration details
  • Allowing accidental access to unrelated queues

Example 2: Read-Only Access for Business Users

Scenario: Your finance manager needs visibility into invoice processing. Wants to know when queues are backing up, but should never execute actions (no modify permissions).

Steps:

  1. Create role "Finance - View Only"

    • Permissions: View Monitoring ✅, Download Reports ✅
    • Remote Actions ❌

  2. Create Monitor View "Finance-Dashboards"

    • Filter: Queues matching INVOICES.*, PAYMENTS.*, REPORTS.*
    • Exclude test queues (queue manager filtering)
    • Custom dashboard showing queue depth trends, error count, age metrics

  3. Assign role + Monitor View:

    • Add finance manager to "Finance - View Only" role
    • Add finance manager to "Finance-Dashboards" Monitor View with "View Only" permission

  4. Configure alerts:

    • Add Alarm Plugins (Teams, email) to propagate INVOICES queue errors to finance manager
    • Manager receives Teams message: "INVOICES.OUT queue depth 850 (Error: >800)"

  5. Test:

    • Finance manager logs in; sees charts and metrics only
    • No Purge, Browse, or Edit buttons visible
    • Receives alerts when invoice queues have issues

Result: Finance manager has strategic visibility without tactical control; can escalate to operations team if action needed.

Example 3: Segregating Dev/Test/Production Access

Scenario: Your organization has dev, test, and production environments. Different teams maintain each. Prevent test team from accidentally accessing production queues.

Steps:

  1. Create three roles:

    • "Dev Developers" – Full remote actions on dev resources
    • "QA Test Team" – Full remote actions on test resources
    • "Production Ops" – Full remote actions on production resources (most restricted)

  2. Create three Monitor Views:

    • "Dev-All" – Filters for dev queue managers only; assigned to "Dev Developers" role
    • "Test-All" – Filters for test queue managers only; assigned to "QA Test Team" role
    • "Production-All" – Filters for production queue managers only; assigned to "Production Ops" role

  3. Enforce separation:

    • Dev developer never sees production queue managers (different Monitor View)
    • If dev developer tries to switch to another Monitor View, gets "Access Denied"
    • Accidental or malicious access to production is prevented at UI level (and enforced server-side)

  4. Audit trail:

    • Audit Log shows every action per environment; easy to track who did what and where

Result: Environment separation enforced; teams cannot cross boundaries even if they try.

Alert Propagation to Users

Once Monitor Views are configured, configure Alarm Plugins to notify users when resources transition to Error state.

Supported notification channels:

  • Email – Alert emailed to user distribution lists
  • Microsoft Teams – Alerts posted to Teams channels
  • Slack – Alerts posted to Slack channels
  • PagerDuty – Critical alerts trigger on-call incidents
  • Custom Webhooks – Integrate with ticketing systems (Jira, ServiceNow), APM tools, etc.

How to configure email alerts for a Monitor View:

  1. Navigate to the Monitor View
  2. Click "Manage Alerts"
  3. Enable "Propagate state changes to external systems"
  4. Select alarm plugin: "Email"
  5. Recipient list: operations@company.com, john.ops@company.com
  6. Trigger conditions:
    • Alert on Error state (queue depth exceeded, message aged)
    • Alert on Unavailable state (queue manager or network issue)
    • Alert on Warning state (optional; can be noisy)
  7. Save

Alert example email:

Subject: IBM MQ Alert - ORDERS.IN Queue Error

Queue Manager: Production-QM1
Queue: ORDERS.IN
Alert: Queue Depth Error
Current Depth: 950 messages
Error Threshold: 900 messages
Severity: Error (Critical)

Historical Data:
- Peak depth last 24h: 950 (this alert)
- Average depth last 24h: 250
- Oldest message age: 35 minutes (threshold: 30 minutes)

Recommended Actions:
1. Check consumer application logs for processing errors
2. Verify ORDERS.IN is not Get inhibited
3. Consider purging if issue is resolved and message backlog is stale
4. Review with application owner on why processing slowed

View in Nodinite: [https://nodinite.company.com/monitor/...]

- :Nodinite: Monitoring System

Access Control Patterns

Pattern 1: Tiered Escalation

Use when: Issues escalate from level 1 (frontline) to level 2 (senior) to level 3 (specialists)

Implementation:

  • Level 1 - Frontline Support

    • Monitor View: High-level metrics, queue depths only
    • Permissions: View Only (no actions)
    • Action: Escalate to Level 2 when queue depth Error occurs

  • Level 2 - Operations Team

    • Monitor View: Full queue details, message browsing
    • Permissions: View + Purge, Browse, Edit basic thresholds
    • Action: Purge if consumer is restarted; escalate complex issues to Level 3

  • Level 3 - MQ Specialist

    • Monitor View: All resources including channels, listeners, queue manager config
    • Permissions: View + Full remote actions, configuration changes
    • Action: Investigate root cause, modify queue manager settings if needed

Benefit: Each level has exactly the access needed; escalation is fast and tracked.

Pattern 2: Application Team Self-Service

Use when: Application teams own their integration queues; ops provides platform

Implementation:

  • Application Team Developers

    • Monitor View: Application-specific queues and channels only
    • Permissions: View + Browse, Download messages
    • Cannot: Purge, modify thresholds (prevents accidental data loss)
    • Action: Investigate message issues, request ops to purge if needed

  • Application Team Lead

    • Monitor View: Same as developers
    • Permissions: View + Full remote actions
    • Cannot: Modify global agent settings or other applications' queues
    • Action: Escalate to ops only if issue persists across restarts

  • Operations Platform Team

    • Monitor View: All applications
    • Permissions: Full
    • Action: Support escalations, tune global monitoring settings, manage queue managers

Benefit: Teams manage their own resources; ops focuses on infrastructure health.

Pattern 3: Business-Driven Monitoring

Use when: Business stakeholders need to understand integration health

Implementation:

  • Business Stakeholders (Non-Technical)

    • Monitor View: High-level dashboards, order/payment/invoice counts
    • Permissions: View Only, Download Reports
    • Alerts: Daily summary (not real-time; less noisy)
    • Action: Review trends; escalate if pattern suggests systemic issue

  • Business Analyst (Technical)

    • Monitor View: Same queues as stakeholders
    • Permissions: View + Download + Message browse (for investigation)
    • Cannot: Purge (prevents data loss of business records)
    • Action: Analyze patterns, recommend threshold adjustments

  • Operations Team

    • Full monitoring and management access to same queues
    • Action: Execute remediations recommended by analysts

Benefit: Business understands integration health; operations responds to identified issues.

Troubleshooting Access Issues

Q: User cannot see any Monitor Views
A: Check: (1) User has a role assigned? (2) Role has "View Monitoring" permission? (3) Monitor View has user/role added to permissions? Verify all three layers.

Q: User can see Monitor View but no resources appear
A: Check: (1) Is the IBM MQ Monitoring Agent configured and running? (2) Are monitored resources (queues, channels) being discovered (may take 1-2 polling cycles)? (3) Are resources matching the Monitor View's filters (check filter expressions)?

Q: User has "purge" role but Purge button is greyed out
A: Check: (1) Monitor View permission set to "View + Actions" (not "View Only")? (2) Queue state is "OK" (some actions disabled for Error/Unavailable queues)? (3) User's role has "Remote Actions" permission?

Q: Alerts not being sent despite configuring Alarm Plugin
A: Check: (1) Alert plugin configured and tested (Test button in Alarm Plugin setup)? (2) Monitor View has alert propagation enabled? (3) Resource in Monitor View is transitioning to Error state (alerts don't fire for OK state)? Check audit log to confirm actions are being recorded.

Security Best Practices

1. Principle of Least Privilege

Grant only the minimum permissions needed. Don't assign "Administrator" role when "Monitor User" or "Remote Actions User" is sufficient.

2. Separation of Duties

Prevent single person from controlling multiple critical resources. Example:

  • Developer A manages application deployment but cannot execute purge on production queues
  • Operations A can execute purge but cannot deploy new agent configurations
  • Manager B approves both but does not execute either

3. Regular Access Reviews

Quarterly, review user roles and Monitor View assignments. Remove access when team members change roles or leave organization. Track in Audit Log.

4. Monitor the Monitors

Set up alerts on Audit Log events. Alert when:

  • Non-authorized user attempts action (failed permission check)
  • Unexpected user executes unusual action (mass purge, configuration change)
  • After-hours access to sensitive resources

5. Sensitive Data Protection

If queues contain PII, payment data, or secrets:

  • Restrict "Browse Messages" and "Download" permissions carefully
  • Consider data masking in Nodinite UI (if available)
  • Ensure audit logs are retained for compliance (SoC2, HIPAA, etc.)

Next Step

Monitoring IBM MQ – Start monitoring queues and channels with configured thresholds

Configuration Guide – Set up monitoring thresholds and agent settings
Managing IBM MQ – Learn remote actions available to teams
Roles – Understand role-based access control system
Monitor Views – Create and manage monitoring dashboards
Alarm Plugins – Configure alert notifications (email, Teams, Slack)
Audit Log – Review user actions and changes for compliance
Prerequisites – Verify prerequisites before setting up access