| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WMQ Explorer 7.x - disable "add remote queue manager&qu |
« View previous topic :: View next topic » |
| Author |
Message
|
| odium74 |
 Posted: Fri Jul 11, 2014 6:08 am Post subject: |
 |
|
Newbie
Joined: 10 Jun 2013
Posts: 8
|
| mqjeff wrote: |
| odium74 wrote: |
if the user using WMQ Explorer enters an existing SVRCONN channel (different from the one we admins assigned to him) where MCAUSER="mqm" , then security is compromised !!
Therefore this method won't help in my case.
thanks ! |
Yes it will.
Again, you're thinking about this from the wrong side. You are trying to prevent the users from entering in the wrong channel information, rather than prevent the users from CONNECTING TO THE WRONG CHANNEL.
Before MQ v7.1, SSLPEER is the way you control who can or cannot connect to a given channel.
Before MQv8, CHLAUTH is the way you control who can or cannot connect to a given channel + SSLPEER |
ok , i will implement and do some test with SSL auth ...
thanks to all ... ! |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Jul 11, 2014 6:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mqjeff wrote: |
| At least some channels can reasonably have a user that is a member of the mqm group - provided that it is secured such that only the right people can use it. |
Isn't that what role-based authorities are intended for?
| mqjeff wrote: |
| And, of course, the inbuilt SSL functions that ship with the product. |
I take the use of that as a given 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Jul 11, 2014 11:04 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Most folks do testing with self signed certs. I would avoid having each entity creating their own self signed certificate because that requires you to exchange all those with each other entity. Instead...
I suggest you create:
1 Internal Self Signed CA key store to sign all other Certificate Signing Requests (CSR)
1 Key store per Qmgr (Obviously)
1 key store per User (entity) you want to test
As the signer, you can use this link to view the content of CSRs to ensure folks put what you want in them for the DN. (Would have been nice if GSKit offered that feature, but it don't.)
I like to build the key stores as .kdb (CMS) files and then create .jks version from those (where needed).
You will need to Extract the CA's public cert to be added to all the other key stores before you have them receive the signed CSR (which is just their public cert and their private cert was created in their key store when they created the CSR). This is a two cert exchange vs (N-1)! exchange for trusted entities per key store. Think about it, this approach most closely matches how a Public CA works. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jul 11, 2014 12:06 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
OP - you do realise that "add remote QM" - does not actually create a QM - don't you?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
