You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by mgiammarco <mg...@gmail.com> on 2011/12/31 19:57:36 UTC

Message level authentication

Hello,
if I have multiple clients that put messages in a queue managed by Camel AND
each client can receive as a reply many messages how can I do it with Camel?

I mean suppose that I create an "out" queue where all replies go. How can I
be sure that a client can get ONLY its messages?

Does Camel put the Principal (user authenticated) in the header of the
message?

Is there a "standard" way that I have not found in the documentation?

Thanks in advance for any reply!

Mario

--
View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5112517.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Message level authentication

Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey,
As was said in previous responses you can use few queues. From producer point of view you can use an virtual destination. This feature is officialy supported by ActiveMQ http://activemq.apache.org/virtual-destinations.html#VirtualDestinations-Usingfiltereddestinations

You will have a central place where the dispatching is done. If you would need a dynamic routing then you can use Camel.

Regards,
Łukasz Dywicki
--
Code-House
http://code-house.org


> Thanks for reply in the first day of the year (and BUON ANNO!).
> 
> I will consider this thing but I am worried about two things:
> 
> - security: can one client "steal messages from others?"
> - automation: it seems to me that it is a manual way. Is there an "official
> way" to do it? For example to put a token/nonce/principal from value from
> spring security (or oauth) in the header of the message?
> 
> I have supposed that mine was a common problem.
> 
> Thanks again,
> Mario
> 
> --
> View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113046.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



Re: Message level authentication

Posted by mgiammarco <mg...@gmail.com>.
Thanks for reply in the first day of the year (and BUON ANNO!).

I will consider this thing but I am worried about two things:

- security: can one client "steal messages from others?"
- automation: it seems to me that it is a manual way. Is there an "official
way" to do it? For example to put a token/nonce/principal from value from
spring security (or oauth) in the header of the message?

I have supposed that mine was a common problem.

Thanks again,
Mario

--
View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113046.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Message level authentication

Posted by Christian Schneider <ch...@die-schneider.net>.
It is always the client that creates the temp queue and sends it as the 
replyTo header field to the server.

Camel by default uses temp queues if you do not give it a special reply 
queue. So e.g.

from("jetty:http://server/endpoint").to("jms:queuename")

from("jms:queuename").to("bean:test")

These routes are both request reply. The first route realizes a bridge 
from http to jms. So reuests go to the server and the response message 
is given back a http response. So you do not see temp queues as they are 
the default.

Christian

Am 01.01.2012 23:06, schrieb mgiammarco:
> Ok probably I have found the right docs. Now I miss only one piece: how can
> the external client that does not know about camel find the right jms
> temporary queue that camel has created for it for receiving more than one
> reply message?
>
> Thanks,
> Mario
>
> 2012/1/1 Mario Giammarco<mg...@gmail.com>
>
>> Ok I will discard encryption, too difficult and too much cpu use.
>>
>> I am very interested in temp queues.
>> Are they jms queues or are internal Camel queues? Are they created
>> dinamically following the clients connected?
>> I now go searching documentation because I have not found them before.
>>
>> Thanks,
>> Mario
>>
>> 2012/1/1 Christian Schneider [via Camel]<
>> ml-node+s465427n5113105h50@n5.nabble.com>
>>
>>   A selector would allow to only get the messages of the client but it
>>> would not prevent a malicious client to do otherwise. So from a security
>>> standpoint that does not help.
>>>
>>> I see two main options here:
>>>
>>> 1. Use separate reply queues for each client. The easiest way is to just
>>> use the default (temp queues). So the clients do not see each other at
>>> all
>>>
>>> 2. Encrypt the reply message with a key only the client knows. e.g.
>>> public/private key scheme.
>>>
>>> Christian
>>>
>>> Am 01.01.2012 11:45, schrieb Filippo Balicchia:
>>>
>>>> Hello,
>>>> Why don't use message selector from client point of view ?
>>>>
>>>> --Filippo
>>>>
>>>> Il 31 dicembre 2011 19:57, mgiammarco<[hidden email]<http://user/SendEmail.jtp?type=node&node=5113105&i=0>>
>>>   ha scritto:
>>>>> Hello,
>>>>> if I have multiple clients that put messages in a queue managed by
>>> Camel AND
>>>>> each client can receive as a reply many messages how can I do it with
>>> Camel?
>>>>> I mean suppose that I create an "out" queue where all replies go. How
>>> can I
>>>>> be sure that a client can get ONLY its messages?
>>>>>
>>>>> Does Camel put the Principal (user authenticated) in the header of the
>>>>> message?
>>>>>
>>>>> Is there a "standard" way that I have not found in the documentation?
>>>>>
>>>>> Thanks in advance for any reply!
>>>>>
>>>>> Mario
>>>>>
>>>>> --
>>>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5112517.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>> --
>>>
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>   If you reply to this email, your message will be added to the
>>> discussion below:
>>>
>>> http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113105.html
>>>   To unsubscribe from Message level authentication, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5112517&code=bWdpYW1tYXJjb0BnbWFpbC5jb218NTExMjUxN3wtMTIyMTI5ODI4>
>>> .
>>> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113637.html
> Sent from the Camel - Users mailing list archive at Nabble.com.


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Re: Message level authentication

