|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ Security Exit for Svrconn Channels |
« View previous topic :: View next topic » |
Author |
Message
|
vignesh1988 |
Posted: Sun Jan 11, 2015 10:27 pm Post subject: MQ Security Exit for Svrconn Channels |
|
|
Acolyte
Joined: 13 Apr 2013 Posts: 62 Location: Chennai
|
Hello ,
I am developing MQ Security Exit for Svrconn channel. 90% of the servers are in Version 7.0.1
So i need advise on how does the svrconn channel security exit work? Since i am planning to set it up across the platforms
I am planning to have a external file which will contains ID's that are permitted to use this svrconn channel and revoke others using suitable error message.
I have only 1 server connection (Svrconn) channel and i have altered with a SCYEXIT name
My exit is working without any syntax error. But i heard that we also need CLNTCONN channel as well since CLNTCONN and SVRCONN imitates Sender and Receiver channel pairs.
So if anyone can guide me through how to set it up , that would be grateful.
I appreciate your help on this.
Thanks
Vignesh |
|
Back to top |
|
 |
PaulClarke |
Posted: Mon Jan 12, 2015 1:03 am Post subject: |
|
|
 Grand Master
Joined: 17 Nov 2005 Posts: 1002 Location: New Zealand
|
This may be just a language thing but your description is slightly misleading.
Every client connection in to a Queue Manager needs two channel definitions - a SVRCONN channel at the Queue Manager and a CLNTCONN channel at the client end. The CLNTCONN channel can come from a variety of sources such as MQSERVER, CCDT, application code etc.
This is similar to a Sender/Receiver channel, as in you need a channel at either end, but there is no imitating going on. The way a CLNTCONN/SVRCONN channel operates is very different from the way a SENDER/RECEIVER channel operates.
As for Security exits you can choose where you want to run them. It is not necessary to run a Security exit at both ends so, if you want to run one just at the Queue Manager end that is fair enough. Clearly if you only run a security exit at one end then the exits can not 'chat' with each other to exchange secrets tokens etc. So, in general with exits at both ends you can make the channel more secure but it is not required by MQ.
Cheers,
Paul. _________________ Paul Clarke
MQGem Software
www.mqgem.com |
|
Back to top |
|
 |
RogerLacroix |
Posted: Mon Jan 12, 2015 3:57 pm Post subject: Re: MQ Security Exit for Svrconn Channels |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hello Vignesh,
You have embarked on a path that requires in-depth security knowledge and strong MQ knowledge.
Why would you want to re-invent the wheel when there is both free (unsupported) and commercial solutions available??
Free:
- BlockIP2 is a server-side only MQ security solution
Commercial:
- Capitalware's MQ Standard Security Exit is a server-side only MQ security solution
- Capitalware's MQ Authenticate User Security Exit implements full client & server MQ security solution
vignesh1988 wrote: |
I am planning to have a external file which will contains ID's that are permitted to use this svrconn channel and revoke others using suitable error message. |
And how would this be any different than using BlockIP2 or MQSSX?? Also, the problem with this solution, is that if a user knows that UserID "XYZ" is in your "good UserID" list then a bad user (hacker) can simply set that UserID in their MQ application and you would never know any difference.
Yes, you can add a second level of checking by checking the incoming IP address along with the UserID and of course, some will even suggest using SSL, so as you can see the complexity will get difficult for server-side only solution.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Jan 13, 2015 6:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You might also review the functions available with CHLAUTH rules in MQ v7.1 and later to see if they meet your requirements.
And, of course, MQ v8 has username/password authentication as well.
Neither will let you stick a list of usernames into a text file. But the local OS registry of the server hosting the queue manager should reasonably be sufficient instead... |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|