websphere-mq security changes in 7.0 + - Is it possible to secure MQ objects without using security exits

We are using security exits in WebsphereMQ 6.0 to provide security 开发者_运维技巧in java clients connecting to MQ and MQ - MQ connectivity. We use security exits to provide secure way to connect to Queue managers , Queue , channel.

IS there any change in security mechanism in latest version so that we can completely avoid using security exits ?

This is what our requirement/goal in MQ security

• Queuemanagers should be only accessible with providing proper username and password (I know this is not possible in 6.0 without security exits )

• A legal user after authenticating queuemanager connection should be able to access only his queue / channel.

Thanks

Short answer - no.

WMQ v7.0 made some significant changes to security such as adding topics as first-class WMQ objects that you can apply security to. However, authentication of remote connections in WMQ v7.0 uses the same mechanisms as in v6.0 which is SSL, exits or some combination of these. Although WMQ Explorer now has a place to put the user ID and password, the user ID is simply accepted by the QMgr at face value (same as in v6.0 and prior) and the password is ignored unless an exit is used to verify it.

I should also mention that any time an ID and password are sent from a WMQ client to an exit on the server side for validation, there is nothing that protects the credentials in transmission by default. If using an exit pair, it is possible that the client side and server side exits could set up per-session encryption in which to send the credentials. More often though, a server-side-only exit is used in combination with SSL channels with a ciphersuite other than NULL_SHA or NULL_MD5. This provides for per-session protection of the credentials without requiring an exit pair.

Some shops I've worked with used exits that encrypt the credentials using a static key and salt. While this method does prevent an eavesdropper from learning the actual password, the encrypted strings can simply be replayed in a new connections request so that level of security is worse than none at all - it gives the impression of security while not actually enhancing security.

The real trick here is in getting the password validated. If an SSL certificate is sufficient, it is possible to use SSLPEER on the channel to filter by Distinguished Name or else use an exit to map the SSL certificate to a local user ID. This latter method is possible using the free BlockIP2 exit from http://mrmq.dk (an IBMer runs the site but the exit code is community-maintained).