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
<[EMAIL PROTECTED]> 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
