Mmm, had a closer look...still not sure it's quite right, though I may be totally missing something :)
I can see its reasonable for AMQP related stuff to use one principal database and management stuff to use another, obviously...but here we have 2 broker management related areas that work together in establishing and controlling jmx connections, but can potentially be using different principal databases. Looking more closely at the methods in AMQUserManagementMBean, it treats the existence of a user/password in the PD it uses as being very related to the contents of the jmxremote.access file used to determine what people can do in the management console. All the create/delete/set rights methods in AMQUserManagementMBean update the jmxremote.access file in accordance to the contents of or any changes they make in the PD AMQUserManagementMBean is using. However, if that is not the same PD that JMXManagedObjectRegistry is using, then the rights AMQUserManagementMBean alters or checks in jmxremote.access have no relevance to the user details that exist in the PD JMXManagedObjectRegistry, which are what is being used to authenticate the management console connections in the first place and are the user details the jmxremote.access file is used to check rights for by the MBeanInvocationHandlerImpl proxy. That doesn't make sense to me, if the idea is to be able to split management authentication off entirely from other authentication it doesnt work as-is, and it also opens a possible hole in the management rights/authentication system... For example, I add 2 Base64MD5 PDs to the config in such a way that the 2 areas will use different PDs (setting the broker.security.jmx.principal-database element to the second Base64MD5 PD achieves this, there are lots of other ways of course). I then log in with user details held in the first PD that JMXManagedObjectRegistry is using, and rights held in jmxremote.access. I add a new user with <whatever> rights using AMQUserManagementMBean through the console and it would create those user details in the principal database AMQUserManagementMBean is using and assign those rights in jmxremote.access. As far as connecting with a management console goes I would still be unable to as the PD that JMXManagedObjectRegistry is using still wouldn't know those user details...unless of course the username happened to coincide with someone else's username in the other PD, in which case they now have unintended management access no matter what their password is, oops. The reverse is also an issue, if I delete an account with AMQUserManagementMBean using one PD, the JMXManagedObjectRegistry would still happily let me connect if my details match those in the PD that it is using, as they haven't been deleted...but my jmxremote.access rights will have been deleted, which might be a problem. So I still think that JMXManagedObjectRegistry should be picking its PD based on the broker.security.jmx.principal-database element from the configuration file, as AMQUserManagementMBean does. If not, id say there are other issues to address. Well thats a far bigger email than I originally intended...but I loathe to trim it down, so if you made it this far, sorry :) Robbie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aidan Skinner Sent: 01 December 2008 09:32 To: [email protected] Subject: Re: JMXManagedObjectRegistry and AMQUserManagementMBean can potentially use different PrincipalDatabases[MESSAGE NOT SCANNED] On Mon, Dec 1, 2008 at 2:47 AM, Robbie Gemmell <[EMAIL PROTECTED]> wrote: > Noticed something earlier when playing with different database types. The > JMXManagedObjectRegistry and AMQUserManagementMBean classes related to the > JMX management features dont use the same terms of selection/assignment for > the PrincipalDatabase they should use, and so can potentially use different > databases. This would result in management console connections being > authenticated through one principal database, and the console's > usermanagement capabilities modifying a different principal database. Is > that by design (eg, allowing JMX management specific accounts??) or is it > option number 2, a bug ? Thought id enquire to make sure before cluttering > the JIRA J This by design. Admin rights and AMQP rights are different concepts. > AMQUserManagementMBean has its principal database set according to the > broker.security.jmx.principal-database element from the configuration file, > and is set at startup by the ConfigurationFilePrincipalDatabaseManager > .initialisePrincipalDatabase() method, just before the > JMXManagedObjectRegistry is created, which itself acquires a list of all the > principal databases from the application registry and loops through them, > selecting either the first Base64MD5PasswordFilePrincipalDatabase it finds, > or if it find none then uses the last PlainPasswordFilePrincipalDatabase it > encounters. I've always thought that this was a rather weird way of doing it, we should clean that up and make it more obvious. - Aidan -- Apache Qpid - World Domination through Advanced Message Queueing http://cwiki.apache.org/qpid "Have we anything resembling a plan?" "Mm-hm. Ride till we find them... and kill them all." - The 13th Warrior
