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 Java broker + management console JMX authentication
Date Tue, 02 Dec 2008 23:00:07 GMT
Hi all, I thought I would start a new thread on qpid-dev to discuss this, as there has been
a couple of fractured conversations about it on JIRA and on qpid-dev that I think could do
with consolidation to get everyone on the same page at the same time.

My commentary below is based on trunk + some patches I submitted, not all of which have been
committed yet, but the ones that haven’t merely fix issues while leaving things implemented
in mostly the same way it was already done.

The current situation as I understand it (feel free to correct me if I am misunderstanding

The broker (via JMXMangedObjectRegistry class) can currently start a JMXConnectorServer that
uses the RMIConnector shipped with the jvm which as configured is totally unauthenticated,
or if you supply the jmxremote_optional.jar and enable management security in the configuration
it can start a JMXConnectorServer which uses a JMXMPConnector that can perform either PLAIN
or CRAM-MD5(HASHED) SASL negotiation, picked depending on whether the principal database is
of the Plain or a Base64MD5 variety. As the JMXConnectorServers environment map can only specify
one callback handler and these are initialised depending on the type of principal database
in use it can only do one or the other and not both, preventing SASL profile negotiation between

When started without any flags the management console connects with using an unauthenticated
RMIConnector, or with -Dsecurity options being set at startup to either PLAIN or CRAM-MD5(HASHED)
will perform authentication across a JMXMPConnector using the jmxremote_optional.jar. It has
to be told which type of security as the JMXConnector's startup environment map only allows
supplying one callbackhandler and it needs to know whether it should be transmitting a hashed
password value or not, based on what the broker is going to expect(ie whether it is using
a Plain PD or Base64MD5 PD). As such, proper SASL profile negotiation between PLAIN and CRAM-MD5(HASHED)
currently cant occur as the console currently needs to know which type of PD the broker it
is connecting to is using.

The lack of authentication with the RMIConnector is what is causing the problems with QPID-1469
(https://issues.apache.org/jira/browse/QPID-1469), as there is no jmx user for it to return
so it NPE's which leads to breaking the jmxremote.access update process and then later prevents
the broker running if it is restarted. It also allows users access to the UserManagement section
whether they have admin rights or not, and although I havent checked, I think the whole console
in general whether they have any jmx rights at all.

How to move forward:

It is possible to authenticate a basic RMIConnector with plain text authentication (and optionally
SSL), the current implementation in the broker/console just doesnt do it. There are built
in utilities to do it, but they require direct access to a plain text user:password file.
Alternatively you can implement your own process using a JMXAuthenticator and specify it in
the connector server environment, so in qpids case it could use the PrincipalDatabase's to
function which would allow customising the approach depending on the type of PD was encountered,
allowing authentication regardless of PD type.

For SASL via JMXMP, if the RMIConnector is made capable of doing plain authentication it isn’t
really needed to do it again using JMXMP, so that could be scrapped and users would then have
a simple choice between plain authentication using an out of the box RMIConnector when using
either type of PD, or use a Base64MD5 PD and CRAM-MD5(HASHED) SASL authentication over JMXMP
by using the jmxremote_optional.jar addon. Security wouldn’t need to be forced on, and so
no one would need the optional jar unless they wanted CRAM-MD5 sasl jmx connnections.

An alternative is to integrate MX4J. Having now looked, it takes the JMXAuthenticator approach
to securing normal RMIConnector's and works by taking direct access to a username:password
file which can be either plain or have the passwords as base64 encoded MD5 or SHA-1 hashes.
It doesn’t implement the JMXMP connector yet, but does have alternative connectors in the
form of burlap, hessian, or soap over http(+ssl if desired) through use of Jetty etc.

Discuss :P


View raw message