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.
Visibility
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.
Access
For the Objects made visible to the users, they can only ACCESS (change/manage) those objects they have permissions to act on. This, too, can be extremely granular down to individual message types on specific queues.
Benefits
- Administrators, Application Managers, and System Managers (like z/OS, IBMi, NSK, etc.) can apply a SECURE, collaborative approach to problem resolution that reduces MTTR.
- Admins and Dev teams can securely collaborate for faster testing and reduced Time to Deployment.
- Compliance and Security Managers can relax.
- Administrators can focus on mission critical tasks.
- Helpdesks don’t get swamped.
Identity and Access Management for MQ Environments can be accomplish easily Infrared360® without introducing new security protocols that you need new skills to understand and manage. Our Trusted Spaces™ approach to enterprise messaging provides secure collaborative capabilities when troubleshooting alerts and incidents before they become costly issues. Avada Software has helped reduce time to resolution and decrease annual hours spent resolving trouble tickets by nearly 90%.
Want to hear about 5 more benefits? Ask one of us.
Related Posts
More Infrared360® Resources
About the Author: Scott Treggiari
