qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell" <gemme...@dcs.gla.ac.uk>
Subject RE: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Date Mon, 08 Dec 2008 04:28:11 GMT
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.


-----Original Message-----
From: aidan.skinner@gmail.com [mailto:aidan.skinner@gmail.com] 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

On Wed, Dec 3, 2008 at 1:41 PM, Martin Ritchie <ritchiem@apache.org> 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
"Have we anything resembling a plan?" "Mm-hm. Ride till we find
them... and kill them all." - The 13th Warrior

View raw message