Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]

[Robbie Gemmell <ge...@dcs.gla.ac.uk>]

The only issue I see with using MX4J is it needs direct access to the
password file to use its PasswordAuthenticator (a JMXAuthenticator)for
standard RMIConnector based connections (its RMIConnector JSR160
implementation is entirely compatible with Suns, so it doesnt do
anything the JDK wont already let you do yourself). As far as I see,
that results in it needing to know which type of PD the file represents
and once again restricting what the console can send it for verification
to a value matching the PD type unless you implement your own
JMXauthenticator, in which case why use MX4J at all there. Implementing
a JMXAuthenticator for qpid could defer that to the principal databases
and so the MC wouldnt need to know what type was being used, it could
just send a hashed (or unhashed)value and the authenticator would deal
with it according to the type of PD in use. Although, as Martin has been
raising in other JIRA's the console could simply try both ways before
declaring a failure, as proposed for determining a SASL profile with the
JMXMPConnector.

non-RMI based connectors are where MX4J becomes useful and interesting
for qpid IMO.

On Wed, 2008-12-03 at 13:41 +0000, Martin Ritchie wrote:
> 2008/12/2 Robbie Gemmell <ge...@dcs.gla.ac.uk>:
> > 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 anything):
> >
> > 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 PLAIN and CRAM-MD5(HASHED).
> >
> > 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
> >
> > Robbie
> >
> 
> 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
> connection. This may be over thinking this to much purely for the Java
> broker and if we had a shippable authentication solution that would
> suffice. If we need something more control-able then perhaps the C++
> management exchange approach would better suit.
> 
> I've got a few JIRAs to raise in this space so will do this now and
> perhaps they will also stimulate discussion.
> 
> Martin
> 

Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]

[Martin Ritchie <ri...@apache.org>]

2008/12/3 Robbie Gemmell <ge...@dcs.gla.ac.uk>:
> The only issue I see with using MX4J is it needs direct access to the
> password file to use its PasswordAuthenticator (a JMXAuthenticator)for
> standard RMIConnector based connections (its RMIConnector JSR160
> implementation is entirely compatible with Suns, so it doesnt do
> anything the JDK wont already let you do yourself). As far as I see,
> that results in it needing to know which type of PD the file represents
> and once again restricting what the console can send it for verification
> to a value matching the PD type unless you implement your own
> JMXauthenticator, in which case why use MX4J at all there. Implementing
> a JMXAuthenticator for qpid could defer that to the principal databases
> and so the MC wouldnt need to know what type was being used, it could
> just send a hashed (or unhashed)value and the authenticator would deal
> with it according to the type of PD in use. Although, as Martin has been
> raising in other JIRA's the console could simply try both ways before
> declaring a failure, as proposed for determining a SASL profile with the
> JMXMPConnector.
>
> non-RMI based connectors are where MX4J becomes useful and interesting
> for qpid IMO.

Would it be possible to modifiy the PasswordAuthenticator to use a
PrincipalDatabase? Having a standard RMI connector sounds like a good
approach, that way things like the CLI and JMX Console don't need to
have additional special jars.

That said if we want to have authentication negotiation then we will
probably need to have something special on the client side so an extra
jar isn't that much to worry about.

I'd just like to keep it as simple for an end users as possible. The
current editing of startup files and adding jars is not exactly user
friendly.

I'd vote for any solution that can allow:

1) Single command to start to use with all broker variations.
    - Allowing one instance to talk to all flavours of the broker.
2) Ability to handle current and potential future authentication mechanisms
3) Ability to use SSL connections
     - on top of authentication choice.
     - as an authentication mechanism.

Martin

> On Wed, 2008-12-03 at 13:41 +0000, Martin Ritchie wrote:
>> 2008/12/2 Robbie Gemmell <ge...@dcs.gla.ac.uk>:
>> > 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 anything):
>> >
>> > 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 PLAIN and CRAM-MD5(HASHED).
>> >
>> > 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
>> >
>> > Robbie
>> >
>>
>> 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
>> connection. This may be over thinking this to much purely for the Java
>> broker and if we had a shippable authentication solution that would
>> suffice. If we need something more control-able then perhaps the C++
>> management exchange approach would better suit.
>>
>> I've got a few JIRAs to raise in this space so will do this now and
>> perhaps they will also stimulate discussion.
>>
>> Martin
>>
>



-- 
Martin Ritchie