ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ SecuritySecuirty for SVRCONN channels

Post new topicReply to topic
Secuirty for SVRCONN channels View previous topic :: View next topic
Author Message
saurabh25281
PostPosted: Wed Mar 27, 2019 11:32 pm Post subject: Secuirty for SVRCONN channels Reply with quote

Voyager

Joined: 05 Nov 2006
Posts: 98
Location: Bangalore

Hi All,

We have a Security scenario involving SVRCONN channels for which we want to find an appropriate solution. Below is our scenario.

We are using MQv 9.0.1
We have 2 LDAP users, one belonging to a group and the other is a non-member.
Both users are connecting from same Appserver to the same Queue Manager.
Both users have +connect access to Qmgr.
Both have access to their respective SVRCONN channels i.e. OAM authorizations are set to +all.
Both the channels are non-SSL.


Requirement is that the non-member user should not be able to connect to the Queue Manager using the others channel. The current ChlAuth rules does not restrict or allow user based on group membership. Hence what are the various solutions for such requirement?

The risk is that the non-member can use the member users channels to connect to the Qmgr which we want to avoid.

We have identified 3 ways of achieving it but are not suitable in our case. They are the following
1. Using SSL SvrConn channels and sharing the keys with group members. Since there are large number of groups and group access would be dynamic this would be an administration nightmare.
2. Using individual ChlAuth rules for each members of a group. This would be difficult to manage, since members of a group needs to be synced to ChlAuth rules periodically.
3. Channel Security Exits managing them is very difficult.

Regards
Saurabh[/list]
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
fjb_saper
PostPosted: Thu Mar 28, 2019 5:19 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20066
Location: LI,NY

I expect non group members users and users do not come from the same subnets.
Did you think about authorizing the corresponding subnet and then setting a backstop rule?
Should they come from the same subnet, using a cert and SSL/TLS is a good start, however you want to make sure that all the group members have a specific OU that non group members don't have. You can then filter on the OU via SSL PEER... and have all their certs signed by an internal CA so no nightmare with cert management...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
RogerLacroix
PostPosted: Thu Mar 28, 2019 2:32 pm Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3122
Location: London, ON Canada

saurabh25281 wrote:
3. Channel Security Exits - managing them is very difficult.

Depends on the product. MQAUSX can easy handle that task. 5 minute job: just create 2 (or more) IniFiles - 1 for each channel and define your LDAP parameters for each.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
saurabh25281
PostPosted: Tue Apr 02, 2019 11:23 pm Post subject: Reply with quote

Voyager

Joined: 05 Nov 2006
Posts: 98
Location: Bangalore

Quote:
Did you think about authorizing the corresponding subnet and then setting a backstop rule?

Doesn't the backstop (CHLAUTH) rule kicks in first before OAM Authorization? We have authorization on groups but they are applied once the CHLAUTH have filtered away the unwanted connections.

Quote:
using a cert and SSL/TLS is a good start, however you want to make sure that all the group members have a specific OU that non group members don't have. You can then filter on the OU via SSL PEER... and have all their certs signed by an internal CA so no nightmare with cert management

Like I have mentioned before, we have discarded the SSL options because we don't want to create multiple certs for multiple group, since authenticating group membership is already possible using LDAP and also because provisioning certs normally takes time which we are trying to avoid. We provide them self service tool from where they enter their details and have security and access taken care.
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
PeterPotkay
PostPosted: Wed Apr 03, 2019 4:52 pm Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7546

saurabh25281 wrote:
We provide them self service tool from where they enter their details and have security and access taken care.

Self service security? Sounds secure.


You have identified the 3 possible choices in your initial post. Yes, security does take some effort.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ SecuritySecuirty for SVRCONN channels
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.