Hi Robbie, I think it is too late for M4 - Martin/Aidan can you comment ?
The MC release will be post M4 at any rate. Bfn, Marnie On Mon, Dec 8, 2008 at 4:28 AM, Robbie Gemmell <[EMAIL PROTECTED]>wrote: > 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: qpid-dev@incubator.apache.org > 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 > >
