activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Samplonius <>
Subject Re: JMS authentication in the embedded web-console
Date Tue, 26 Jun 2007 02:24:17 GMT

  It would kind of cool if the Web Console could pass its username and password through to
JMS.  This assumes of course that Web Console has been setup with BASIC auth.  But that is
a fair assumption, because if your destinations are password protected, your webconsole is
likely also protected.

  I actually played around a bit with having Jetty use ActiveMQ's JAAS plugin.  I never finished
testing it, but it should work.  In this case, everything should just work, and there would
be unified auth for all of the protocols.

  Of course, JMX is always an option, instead of JMS.  If the Web Console queueBrowser used
JMX, it would work just fine.  I can browse the queue fine with JConsole, so I know JMX works.
 And since everything that Web Console uses is otherwise JMX, this kind of makes sense (at
least it would be consistent).

  I guess it would also be a good idea to document that a JMX read-only user can read any
destination.  And a JMX write user can write to any destination.  So JMX auth trumps ActiveMQ
destination auth.  Which is fair, since an JMX user can shut the JVM down too.

  I guess the ActiveMQ.Agent is more thorny.  I don't really understand this issue.  ActiveMQ.Agent
is an internal topic, like the advisory topics, so why is ActiveMQ crashing on start when
destination security is defined?  Is this even worth fixing?  If the Web Console had a page
that showed queue subscribers, I don't think you'd need both.  Maybe just leave the ActiveMQ.Agent
disabled by default.  I'd prefer one 100% working interface, rather than two partially broken

----- "Mario Siegenthaler" <> wrote:
> Hi
> Tom pointed out the problem with the web console and a secured
> JMS-connection. While it's already possible to configure that over
> JNDI and straightforward to make that configurable via
> system-properties, this will be an issue for the in-vm jetty, that's
> started with the broker. We'd require the user to set a user/password
> to connect to the invm-broker. IMO this is quite a hassle (the same
> thing is true for the console, this thing in fact kills the broker
> because it can't startup because it gets a invalid username/password
> exception).
> The easiest thing'd be to allow vm:// connections without checking
> for
> username/password. The problem with this approach is certainly that
> the policy check on the queues/topics'd have to be ignored.
> Any thoughts on this topic? I'll be happy to write a patch as soon as
> I know the way we want to go.
> Mario

View raw message