Browse Prior Art Database

Ideas to fix MQ Cluster queue security limitations

IP.com Disclosure Number: IPCOM000243564D
Publication Date: 2015-Oct-01
Document File: 3 page(s) / 110K

Publishing Venue

The IP.com Prior Art Database

Abstract

In messaging product's Cluster feature, cluster queue is a common object accessible by all the cluster queue manager members to perform 'PUT' operation. Irrespective of how big the cluster is, all the cluster queues are visible and accessible to all the cluster queue manager members. We need to apply one or more layer of security between the queue managers to protect the cluster queues to limited cluster queue manager members. Security can be implemented and maintained in channel level using SSL or channel exit or by setting OAM for remote queue managers and objects. To restrict the visibility of cluster queues to particular group of cluster queue manager is not possible in MQ cluster without implementing above mentioned security methods. However those methods will not give the security control to the cluster queues whose security is in question.

Below options are available currently in messaging products, to limit the accessibility of MQ cluster queues among cluster queue managers.

1. Secure Socket Layer (SSL): We shall implement SSL in cluster channels which helps cluster queue managers to authenticate each other. SSL usage in MQ cluster channels have below limitations,

a. It helps for authentication in queue manager level and so visibility of cluster queues in a cluster queue manager will be fully allowed or denied. Implementing limited visibility of few cluster queues and full visibility of few other cluster queues resides in the same cluster queue manager is not possible in this SSL setup.

b. SSL way of securing the cluster queues will demand SSL implementation in all cluster channel connections to the queue manager which hosts the cluster queues.

2. Security Exit: Same as SSL setup, Security exit usage in cluster channels helps cluster queue managers to authenticate each other. Limitation of implementing security exit in cluster channels is the authentication is done in queue manager level and so controlling the visibility of particular cluster queues in a cluster queue manager is not possible. Also this security exit implementation needs to be done in all cluster channels connecting to the cluster queue manager which hosts the cluster queues.

3. Channel MCAUSER attribute: Usage of limited access user id in MCAUSER in cluster channel level is used for authentication in queue manager level among cluster queue managers. This setup of security will not help for access control of particular cluster queues in a cluster queue manager. Securing cluster queues using cluster channel MCAUSER attribute means, to implement this setup in all channels connecting to the queue manager which hosts the cluster queues.

4. OAM authorization: Object Authority Manager (OAM) feature of MQ helps to control access to remote queue managers and remote queues in a cluster which in-turn helps to protect the cluster queue access. However, here the access control is done by other queue managers in the cluster, not the queue manager which hosts the cluster queues.

In the above listed features of MQ, cluster queue security is controlled in channel level or by the other queue managers in the cluster. There is no solution in place to limit the cluster queue access in that queue itself.

This article involves creating logical queue manager groups (sub-cluster groups) in cluster to create sub-cluster group specific cluster queues. So the cluster queues created for a particular sub-cluster group or groups will be not be visible to other queue managers in the cluster.

This solution has below two new advantages over other existing solution for cluster queue security, 1. To restrict the visibility of cluster queues to particular group of queue managers in a cluster. 2. The security control of a cluster queue visibility, to the selected group of cluster queues, will be that cluster queue itself.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

Ideas to fix MQ Cluster queue security limitations

This new idea is to create sub-groups of queue managers within the MQ cluster. Cluster queues can use these logical groups to control their visibility to selected and limited cluster queue managers.

This theory will need two new attributes to be introduced in queue manager level and queue level. Queue manager level attributes - CLUSQGRP, CLQGRPNL
Cluster queue level attributes - CLUSQGRP, CLQGRPNL

CLUSQGRP - Both Queue manager and queues should be added with this attribute. Value entered in CLUSQGRP queue manager attribute denotes which cluster sub-group that queue manager belongs to. This attribute is valid only if the queue manager is member of a cluster and a partial repository. Full repository queue managers will have visibility of all cluster queues in that cluster or in other words, they will be automatically become members of all cluster sub-groups. Value entered CLUSQGRP (cluster) queue attribute indicates to which logical cluster group that cluster queue will be visible. Queue managers member of different sub-groups can not access the cluster queues belong to other sub-groups in the cluster.

CLQGRPNL - If a cluster queue manager to be a member of more than one cluster sub-groups, corresponding cluster sub-group details to be added in a Namelist object and the namelist details should be added with queue manager attribute CLQGRPNL. By doing so, the cluster queue manager can access all the cluster queues belong to the cluster sub-groups listed in the namelist object. If a cluster queue should be visible to more than one cluster sub-group, a name list object with all those sub-groups should be created and the name list details can be mentioned in the cluster queue attribute CLQGRPNL. Both Queue manager and queues should be added with this new attribute CLQGRPNL.

Empty CLUSQGRP & CLQGRPNL attributes means the cluster queue will come under general cluster group and so visible to all the cluster queue managers.

What is New?

In already existing cluster queue security solutions, access control is done in corresponding queue manager's channel level or by other queue managers in the same cluster. Cluster queue in question do not have any control over to whom it will be visible to. Above mentioned new concept with give more control over cluster queue security such a way that, security control of a cluster queue can be done in that cluster queue itself and so access control is easy to implement and makes it easy...