| Author |
Message
|
| dotaneli |
 Posted: Tue Nov 02, 2010 5:40 am Post subject: SSL instead of users with ACL? |
 |
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Hey,
anyone knows a way to allow/deny access to MQ resources based on SSL certificates (not user-based)?
Thanks. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Nov 02, 2010 5:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
About the only way I can think of is with an exit.
_________________
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 |
|
|
| dotaneli |
| Posted: Tue Nov 02, 2010 5:46 am Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
| Okay thanks.. any other suggestions? |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Nov 02, 2010 6:10 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
The (free) BlockIP2 exit can be used to assign the mcauser value to connections based on values in the SSL certificate used.
The mcauser value is then used in the usual ACL manner (by granting access to groups that the userid is a member of). |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 02, 2010 6:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
SSLPEER does just this - it determines what DNs are allowed to connect to the channel.
The DN does not have to be for an individual user. The SSLPEER value can match a higher level OU than an individual user, or really any value in the DN at all...
If the certificate is not valid and trusted, the connection will be blocked regardless of DN.
MCAUSER can then enforce a role for any user that is allowed to connect by SSLPEER.
What situation do you need to cover that is not handled by the above? |
|
| Back to top |
|
|
| dotaneli |
| Posted: Tue Nov 02, 2010 11:03 pm Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Thank you all.
mqjeff:
| Quote: |
| What situation do you need to cover that is not handled by the above? |
For example, I want users from Paris to have control over Q.PARIS.IN and Q.PARIS.OUT, but not Q.LONDON.IN or Q.LONDON.OUT, and vice versa.
If I use a SVRCONN, your solution isn't possible. However if I use regular sender-receiver pairs, I can map a user to an organization. I'll have to see if my client uses the SVRCONN or SDR-RCVR pair.
Anyhow, if I understand correclty, except for the solution discussed above, there is no other way to give authorizations to MQ resources such as queues, using SSL certificates instead of users, correct? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 03, 2010 1:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| dotaneli wrote: |
Thank you all.
mqjeff:
| Quote: |
| What situation do you need to cover that is not handled by the above? |
For example, I want users from Paris to have control over Q.PARIS.IN and Q.PARIS.OUT, but not Q.LONDON.IN or Q.LONDON.OUT, and vice versa. |
So users from PARIS connect to SVRCONN.FROM.PARIS and are blocked from connecting to SVRCONN.FROM.LONDON by SSLPEER.
SVRCONN.FROM.PARIS has an MCAUSER(PARIS).
setmqaut is performed for user PARIS to allow Q.PARIS.IN and Q.PARIS out and block Q.LONDON.IN and Q.LONDON.OUT and everything else. |
|
| Back to top |
|
|
| dotaneli |
| Posted: Wed Nov 03, 2010 1:20 am Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
| Right, but doesn't it loose the entire point of an SVR conn? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 03, 2010 1:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| dotaneli wrote: |
| Right, but doesn't it loose the entire point of an SVR conn? |
I have absolutely no idea what you think you mean by this.
Everything I have described is exactly part of the point of a SVRCONN as far as I'm concerned. |
|
| Back to top |
|
|
| dotaneli |
| Posted: Wed Nov 03, 2010 1:31 am Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
| Well one of the things I can think about that justify the use of an SVRCONN channel, are the need of a qmgr admin to not establish a new connection for each new client, so that every single site could connect via the same channel. That of course reduces addministration and makes the B2B connection loosly coupled. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 03, 2010 1:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
And then when one client app at one partner institution had an issue where it spawned 10,000 connections in a single second and didn't drop any, then everyone across the entire B2B network is now unable to talk to your institution.
Not so loosely coupled, then.
 |
|
| Back to top |
|
|
| dotaneli |
| Posted: Wed Nov 03, 2010 1:41 am Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Well that is partly true, in the manner that you get a single point of failure but you are still loosly coupled. Arcitechualy speeking, you are not concered with the identity of your clients (you still need to know the root CA though).
But forget that, you do understand that organizations could not be easily persuaded into defining more channels, right? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 03, 2010 1:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't see how a two minute effort to define a new SVRCONN and configure it to enforce a role-based security model is any more effort on top of creating a new certificate for the partner, or adding the partner's trusted cert to the edge queue manager is significant.
It's another very small, very painless, very useful step in onboarding a new customer.
And a lot easier to sell in most places than an exit. |
|
| Back to top |
|
|
| dotaneli |
| Posted: Wed Nov 03, 2010 1:49 am Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
If the alternative is an exit, you are correct.
That is why i'm looking for other solutions...
As far as ideas goes, you have the best one. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 03, 2010 4:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dotaneli wrote: |
| As far as ideas goes, you have the best one. |
It's also the most typical one. Different user / application / access combinations are typically handled with multiple SVRCONN channels. Many sites in my experience have used SVRCONN channels like SVRCONN.FROM.PARIS.1, SVRCONN.FROM.PARIS.2, etc to segrigate otherwise identical access requirements.
(I make no claim for or against this practice but mention it for illustrative purposes)
| dotaneli wrote: |
| you do understand that organizations could not be easily persuaded into defining more channels |
If the organisation balks at creating more SVRCONN channels, trout them. It's no cost, minimal effort, minimal impact. Sender/Reciever channels ok, you need the network people involved & maybe a few memos. SVRCONN? Please.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
