I have been looking into this a bit more...I did type an email back on Wednesday only for it to go *poof* as the client crashed when I hit send...I was rather ill at the time (so that made me feel much better, not :P) and in the middle of a couple large pieces of work so I never got time to send it again, but that was perhaps a good thing as ive spent more time reading about it since :)
I haven't found any reference to a JMXConnector other than JMXMP which uses SASL for the authentication mechanism. Everything else seems to rely on the built in functionality or custom implementations thereof, both of which use the simple JMXAuthenticator interface to secure the connector (it consists of giving a user/pass string array to the jmxconnector on creation in the client, and it calling an 'authenticate' method in the JMXAuthenticator specified in the JMXConnector creation on the broker, with it either returning the verified Subject to JAAS or throwing a SecurityException). I decided to have a play in that field too and have made a JMXAuthenticator implementation for qpid which uses the principal databases to verify the user details, with the MC sending the entered user:pass unaltered and the broker either comparing directly if its a PlainPD or taking an MD5 hash if its a Base64MD5 PD and comparing with the stored value (could/should do the opposite, have the MC send a hash and then hash the stored PlainPD password for comparison). With that working, as well as addressing QPID-1511, the QPID-1469 getCurrentJMXUser() issue with corrupting the jmxremote.access file and preventing broker restart goes away (I also patched it separately to address the root NPE causing it, and I think that at least needs to go into M4 if nothing else does) as the users are now authenticated, eliminating the issue causing the NPE. With the authentication in place I also modified the RMIConnectorServer the broker starts to be proxied by MBeanInvocationHandlerImpl like the JMXMP connector server is, meaning that users connecting via RMI are now subject to the jmx user rights system unlike previously where they had full access no matter their jmx rights (if they even had any, which they didn't need to but do now in order to connect at all). The next things to look at in this area are SSL (which is an easy enough add), and making the console auto negotiate what connector and/or sasl profile its using automatically (QPID-1506). I finished (perhaps the wrong order, but hey :P) by taking a look at what Tomcat and Geronimo do. According to the documentation, Tomcat appears to use the built in utilities for authentication, ie specify a user:password and access files in the appropriate properties and let the RMI JMXConnector take care of it from there with the functionality built into JDK 5+6, and optionally using the HTTP Adapter from MX4J to allow proxying it to http. Geronimo offers both secure and insecure connectors, having acquired ssl support as of v2.1.2 in August, although the secure one is off by default and you have to leave the insecure one running in either case at the moment to support some of the functionality. It doesn't really specify jmx authentication, although id assume it to be similar to Tomcat. Now the sticky bit - is it too late for any of this (except the QPID-1469 mini-patch, which is merely an if statement and I think rather needed if nothing else makes it) to be put in M4? If it doesn't go in M4 then it cant really go in the MC until after its proposed future release, otherwise it won't work with M4 unless using the JMXMP connector. Robbie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aidan Skinner Sent: 04 December 2008 14:51 To: [email protected] Subject: Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED] On Wed, Dec 3, 2008 at 1:41 PM, Martin Ritchie <[EMAIL PROTECTED]> wrote: > From a brief look at the JMXRemote specification > (http://www.ece.uic.edu/~cpress/jmx/jmx_remote-1_0-fr-specJSR-000160.pdf) > my favoured approach would be to see what MX4J has to offer but we > should look do some form of protocol negotiation. So we can more > easily decide what authentication we wish to perform over the I feel quite strongly that whatever we choose to do is a) secure and b) transparent to the user. They shouldn't care about things like password file format on the broker, this is clearly insane. I would like to see a solution using SASL that allows/requires us to connect over SSL. SSL + either SASL/PLAIN or x509 certificate verification would be my ideal. - 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
