| Author |
Message
|
| hklbj |
 Posted: Tue Nov 11, 2014 12:05 am Post subject: single server connection channel for multiple client user id |
 |
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Hi,
I have following scenario and would like to seek an advice. thanks.
3 MQ clients are using only server connection channel 'CH.SVRC1' on remote queue manager to access different MQ objects 'Q1', 'Q2', 'Q3' & 'Q4'. My idea would leave the MCAUSER field of 'CH.SVRC1' blank and the client applications will supply the userid respectively to perform operations. Is the setup feasible and any security loophole? I don't want to have 3 server connection channel to server 3 different MQ clients. Appreciate your help.  |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Nov 11, 2014 12:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Leaving the MCA user blank is a security loophole, as it would allow both blank ids to be passed (gaining the channel agent id), and it would allow ids like mqm to be passed.
Check if you can prevent this with CHLAUTH controls (and set the MCAUSER to a value such as NoBody).
You can also solve this using the BlockIP2 exit, and use it to block blank ids and any mqm admin ids. The other ids can be passed through.
_________________
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 |
|
|
| hklbj |
| Posted: Tue Nov 11, 2014 1:42 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Thanks zpat, other than using security exit. Any other implementation can achieve my goal? What i can think about is to create as many server connection per each client but it is difficult to manage from administration point of view.  |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Nov 11, 2014 1:45 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
In MQ V8.0 you can just have the client applications providing a userid/password combination. That password can be validated against the OS or LDAP etc. The client can then run with the authority of the userid provided. Is this the type of thing you wanted?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| hklbj |
| Posted: Tue Nov 11, 2014 1:50 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
| PaulClarke wrote: |
In MQ V8.0 you can just have the client applications providing a userid/password combination. That password can be validated against the OS or LDAP etc. The client can then run with the authority of the userid provided. Is this the type of thing you wanted?
Cheers,
Paul. |
Thanks Paul, it sounds good.
However, my MQ server version is 7.5 only. I would like to study chlauth, do you have any relevant information? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 11, 2014 1:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hklbj wrote: |
| What i can think about is to create as many server connection per each client but it is difficult to manage from administration point of view. |
Each client installation should have (ideally) it's own SVRCONN and if you're disciplined enough in your approach to managing it, it's not difficult. Alternatives have already been suggested by zpat and PaulClarke. As regards CHLAUTH, there are Morag Hughson's fine articles on developerWorks.
_________________
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 |
|
|
| zpat |
| Posted: Tue Nov 11, 2014 1:59 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
A different channel for each client? I would hate to have your CCDT maintenance effort!
Quote from someone - “Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it.”
_________________
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 |
|
|
| hughson |
| Posted: Tue Nov 11, 2014 2:38 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
I wouldn't generally suggest a need to have three separate SVRCONN channels for this. One channel definition and three CHLAUTH rules to set a different MCAUSER for each running instance with the channel definition MCAUSER set to "nobody" as already suggested would cover the security side of things.
The other reasons to want separate channel names is to allow you to STOP CHANNEL a specific one, but since you can use STOP CHANNEL with the IP address of the one you want to stop, and you can use CHLAUTH to disallow access, that argument goes away too.
Another reason for separate channels might be to control how many instances of each application can run, but since you have MAXINST and MAXINSTC, you can control that on a single channel too.
The final reason would be for management, i.e. wanting to easily see what is connected. DISPLAY CHSTATUS shows you the RAPPLTAG which is the remote application name, but if these are all the same, then a different channel name would aid in knowing what's what. FYI, the main reason these would be the same was Java.exe, but that was solved in V7.5 where the main class name was used as the APPLTAG instead of "WebSphere MQ Client for Java" for all of them, so this may not even be a good reason any more.
Just food for thought, I may have missed other good reasons for having a separate SVRCONN channel name, but I'm sure others will chip in with them.
P.S. CHLAUTH blog posts listed here.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 11, 2014 2:56 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
A different channel for each client? I would hate to have your CCDT maintenance effort!
Quote from someone - “Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it.” |
It was a long night last night, so I'll clarify - by 'client installation' I mean per server, not per client(s) running on a particular server, except where it's shared infrastructure, e.g. multiple business units running on the same tin (if only...). With the advent of MAXINST and MAXINSTC, CHLAUTH, et al, life has become a lot easier, but I still would separate as far as possible, i.e. not have non-related business-line apps using the same channel - but that's just me.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Nov 11, 2014 4:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hughson wrote: |
The other reasons to want separate channel names is to allow you to STOP CHANNEL a specific one, but since you can use STOP CHANNEL with the IP address of the one you want to stop, and you can use CHLAUTH to disallow access, that argument goes away too.
|
With the possibility of multiple unrelated applications running on the same WAS / .NET / Weblogic server, I still vote for a separate SVRCONN channel per application.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hklbj |
| Posted: Tue Nov 11, 2014 8:33 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Thanks all valuable suggestions and opinions. 
I will study about CHLAUTH in my case. Anyway, thanks again. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 11, 2014 8:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| With the possibility of multiple unrelated applications running on the same WAS / .NET / Weblogic server, I still vote for a separate SVRCONN channel per application. |
Do you mean a unique SVRCONN for each individual application? Or, application type (like Payroll, Inventory)?
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Nov 11, 2014 10:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Each individual app. Not each instance of that app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 11, 2014 10:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| Each individual app. Not each instance of that app. |
So to be clear, if you have four apps that together make up the payroll business thingy, you'd end up having four svrconns, one for each piece of the payroll business thingy. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 11, 2014 1:37 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| Each individual app. Not each instance of that app. |
So, if I have 30 individual application programss that comprise the payroll system, and 30 that do inventory, and 30 that do a/p, 30 that do a/r, 30 that do CRM, ... then you're suggesting 150+ individual SVRCONN channels?
_________________
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 |
|
|
|
|