Posted by mgiammarco <mg...@gmail.com>.
Ok probably I have found the right docs. Now I miss only one piece: how can
the external client that does not know about camel find the right jms
temporary queue that camel has created for it for receiving more than one
reply message?

Thanks,
Mario

2012/1/1 Mario Giammarco <mg...@gmail.com>

> Ok I will discard encryption, too difficult and too much cpu use.
>
> I am very interested in temp queues.
> Are they jms queues or are internal Camel queues? Are they created
> dinamically following the clients connected?
> I now go searching documentation because I have not found them before.
>
> Thanks,
> Mario
>
> 2012/1/1 Christian Schneider [via Camel] <
> ml-node+s465427n5113105h50@n5.nabble.com>
>
>  A selector would allow to only get the messages of the client but it
>> would not prevent a malicious client to do otherwise. So from a security
>> standpoint that does not help.
>>
>> I see two main options here:
>>
>> 1. Use separate reply queues for each client. The easiest way is to just
>> use the default (temp queues). So the clients do not see each other at
>> all
>>
>> 2. Encrypt the reply message with a key only the client knows. e.g.
>> public/private key scheme.
>>
>> Christian
>>
>> Am 01.01.2012 11:45, schrieb Filippo Balicchia:
>>
>> > Hello,
>> > Why don't use message selector from client point of view ?
>> >
>> > --Filippo
>> >
>> > Il 31 dicembre 2011 19:57, mgiammarco<[hidden email]<http://user/SendEmail.jtp?type=node&node=5113105&i=0>>
>>  ha scritto:
>> >> Hello,
>> >> if I have multiple clients that put messages in a queue managed by
>> Camel AND
>> >> each client can receive as a reply many messages how can I do it with
>> Camel?
>> >>
>> >> I mean suppose that I create an "out" queue where all replies go. How
>> can I
>> >> be sure that a client can get ONLY its messages?
>> >>
>> >> Does Camel put the Principal (user authenticated) in the header of the
>> >> message?
>> >>
>> >> Is there a "standard" way that I have not found in the documentation?
>> >>
>> >> Thanks in advance for any reply!
>> >>
>> >> Mario
>> >>
>> >> --
>> >> View this message in context:
>> http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5112517.html
>> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113105.html
>>  To unsubscribe from Message level authentication, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5112517&code=bWdpYW1tYXJjb0BnbWFpbC5jb218NTExMjUxN3wtMTIyMTI5ODI4>
>> .
>> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>


--
View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113637.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Message level authentication

Posted by mgiammarco <mg...@gmail.com>.
Ok I will discard encryption, too difficult and too much cpu use.

