| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| CHLAUTH : how to block all and allow only explicite ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| exerk |
 Posted: Thu Nov 21, 2013 8:00 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Michael Dag wrote: |
| exerk wrote: |
| JosephGramig wrote: |
| Since the WMQ admin is the one that creates the OAM rules governing access, it makes sense that they are also the ones managing the Internal CA... |
Joseph, I'm going to strongly disagree with you here because to me that's like giving the keys of the asylum to the inmates - too open to abuse. |
I read this in the context to Developers needing access... so we are talking about DEV/TEST environments not ACC/PROD where NO Developers should be allowed... |
I stand by my statement - just because it's Dev/Test is no excuse that it should not be treated the same as the higher environments, and if you have an internal CA controlled by the appropriate department, that department will undoubtedly have non-Production and Production CAs.
_________________
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: Thu Nov 21, 2013 9:53 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| exerk wrote: |
| Michael Dag wrote: |
| exerk wrote: |
| JosephGramig wrote: |
| Since the WMQ admin is the one that creates the OAM rules governing access, it makes sense that they are also the ones managing the Internal CA... |
Joseph, I'm going to strongly disagree with you here because to me that's like giving the keys of the asylum to the inmates - too open to abuse. |
I read this in the context to Developers needing access... so we are talking about DEV/TEST environments not ACC/PROD where NO Developers should be allowed... |
I stand by my statement - just because it's Dev/Test is no excuse that it should not be treated the same as the higher environments, and if you have an internal CA controlled by the appropriate department, that department will undoubtedly have non-Production and Production CAs. |
You know, to be a WMQ Administrator explicitly means you are fully trusted because there is nothing you cannot do... For this reason, I'm against any ID other than mqm (or the WMQ service ID) being in the mqm group. Only WMB forces you to add the WMB servide ID to the mqm group and current versions have a way around that. But I digress...
When you have another department that manages CAs (Internal and External), sure they would do it. But it is important that they know what you as the WMQ Admin require in the DN of the certificates being issued so that the certificate can be associated with an ID (shared or individual (and most places don't want to allow a shared ID)).
In my current case, it is only the WMQ Admins enforcing identity and no other group is willing to take on this responsibility. I'm not an inmate and you cannot find any record of me being one at any mental institution. 
And "of course I'm trustworthy"!  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 21, 2013 10:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| JosephGramig wrote: |
And "of course I'm trustworthy"! |
I can vouch for JosephGramig because, well, he's on the Internet...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Nov 21, 2013 10:10 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| exerk wrote: |
| I stand by my statement - just because it's Dev/Test is no excuse that it should not be treated the same as the higher environments, and if you have an internal CA controlled by the appropriate department, that department will undoubtedly have non-Production and Production CAs. |
If you have them... use them ofcourse!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bernard_fay |
| Posted: Tue Nov 26, 2013 4:40 am Post subject: |
|
|
Apprentice
Joined: 24 Jul 2012
Posts: 30
|
Yes, it is a development environment.
So, if I understand well the only way to achieve this is by the use of CA.
I am really puzzled why IBM did not setup something to allow security on a user id basis??? It sounds rather strange to me.
Thanks everyone for your inputs.
Bernard |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 26, 2013 6:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bernard_fay wrote: |
Yes, it is a development environment.
So, if I understand well the only way to achieve this is by the use of CA.
I am really puzzled why IBM did not setup something to allow security on a user id basis??? It sounds rather strange to me.
Thanks everyone for your inputs.
Bernard |
Well Bernard, there are 2 points here
Assuming you have prevented admin access on the channel, and set up your group permissions correctly, you have permissions on a user_id level (really group level) and this is part of authorizations.
However if you need authentication (check that the userid is who he pretends to be), then yes the default way to do this is via SSL certs.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Nov 26, 2013 7:04 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| bernard_fay wrote: |
Yes, it is a development environment.
So, if I understand well the only way to achieve this is by the use of CA.
I am really puzzled why IBM did not setup something to allow security on a user id basis??? It sounds rather strange to me.
Thanks everyone for your inputs.
Bernard |
Or channel exits... But I think the SSL answer is more reliable. If you feel the need, then use a Public CA but you need to answer how the content of the DN will be enforced. Just having a good certificate is not enough. You need to know who it belongs to and possibly other associations (like OUs to indicate a User or Application group, or the CN to indicate exactly who, or OU to indicate what MQ cluster it may participate in and so on).
Lots of thought and planning needs to go into SSL (and just as much in to channel exits and maybe a lot more).
IMHO, if you go the channel exit route, then you should definitely purchase commercially available products because it will be:
- Cheaper
- Available faster
- Supported
- ...and I'm sure we can go on and on
|
|
| Back to top |
|
|
| bernard_fay |
| Posted: Tue Nov 26, 2013 7:48 am Post subject: |
|
|
Apprentice
Joined: 24 Jul 2012
Posts: 30
|
| Quote: |
| Assuming you have prevented admin access on the channel, and set up your group permissions correctly, you have permissions on a user_id level (really group level) and this is part of authorizations. |
I really have the feeling I skipped something while reading the infocenter.
So far, I gave access (inq, connect, dsp) to a QM for a local user on the server but everybody can access the QM. I don't want that. I would like to give access only to a small group of developers.
To the same local user I gave DSP access to the server-connection channel.
Do I look at the wrong place to save my problem?
Thanks,
Bernard |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Tue Nov 26, 2013 8:06 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Bernard,
You need a way to positively identify who is connecting. You can do that with either a channel exit or an SSL certificate that contains identifying information (like CN=AD.ID). In the case of SSL, you need to know the issuer made sure of the content of the certificate request was valid (openssl will let you look at the request (odd that you cannot do that with GS Kit)).
In your case, it looks like you want to map a group of folks (DEV_FOLKS) to a single ID. For this case, have the developers make certificate requests that have OU=DEV_FOLKS in the DN (at least). Then on the channel you already created, specify a SSLCIPH and SSLPEER('OU=DEV_FOLKS'). This will only allow connections with a valid certificate that contains OU=DEV_FOLKS to connect.
Is this what you want? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 26, 2013 2:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bernard_fay wrote: |
| Quote: |
| Assuming you have prevented admin access on the channel, and set up your group permissions correctly, you have permissions on a user_id level (really group level) and this is part of authorizations. |
I really have the feeling I skipped something while reading the infocenter.
So far, I gave access (inq, connect, dsp) to a QM for a local user on the server but everybody can access the QM. I don't want that. I would like to give access only to a small group of developers.
To the same local user I gave DSP access to the server-connection channel.
Do I look at the wrong place to save my problem?
Thanks,
Bernard |
Remember that in Unix you do not allocate permissions to a user but to it's primary group. So if you thought you only gave permission to Jill but everybody has access it may well be because Jill's primary group was users and everybody else is in it as well...
This is why it is always better to allocate permissions to groups instead of users. You can then move users from group to group as needed.
Also when setting an mcauser on a channel all users will have the permissions of the user specified in the mca... This when you will want to apply an SSL cert with SSL Peer check. It is really a must for admin access to the qmgr over a svrconn channel. Either SSL or as my esteemed collegue said an authentication exit.
Have fun
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
