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 connections.
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: /broker/config/runtime.json That is a version of the configuration which the broker was started and has all property place holder variables resolved. Now if you access: /broker/config 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: http://activemq.apache.org/apollo/documentation/user-manual.html#Encrypting_Passwords_in_the_Configuration Regards, Hiram FuseSource Web: http://fusesource.com/ Connect at CamelOne May 24-26 The Open Source Integration Conference On Tue, May 17, 2011 at 2:14 AM, Lionel Cons <[email protected]> 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 >
