Author |
Message
|
saurabh25281 |
Posted: Wed Mar 27, 2019 11:32 pm Post subject: Secuirty for SVRCONN channels |
|
|
Centurion
Joined: 05 Nov 2006 Posts: 108 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 other’s 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 user’s 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 |
|
 |
fjb_saper |
Posted: Thu Mar 28, 2019 5:19 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 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 |
|
 |
RogerLacroix |
Posted: Thu Mar 28, 2019 2:32 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 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 |
|
 |
saurabh25281 |
Posted: Tue Apr 02, 2019 11:23 pm Post subject: |
|
|
Centurion
Joined: 05 Nov 2006 Posts: 108 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 |
|
 |
PeterPotkay |
Posted: Wed Apr 03, 2019 4:52 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
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 |
|
 |
|