I am very interested in temp queues.
Are they jms queues or are internal Camel queues? Are they created
dinamically following the clients connected?
I now go searching documentation because I have not found them before.

Thanks,
Mario

2012/1/1 Christian Schneider [via Camel] <
ml-node+s465427n5113105h50@n5.nabble.com>

> A selector would allow to only get the messages of the client but it
> would not prevent a malicious client to do otherwise. So from a security
> standpoint that does not help.
>
> I see two main options here:
>
> 1. Use separate reply queues for each client. The easiest way is to just
> use the default (temp queues). So the clients do not see each other at all
>
> 2. Encrypt the reply message with a key only the client knows. e.g.
> public/private key scheme.
>
> Christian
>
> Am 01.01.2012 11:45, schrieb Filippo Balicchia:
>
> > Hello,
> > Why don't use message selector from client point of view ?
> >
> > --Filippo
> >
> > Il 31 dicembre 2011 19:57, mgiammarco<[hidden email]<http://user/SendEmail.jtp?type=node&node=5113105&i=0>>
>  ha scritto:
> >> Hello,
> >> if I have multiple clients that put messages in a queue managed by
> Camel AND
> >> each client can receive as a reply many messages how can I do it with
> Camel?
> >>
> >> I mean suppose that I create an "out" queue where all replies go. How
> can I
> >> be sure that a client can get ONLY its messages?
> >>
> >> Does Camel put the Principal (user authenticated) in the header of the
> >> message?
> >>
> >> Is there a "standard" way that I have not found in the documentation?
> >>
> >> Thanks in advance for any reply!
> >>
> >> Mario
> >>
> >> --
> >> View this message in context:
> http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5112517.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113105.html
>  To unsubscribe from Message level authentication, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5112517&code=bWdpYW1tYXJjb0BnbWFpbC5jb218NTExMjUxN3wtMTIyMTI5ODI4>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5113540.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Message level authentication

Posted by Christian Schneider <ch...@die-schneider.net>.
A selector would allow to only get the messages of the client but it 
would not prevent a malicious client to do otherwise. So from a security 
standpoint that does not help.

I see two main options here:

1. Use separate reply queues for each client. The easiest way is to just 
use the default (temp queues). So the clients do not see each other at all

2. Encrypt the reply message with a key only the client knows. e.g. 
public/private key scheme.

Christian

Am 01.01.2012 11:45, schrieb Filippo Balicchia:
> Hello,
> Why don't use message selector from client point of view ?
>
> --Filippo
>
> Il 31 dicembre 2011 19:57, mgiammarco<mg...@gmail.com>  ha scritto:
>> Hello,
>> if I have multiple clients that put messages in a queue managed by Camel AND
>> each client can receive as a reply many messages how can I do it with Camel?
>>
>> I mean suppose that I create an "out" queue where all replies go. How can I
>> be sure that a client can get ONLY its messages?
>>
>> Does Camel put the Principal (user authenticated) in the header of the
>> message?
>>
>> Is there a "standard" way that I have not found in the documentation?
>>
>> Thanks in advance for any reply!
>>
>> Mario
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5112517.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Re: Message level authentication

Posted by Filippo Balicchia <fb...@gmail.com>.
Hello,
Why don't use message selector from client point of view ?

--Filippo

Il 31 dicembre 2011 19:57, mgiammarco <mg...@gmail.com> ha scritto:
> Hello,
> if I have multiple clients that put messages in a queue managed by Camel AND
> each client can receive as a reply many messages how can I do it with Camel?
>
> I mean suppose that I create an "out" queue where all replies go. How can I
> be sure that a client can get ONLY its messages?
>
> Does Camel put the Principal (user authenticated) in the header of the
> message?
>
> Is there a "standard" way that I have not found in the documentation?
>
> Thanks in advance for any reply!
>
> Mario
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Message-level-authentication-tp5112517p5112517.html
> Sent from the Camel - Users mailing list archive at Nabble.com.