You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by David Jencks <da...@yahoo.com> on 2008/11/14 20:04:33 UTC
Connector 1.6 security import context and AMQ
One of the new features of the proposed connector (j2ca) 1.6 spec is
the SecurityImportContext that allows inbound connectors (to mdbs) to
supply the security identity that the mdb will run under. I started
writing support for this in the geronimo j2ca component and have been
wondering how amq might take advantage of this new capability.
From my limited research I think that amq security currently only
directly supports authenticating and authorizing access to connections
and destinations, but not messages. This doesn't seem too interesting
for the j2ca security import context since the only identity available
is the one configured to get the connection the inbound messages are
delivered over. Since this is configured on the receiving server, you
might just as well configure the unauthenticated subject for the mdb
directly and skip the import step.
Lets back up a bit and consider the identities that might be
associated with a message....
1. the message was originally sent by someone.
2. At each step of message processing there's a server that is sending
the message and a server that is receiving the message.
2.a when the message is originally created (1) and (2) might be the
same identity. Similarly when the message is finally consumed they
might be the same identity.
As I mentioned, IIUC currently amq security only considers (2) and
discards (1) as soon as the message gets to the first broker. I think
the security inflow is only going to be interesting if (1) is used as
the source of the imported security identity; this would require
including some info about the identity with the message.
Does this analysis make sense?
Would anyone find this useful if it was implemented and easy to use?
How would I go about implementing this?
Just in case the above is a bit too abstract to actually understand
what I'm thinking about :-)...
Lets suppose there are a bunch of clients that originate messages, and
each are supplied with a certificate identifying themselves. Messages
would get the certificate attached (I'm sidestepping the question of
how at the moment) so after going through a routing network of 15 or
20 brokers the mdb that finally consumed the message would have the
original client authenticated automatically by the framework and use
this identity for authorization. (of course the brokers could also
use this info.... but unless they are using mdbs I'm not concerned at
the moment about how).
many thanks
david jencks
Re: Connector 1.6 security import context and AMQ
Posted by Hiram Chirino <hi...@hiramchirino.com>.
How about JMSXContentSignature or something like that. JMS spec
reserves the use of properties that start with JMSX for provider
implementation purposes. Therefore it should not conflict with end
user app properties.
Regards,
Hiram
On Fri, Nov 21, 2008 at 3:41 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Nov 21, 2008, at 10:58 AM, Hiram Chirino wrote:
>
>> Sound interesting.
>>
>> I would recommend just having a producer attach a signature of the
>> message body to a well known message property. The inflow code could
>> inspect to see that property is set, and if so, then verify the
>> signature. I'm guessing you get 2 things from this.. #1 is you get
>> the identity of the sender, and #2 that at least the body content was
>> not tampered with.
>>
>> The nice thing about that is you can then just implement on top of the
>> existing system (i.e. old clients can participate) and we can enhance
>> the next version of the client to auto sign, and auto do signature
>> checks in the JMS client libary so it's more transparent to the user.
>> Client would just need to pass in the cert info to the Connection
>> Factory.
>>
>> What do you think?
>
> I like this a lot! Do you have a suggestion for what the "well known
> message property" should be?
>
> thanks
> david jencks
>
>>
>>
>> On Fri, Nov 14, 2008 at 2:04 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>> One of the new features of the proposed connector (j2ca) 1.6 spec is the
>>> SecurityImportContext that allows inbound connectors (to mdbs) to supply
>>> the
>>> security identity that the mdb will run under. I started writing support
>>> for this in the geronimo j2ca component and have been wondering how amq
>>> might take advantage of this new capability.
>>>
>>> From my limited research I think that amq security currently only
>>> directly
>>> supports authenticating and authorizing access to connections and
>>> destinations, but not messages. This doesn't seem too interesting for
>>> the
>>> j2ca security import context since the only identity available is the one
>>> configured to get the connection the inbound messages are delivered over.
>>> Since this is configured on the receiving server, you might just as well
>>> configure the unauthenticated subject for the mdb directly and skip the
>>> import step.
>>>
>>> Lets back up a bit and consider the identities that might be associated
>>> with
>>> a message....
>>>
>>> 1. the message was originally sent by someone.
>>> 2. At each step of message processing there's a server that is sending
>>> the
>>> message and a server that is receiving the message.
>>> 2.a when the message is originally created (1) and (2) might be the same
>>> identity. Similarly when the message is finally consumed they might be
>>> the
>>> same identity.
>>>
>>> As I mentioned, IIUC currently amq security only considers (2) and
>>> discards
>>> (1) as soon as the message gets to the first broker. I think the
>>> security
>>> inflow is only going to be interesting if (1) is used as the source of
>>> the
>>> imported security identity; this would require including some info about
>>> the
>>> identity with the message.
>>>
>>> Does this analysis make sense?
>>>
>>> Would anyone find this useful if it was implemented and easy to use?
>>>
>>> How would I go about implementing this?
>>>
>>> Just in case the above is a bit too abstract to actually understand what
>>> I'm
>>> thinking about :-)...
>>>
>>> Lets suppose there are a bunch of clients that originate messages, and
>>> each
>>> are supplied with a certificate identifying themselves. Messages would
>>> get
>>> the certificate attached (I'm sidestepping the question of how at the
>>> moment) so after going through a routing network of 15 or 20 brokers the
>>> mdb
>>> that finally consumed the message would have the original client
>>> authenticated automatically by the framework and use this identity for
>>> authorization. (of course the brokers could also use this info.... but
>>> unless they are using mdbs I'm not concerned at the moment about how).
>>>
>>> many thanks
>>> david jencks
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Connector 1.6 security import context and AMQ
Posted by David Jencks <da...@yahoo.com>.
On Nov 21, 2008, at 10:58 AM, Hiram Chirino wrote:
> Sound interesting.
>
> I would recommend just having a producer attach a signature of the
> message body to a well known message property. The inflow code could
> inspect to see that property is set, and if so, then verify the
> signature. I'm guessing you get 2 things from this.. #1 is you get
> the identity of the sender, and #2 that at least the body content was
> not tampered with.
>
> The nice thing about that is you can then just implement on top of the
> existing system (i.e. old clients can participate) and we can enhance
> the next version of the client to auto sign, and auto do signature
> checks in the JMS client libary so it's more transparent to the user.
> Client would just need to pass in the cert info to the Connection
> Factory.
>
> What do you think?
I like this a lot! Do you have a suggestion for what the "well known
message property" should be?
thanks
david jencks
>
>
> On Fri, Nov 14, 2008 at 2:04 PM, David Jencks
> <da...@yahoo.com> wrote:
>> One of the new features of the proposed connector (j2ca) 1.6 spec
>> is the
>> SecurityImportContext that allows inbound connectors (to mdbs) to
>> supply the
>> security identity that the mdb will run under. I started writing
>> support
>> for this in the geronimo j2ca component and have been wondering how
>> amq
>> might take advantage of this new capability.
>>
>> From my limited research I think that amq security currently only
>> directly
>> supports authenticating and authorizing access to connections and
>> destinations, but not messages. This doesn't seem too interesting
>> for the
>> j2ca security import context since the only identity available is
>> the one
>> configured to get the connection the inbound messages are delivered
>> over.
>> Since this is configured on the receiving server, you might just as
>> well
>> configure the unauthenticated subject for the mdb directly and skip
>> the
>> import step.
>>
>> Lets back up a bit and consider the identities that might be
>> associated with
>> a message....
>>
>> 1. the message was originally sent by someone.
>> 2. At each step of message processing there's a server that is
>> sending the
>> message and a server that is receiving the message.
>> 2.a when the message is originally created (1) and (2) might be the
>> same
>> identity. Similarly when the message is finally consumed they
>> might be the
>> same identity.
>>
>> As I mentioned, IIUC currently amq security only considers (2) and
>> discards
>> (1) as soon as the message gets to the first broker. I think the
>> security
>> inflow is only going to be interesting if (1) is used as the source
>> of the
>> imported security identity; this would require including some info
>> about the
>> identity with the message.
>>
>> Does this analysis make sense?
>>
>> Would anyone find this useful if it was implemented and easy to use?
>>
>> How would I go about implementing this?
>>
>> Just in case the above is a bit too abstract to actually understand
>> what I'm
>> thinking about :-)...
>>
>> Lets suppose there are a bunch of clients that originate messages,
>> and each
>> are supplied with a certificate identifying themselves. Messages
>> would get
>> the certificate attached (I'm sidestepping the question of how at the
>> moment) so after going through a routing network of 15 or 20
>> brokers the mdb
>> that finally consumed the message would have the original client
>> authenticated automatically by the framework and use this identity
>> for
>> authorization. (of course the brokers could also use this info....
>> but
>> unless they are using mdbs I'm not concerned at the moment about
>> how).
>>
>> many thanks
>> david jencks
>>
>>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
Re: Connector 1.6 security import context and AMQ
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Sound interesting.
I would recommend just having a producer attach a signature of the
message body to a well known message property. The inflow code could
inspect to see that property is set, and if so, then verify the
signature. I'm guessing you get 2 things from this.. #1 is you get
the identity of the sender, and #2 that at least the body content was
not tampered with.
The nice thing about that is you can then just implement on top of the
existing system (i.e. old clients can participate) and we can enhance
the next version of the client to auto sign, and auto do signature
checks in the JMS client libary so it's more transparent to the user.
Client would just need to pass in the cert info to the Connection
Factory.
What do you think?
On Fri, Nov 14, 2008 at 2:04 PM, David Jencks <da...@yahoo.com> wrote:
> One of the new features of the proposed connector (j2ca) 1.6 spec is the
> SecurityImportContext that allows inbound connectors (to mdbs) to supply the
> security identity that the mdb will run under. I started writing support
> for this in the geronimo j2ca component and have been wondering how amq
> might take advantage of this new capability.
>
> From my limited research I think that amq security currently only directly
> supports authenticating and authorizing access to connections and
> destinations, but not messages. This doesn't seem too interesting for the
> j2ca security import context since the only identity available is the one
> configured to get the connection the inbound messages are delivered over.
> Since this is configured on the receiving server, you might just as well
> configure the unauthenticated subject for the mdb directly and skip the
> import step.
>
> Lets back up a bit and consider the identities that might be associated with
> a message....
>
> 1. the message was originally sent by someone.
> 2. At each step of message processing there's a server that is sending the
> message and a server that is receiving the message.
> 2.a when the message is originally created (1) and (2) might be the same
> identity. Similarly when the message is finally consumed they might be the
> same identity.
>
> As I mentioned, IIUC currently amq security only considers (2) and discards
> (1) as soon as the message gets to the first broker. I think the security
> inflow is only going to be interesting if (1) is used as the source of the
> imported security identity; this would require including some info about the
> identity with the message.
>
> Does this analysis make sense?
>
> Would anyone find this useful if it was implemented and easy to use?
>
> How would I go about implementing this?
>
> Just in case the above is a bit too abstract to actually understand what I'm
> thinking about :-)...
>
> Lets suppose there are a bunch of clients that originate messages, and each
> are supplied with a certificate identifying themselves. Messages would get
> the certificate attached (I'm sidestepping the question of how at the
> moment) so after going through a routing network of 15 or 20 brokers the mdb
> that finally consumed the message would have the original client
> authenticated automatically by the framework and use this identity for
> authorization. (of course the brokers could also use this info.... but
> unless they are using mdbs I'm not concerned at the moment about how).
>
> many thanks
> david jencks
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com