activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Security of the management interface
Date Thu, 26 May 2011 20:29:02 GMT
Ok I think this is all resolved now.

All the configuration <acl> elements now support <admin> and <monitor>
access configuration elements.
The monitoring access level allows you to access management actions
which don't modify the broker state, while the admin access level also
grants you access to change the broker state such as killing

If a a resource such as a Queue does not have an acl defined it will
used the acl defined in the virtual host to figure out who can access
the resource. If the acl in the virtual host is not defined, then it
will use the acl list configured on the broker.

We are clearing out the password fields in the runtime configuration
which is access with this URL:
That is a version of the configuration which the broker was started
and has all property place holder variables resolved.

Now if you access:
That gives you the raw configuration file as it exists on disk without
any variable substitution performed.

So if you store passwords in the file, then they will get transmitted.
 But, you really should not be storing passwords in the clear on disk
anyways so you should replace those with property placeholders as
described at:



Connect at CamelOne May 24-26
The Open Source Integration Conference

On Tue, May 17, 2011 at 2:14 AM, Lionel Cons <> wrote:
> Hiram,
> First of all, thanks for starting to document the management interface. I
> hope you will add the missing bits (e.g. get/update apollo.xml, shutdown the
> broker...) soon.
> Here are some security related comments.
> Since credentials will be given in clear to the management interface (HTTP
> basic authentication), Apollo should support SSL encryption for it.
> The current authorization scheme (allow users defined in broker.admin to do
> everything) is not fine grain enough. At minimum, there should be the
> possibility to have two different accesses: read-only (only get information
> without changing the broker state) and read-write (such as restarting the
> broker, changing its configuration, deleting a queue...). Note that the
> broker configuration is very sensitive since it may contain clear text
> passwords (e.g. <key_storage>) and security settings (who is allowed to do
> what).
> Maybe the management interface should have its own fine grain access control
> (a bit like httpd) so that one can specify at the URL level who can do what?
> The management interface will probably be extended to include what the
> ActiveMQ web console provides today. If this is the case, actions such as
> browsing a queue, inspecting a message, sending a message, etc. should be
> controlled by the same per destination ACLs used by the STOMP access.
> Cheers,
> Lionel

View raw message