REST API Security

IBM MQ REST APIs—administration and messaging—arrive over HTTP through mqweb. That convenience expands attack surface: credential theft, excessive authority, weak TLS, and accidental exposure of queue managers to untrusted networks. Security architecture must cover transport encryption, authentication, authorization, logging, and network placement together—not only enabling HTTPS. Beginners enable mqweb on port 9443 and share an admin password with every microservice. This tutorial explains how REST security layers map to familiar MQ concepts, hardening mqweb, identity patterns for DevOps, mutual TLS options, integration with enterprise OAuth, auditing REST calls, and common failure modes that look like application bugs but are auth misconfiguration.

Defense in Depth for REST

Layer 1: network—firewall mqweb to trusted CIDRs or internal service mesh. Layer 2: TLS—disable weak ciphers, use corporate CA, monitor cert expiry. Layer 3: authentication—prove caller identity via basic, OAuth, or client cert. Layer 4: authorization—OAM grants per queue and object. Layer 5: audit—ship mqweb and MQ logs to SIEM. Missing any layer leaves gaps—TLS without OAM still allows admin password holders to delete queues.

TLS for mqweb

mqweb runs on Liberty; keystores configure server certificate and trust for clients. Clients must trust the server CA. Mutual TLS requires client certs in mqweb trust configuration and mapping to MQ principals—similar discipline to channel SSLPEER rules. Renew mqweb certificates on the same calendar as channel certs or automate via PKI. Test after renewal with curl -v before applications deploy.

Authorization After Login

Authenticated REST caller becomes an MQ user ID for OAM checks. A token or basic auth name must map to a principal with explicit +put on PAY.IN only—not mqm admin. Use setmqaut or security console; verify with dspmqaut. Admin REST endpoints need tighter groups than messaging endpoints—split service accounts: pay-producer-rest vs mq-operator-admin.

1
2
3
setmqaut -m QM1 -n PAY.IN -t queue -p pay-rest-svc -a +put
setmqaut -m QM1 -n PAY.OUT -t queue -p pay-rest-svc -a +get
dspmqaut -m QM1 -n PAY.IN -t queue -p pay-rest-svc

CONNAUTH and REST

Queue manager CONNAUTH may still apply to connections mqweb makes internally. LDAP password changes affect REST basic auth users. Lockout policies on directory services can stop microservices in bulk. Document dependency between REST clients and AUTHINFO objects.

Operational Controls

• Separate mqweb instances for admin vs messaging if topology allows.
• Rate limiting at API gateway against abusive PUT loops.
• No production credentials in source code—use vaults.
• Alert on 401/403 spikes on mqweb access logs.
• Penetration test REST paths after major mqweb upgrades.

Common Mistakes

1. Shared admin password in Kubernetes secrets for all pods.
2. self-signed TLS without corporate trust—clients disable verify.
3. Granting +all for speed during project start, never revoked.
4. Exposing port 9443 on 0.0.0.0 in cloud security groups.
5. Ignoring JSON message content in compliance scope.

Explainer: Lobby Security for the Web Entrance

Channels use the loading dock with truck papers (CHLAUTH). REST uses the public lobby web kiosk. You still need badges (auth) and room keys (OAM)—a fancy kiosk does not remove the inner doors.

Explain Like I'm Five: REST API Security

The website that talks to the mail machine needs a lock on the door (TLS) and a secret name tag (password or certificate) so strangers cannot send fake letters.

Practice Exercises

Exercise 1

Document mqweb TLS cert expiry date and owner team.

Exercise 2

Create least-privilege principal for one REST put-only use case; show dspmqaut output.

Exercise 3

List network controls between internet and mqweb in your architecture (or gaps).

Frequently Asked Questions

Test Your Knowledge