JMS authentication in the embedded web-console

[Mario Siegenthaler <ma...@gmail.com>]

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

Re: JMS authentication in the embedded web-console

[Mario Siegenthaler <ma...@gmail.com>]

Just as an afterthought: I'll need the webconsole to allow only
non-modifying actions for a certain group of users. F.e. it should be
possible to view the contents of a queue but not to purge it.
While a solution to this is rather straightforward, namely to use the
JEE-role based security model (isUserInRole) it's not exactly
configuration friendly. We'd need some way to have a 'default' way
that doesn't check for anything.
Another way'd be to rely onto the activemq-security and let it decide
if a user may purge a queue or not. However this'll need to be able to
pass the user to activemq. Anyone running such a configuration?

Let me know what you think on this subject
Mario

On 6/25/07, Mario Siegenthaler <ma...@gmail.com> 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
>

Re: JMS authentication in the embedded web-console

[Tom Samplonius <to...@samplonius.org>]

  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 interfaces.


----- "Mario Siegenthaler" <ma...@gmail.com> 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