On 7/18/06, Kelly Campbell <[EMAIL PROTECTED]> wrote:
Thanks James,
I'm mentoring Sepand on this project within our company, so I'll try
to explain what we're trying to do. We want to use SSL client-side
certificates to provide the authentication mechanism rather than
user/pass or other authentication, so he is working to extend the SSL
transport to do that. We already have an existing system using this
for https web services style requests, and want to use the same
mechanism with ActiveMQ. Does this seem like a reasonable extension?
Sure, sounds good to me.
This kinda thing has come up a little in the past; I think we need to
add an extra field to the ConnectionInfo (the command sent to the
broker to 'login' a connection to the broker) so that we can support
alternative authentication mechanisms. e.g. to send along a passcode,
token, certificate or whatever as a parameter to the ConnectionInfo.
(To maintain backwards compatibility with the OpenWire format we could
maybe create a derivation of ConnectionInfo for use with SSO or SSL
based authentication).
I haven't had time to study the part of the code he's asking about in
depth, but it sounds like we are not sure that the JMSXUserId is
protected from spoofing. I will take a closer look based on your
reply.
Cool - there could possibly be a hole in there somewhere, so please do
double check. The contract of JMSXUserId should just be for the broker
to rubber stamp messages with the clientID of the
already-authenticated ConnectionInfo.
--
James
-------
http://radio.weblogs.com/0112098/
