| Author |
Message
|
| trotta |
 Posted: Tue Nov 02, 2010 9:17 am Post subject: Security Leve at MQ |
 |
|
Newbie
Joined: 02 Nov 2010
Posts: 7
Location: Brazil
|
Currently, I'm working in a project which is aimed to connect more than 23 clients as Robot to the same server by using 1 inbound and 1 outbound common queues to store incoming and outcoming messages. The solution is based on push/pull strategy, which the robot would be responsible to push the message, the server would get that message, process it and put the answer into the outbound queue. After that, the Robot would be responsible to pull the data from outbound queue.
What can we make at the MQ end to guarantee that nobody could touch on the wrong message or steal a given message which needs to be picked up by another robot, even we could use correlation id to identify a given message created by a given robot?
On bottom line, Robot A and B are sharing the same queue and A can not see or get the message which belongs to B. Getting Browser permission denied on the queue would it be secure enough ? Could be possible anyone perform a MQGET() and get all the messages ? Is there anything I can do to become it secure without using separate queues for each robot ?
Thank you |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 02, 2010 9:25 am Post subject: Re: Security Leve at MQ |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| trotta wrote: |
| Is there anything I can do to become it secure without using separate queues for each robot ? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 02, 2010 9:27 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The correlation id is a way to ensure that the 'robot' gets only its message but there is no guarantee that 'something else' can't open the queue and get all messages, alternatives are the ability for the client to have a temporary dynamic queue for the reply, or as you stated, a separate 'permanent' queue of its own. Secure your channels for each client using the appropriate methods, e.g. SSL, SSLPEER, and MCAUSER, or use something like BlockIP2 if you want to use only one channel (not advisable in my view) and the clients are from different IP addresses.
Just my tuppeny-worth...
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Nov 02, 2010 10:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
As mentioned you can use a dynamic queue to ensure that the only message that a robot is eligible to receive is it's own.
There's no particular reason to use the same queue for all of the robots.
And of course you can code the server and the robot to encrypt and decrypt the message data separately from an MQ provision. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Tue Nov 02, 2010 10:16 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Quote: |
| ...connect more than 23 clients as Robot to the same server by using 1 inbound and 1 outbound common queues to store incoming and outcoming messages. |
New Queue would do the Job for you !! Agree with Vitor.
BUT if inbound message has some 'Unique Field Value' in the inbound msg itself and that value is being kept in the reply msg then Robot can compare it while getting the reply message back.
A & B are 2 Robots, both have 'unique field value' in their msgs.
Ex:
For 'A' its
<unique>A Identity007</unique>
For 'B' its
<unique>B Identity900</unique>
If 'A' knows that it would get the msg and it would do IF-CONDITION-THEN-ELSE based on value of <unique></unique> field then it can accept those msgs that match the criteria else ignore them.
BUT if the application has got all the msgs in one go from the Queue, then those msgs would be off from the queue and other applications would be waiting still for the correct reply msg.
So better, go for Different Qs.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 02, 2010 11:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| shashivarungupta wrote: |
| BUT if inbound message has some 'Unique Field Value' in the inbound msg itself and that value is being kept in the reply msg then Robot can compare it while getting the reply message back. |
But this wouldn't prevent Robot A getting messages intended for Robot B
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 02, 2010 2:06 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| BUT if inbound message has some 'Unique Field Value' in the inbound msg itself and that value is being kept in the reply msg then Robot can compare it while getting the reply message back. |
And while the message is being being browsed by a robot that the message doesn't belong to, and a message is removed off the queue, so the browse cursor has effectively moved, the latency this all introduces, oh, and not forgetting or ignoring the fact that browsing a message is synonymous to a non-destructive GET, which is what the OP wants to avoid....need I go on?
_________________
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 |
|
|
| shashivarungupta |
| Posted: Tue Nov 02, 2010 11:34 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| Vitor wrote: |
| shashivarungupta wrote: |
| BUT if inbound message has some 'Unique Field Value' in the inbound msg itself and that value is being kept in the reply msg then Robot can compare it while getting the reply message back. |
But this wouldn't prevent Robot A getting messages intended for Robot B |
Absolutely !
| exerk wrote: |
| And while the message is being being browsed by a robot that the message doesn't belong to, and a message is removed off the queue, so the browse cursor has effectively moved, the latency this all introduces, oh, and not forgetting or ignoring the fact that browsing a message is synonymous to a non-destructive GET, which is what the OP wants to avoid....need I go on? |
I mentioned what would be the scenario of destructive GET above. And in case of non-destructive GET , robots can still see the msgs of their match Or of not their match !! So problem would persist.
That's why I said, "So better, go for Different Qs."
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Nov 05, 2010 5:10 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
And 'trotta' has been working on the architecture of how the Robots will work on multiple outbound queues to MQGET the msgs, (whereas inbound queue would be same for all robots, target would get the messages from it and would have the logic to filter them based on the nature of the messages). Target would put the Reply msgs, intelligently, to the respective outbound queues from where robots will pick the messages up.
(And this helps me to complete the 7 Tons) 
Thanks all. 
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| trotta |
| Posted: Fri Nov 05, 2010 12:41 pm Post subject: |
|
|
Newbie
Joined: 02 Nov 2010
Posts: 7
Location: Brazil
|
Yes ! Thank you everyone who replied my topic.
I appreciate all the suggestions provided here.
 |
|
| Back to top |
|
|
|
|
