| Author |
Message
|
| WannaBeInAParker |
 Posted: Wed May 19, 2010 8:10 am Post subject: Extended Transactional Client - Require its use? |
 |
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
Is there any way through configuration of a SVRCONN channel to require that all connections are using the ET Client? If not through configuration is the information available through an exit? That is can I determine if the client program is using the ET client and if not reject the connection?
Any help is appreciated
Jack
_________________
-WannaBe- |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed May 19, 2010 12:44 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Give the Extended Transactional clients their own channel(s), and the non-ET clients their own channel(s), and control it by CCDT. Further lock it down with SSL and use unique SSLPEER values in the client certificates (values that distinguish whether a client using that certificate is ET or not), or use a commercial exit (I'm sure Roger will be along in a minute to recommend just the thing  ).
_________________
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 |
|
|
| mvic |
| Posted: Wed May 19, 2010 12:45 pm Post subject: Re: Extended Transactional Client - Require its use? |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| WannaBeInAParker wrote: |
| Is there any way through configuration of a SVRCONN channel to require that all connections are using the ET Client? |
Polite question : why? |
|
| Back to top |
|
|
| WannaBeInAParker |
| Posted: Wed May 19, 2010 1:01 pm Post subject: |
|
|
Voyager
Joined: 09 Dec 2003
Posts: 81
|
Yes, a very good question. I work for a company that as a rule, does not allow client channels. We have allowed them on a limited basis for internal users, but have locked them down to only access a small subset of queues and have the blockip msg exit installed to only allow access from certain IPs. We are discussing MQSeries communication with an external company over a leased line and they are pushing to use a client channel with the ET Client on their end. I understand that even if we force the external user to use the ET, they can still simply put the messages out of syncpoint essentially falling back to the default client. However, forcing the use of the ET on our end makes management feel better about allowing the use of client channels for external access.
I hope this helps
Jack
_________________
-WannaBe- |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 19, 2010 1:25 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Thanks.
IMHO users/groups/setmqaut/security exits are the MQ way to do this.
Or SSL perhaps. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed May 19, 2010 4:26 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mvic wrote: |
| IMHO users/groups/setmqaut/security exits are the MQ way to do this. Or SSL perhaps. |
Yes, to control access to a channel, but this does not control usage of ET. A Receive Exit or Send Exit will expose the lower level MQ protocols and can be used to detect if ET being used, and control access. I don't know of any exits on the market that do this.
_________________
Glenn |
|
| Back to top |
|
|
| mvic |
| Posted: Wed May 19, 2010 4:36 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| gbaddeley wrote: |
| Yes, to control access to a channel, but this does not control usage of ET. |
Agreed, but restricting to ETC is not a "reasonable" requirement.
Included in the scope of "reasonable" is the concept of "maintainable and usable into the foreseeable future".
IMHO, of course. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 19, 2010 5:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| WannaBeInAParker wrote: |
Yes, a very good question. I work for a company that as a rule, does not allow client channels. We have allowed them on a limited basis for internal users, but have locked them down to only access a small subset of queues and have the blockip msg exit installed to only allow access from certain IPs. We are discussing MQSeries communication with an external company over a leased line and they are pushing to use a client channel with the ET Client on their end. I understand that even if we force the external user to use the ET, they can still simply put the messages out of syncpoint essentially falling back to the default client. However, forcing the use of the ET on our end makes management feel better about allowing the use of client channels for external access.
I hope this helps
Jack |
You don't need MQETC to have MQ Clients use syncpoint on its puts and/or gets.
An app using MQETC is under no obligation to use syncpoint on its puts and/or gets.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
