activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Connector 1.6 security import context and AMQ
Date Fri, 21 Nov 2008 20:41:27 GMT

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  
> <david_jencks@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


Mime
View raw message