qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack" <marnie.mccorm...@googlemail.com>
Subject Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Date Mon, 08 Dec 2008 10:11:17 GMT
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 <gemmellr@dcs.gla.ac.uk>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: 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
> SCANNED]
>
> 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
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message