activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelly Campbell" <>
Subject Re: Creating a secure connection system and using JMSXUserID support
Date Tue, 18 Jul 2006 03:15:39 GMT
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?

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


On 7/17/06, James Strachan <> wrote:
> On 7/17/06, Sepand M <> wrote:
> > Hi,
> >
> > I'm trying to modify ActiveMQ so it can handle SSL connections
> FWIW we already support SSL connections...
> in particular...
> > and
> > authorize access to different queues based on client IDs.
> We have a security plugin to perform authentication and authorization
> on specific destinations, details here...
> > I've been looking at your "JMSXUserID support" (
> > to see if it
> > could be used for authentication once the connection has been
> > established.
> So the purpose of the JMSXUserID feature is to be able to add a header
> to all JMS messages that leave a broker so that consumers receiving
> the message can know the authenticated user ID who sent the message.
> i.e. it means that a producer cannot spoof its userID when sending a
> message.
> JMSXUserID does not perform the actual authentication/authorization -
> thats a feature of the security plugin I mentioned above.
> > From what I see, using the BrokerService.setPopulateJMSXUserID(true);
> > causes the BrokerService to use a UserIDBroker, which in turn uses the
> > ConnectionContext to retreive the userID.
> >
> > The problem I see is that the connection context is set in
> > AbstractConnection.processMessage, which uses the producerId received
> > from the message, which has been send by the producer (and is not
> > validated by the server).
> > This, to me, means that if the producer manages to guess a correct
> > producerId, it will have impersonated another producer.
> >
> > Is this true?
> The clientID is the thing we use; something the client can generate
> itself. Though we ensure that only 1 connection that is active has a
> single clientID value at any point in time (so no client can pretend
> to be another one - its also required by the JMS spec). So I don't
> think it matters too much what the producerId is - unless I've
> misunderstood your point
> --
> James
> -------

View raw message