Identity and Access Management for MQ Environments
Should Administrators, Engineers, Developers, helpdesk Agents, and Managers all have the same visibility and access to your enterprise messaging and integration infrastructure? Not according to Gartner and we couldn’t agree more. In fact, Identity and Access Management for MQ Environments is why we created our unique Trusted Spaces™ capability in Infrared360®.
Let’s face it: there are clear-cut situations where someone other than the MQ Administrator needs to get visibility or access to a queue, Qmgr, or even down to a message on a queue.
Visibility Only Situations:
An Application Team Manager says Support reported a problem with a production transaction for the application. The message is not being consumed.
Before they ask you to remove it or move it, they need to look at it, because they’re the application SME who knows what the contents of the transaction is supposed to contain, format, character set, etc. They don’t want this to escalate to a SEV2 situation, so that means they’re asking you to drop everything you’re supposed be doing and put on your Forensic Files hat – right now.
Access Needed Situations:
An Application Developer needs to test the new application to ensure it takes messages off a queue, processes them, and their broker application transforms it properly and puts in onto yet another outbound queue. You’ll need to check the original message goes out, is found coming back into the broker app input queue, then shows up in a new way on the outbound queue from the broker. Btw – once this is done once, you’ll want to automate the sending of those transactions in this flow.
Want some even better examples? Read Viewing, Supporting, and Securing an IBM MQ Environment On Z/OS
Since these situations, and many others like them, not only exist but are common, Identity and Access Management for MQ Environments is crucial. It’s why we created Infrared360® – to help simplify life for MQ Admins. Our Trusted Spaces™ feature lets you keep users seeing and working only in the areas they should and promotes secure collaboration across departments, teams, locations, and partners. This powerful feature set allows or limits visibility to objects such as Queues, Topics, Consumers, Channels, Applications, Flows, and other integration-type server resources according to the “permissions” or “role” of the user.
Users can be assigned VISIBILITY to only to the objects within their Middleware Environments for which they have permission to see. This can be extremely granular down to individual message types on specific queues.