You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2008/11/18 16:21:44 UTC
[jira] Created: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
-----------------------------------------------------------------------
Key: QPID-1469
URL: https://issues.apache.org/jira/browse/QPID-1469
Project: Qpid
Issue Type: Bug
Components: Java Management : JMX Console
Affects Versions: M4
Reporter: Martin Ritchie
Attachments: QPID-1469-NPE-AMQUMMBean.log
Summary:
Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
Set Rights
Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Robbie Gemmell <ge...@dcs.gla.ac.uk>.
Need to check but I think I am wrong about that, if there is no
JMXAuthenticator set on the broker end it probably wont care if the MC sends
it the credentials anyway, as it wont bother checking them.
Not a big deal anyway, the other changes (auto negotiation) to that area of
the MC can be made easily without the rmi authentication changes as they are
only a few lines and so will be easily added at any time.
-----Original Message-----
From: Robbie Gemmell
<snip>
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.
</snip>
Robbie
Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Dec 8, 2008 at 10:41 AM, Martin Ritchie <ri...@apache.org> wrote:
> 2008/12/8 Aidan Skinner <ai...@apache.org>:
>> On Mon, Dec 8, 2008 at 10:11 AM, Marnie McCormack
>> <ma...@googlemail.com> wrote:
>>
>>> I think it is too late for M4 - Martin/Aidan can you comment ?
>>
>> It depends on the patch, although I think it's probably too late.
>>
>> TBH I think we should just dump the Base64MD5 stuff altogether and
>> reccomend everybody use plain, it's more hassle than it's worth.
>
> Agreed though it would be good to get QPID-1502 sorted at the same
> time so we don't loose the abilty to use the MC to remotely manage
> passwords.
Yeah, probably something for M4+1.
- 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
Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Martin Ritchie <ri...@apache.org>.
2008/12/8 Aidan Skinner <ai...@apache.org>:
> On Mon, Dec 8, 2008 at 10:11 AM, Marnie McCormack
> <ma...@googlemail.com> wrote:
>
>> I think it is too late for M4 - Martin/Aidan can you comment ?
>
> It depends on the patch, although I think it's probably too late.
>
> TBH I think we should just dump the Base64MD5 stuff altogether and
> reccomend everybody use plain, it's more hassle than it's worth.
Agreed though it would be good to get QPID-1502 sorted at the same
time so we don't loose the abilty to use the MC to remotely manage
passwords.
Martin
> - 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
>
--
Martin Ritchie
RE: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Robbie Gemmell <ge...@dcs.gla.ac.uk>.
I have attached the mentioned patches in their complete and current form to
QPID-1469 and QPID-1511 respectively.
Getting rid of the Base64MD5 stuff would certainly make life simpler.
...as would someone fixing the annoying [Message not scanned] tag on my
email subjects, its been weeks now, grr support :)
Robbie
-----Original Message-----
From: aidan.skinner@gmail.com [mailto:aidan.skinner@gmail.com] On Behalf Of
Aidan Skinner
Sent: 08 December 2008 10:15
To: qpid-dev@incubator.apache.org
Subject: Re: Java broker + management console JMX authentication[MESSAGE NOT
SCANNED]
On Mon, Dec 8, 2008 at 10:11 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> I think it is too late for M4 - Martin/Aidan can you comment ?
It depends on the patch, although I think it's probably too late.
TBH I think we should just dump the Base64MD5 stuff altogether and
reccomend everybody use plain, it's more hassle than it's worth.
- 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
Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Dec 8, 2008 at 10:11 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> I think it is too late for M4 - Martin/Aidan can you comment ?
It depends on the patch, although I think it's probably too late.
TBH I think we should just dump the Base64MD5 stuff altogether and
reccomend everybody use plain, it's more hassle than it's worth.
- 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
Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ge...@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 <ri...@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
>
>
RE: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by Robbie Gemmell <ge...@dcs.gla.ac.uk>.
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 <ri...@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
Re: Java broker + management console JMX authentication
Posted by Aidan Skinner <ai...@apache.org>.
On Wed, Dec 3, 2008 at 1:41 PM, Martin Ritchie <ri...@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
Re: Java broker + management console JMX authentication[MESSAGE NOT SCANNED]
Posted by 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
Re: Java broker + management console JMX authentication[MESSAGE
NOT SCANNED]
Posted by 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
Posted by Martin Ritchie <ri...@apache.org>.
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
Java broker + management console JMX authentication
Posted by 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
RE: [jira] Commented: (QPID-1469) AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user[MESSAGE NOT SCANNED]
Posted by Robbie Gemmell <ge...@dcs.gla.ac.uk>.
Could do, although the issue there is that MX4J doesnt implement the JMXMP
connector and instead have its own connectors based on soap, hessian, or
burlap which all require Jetty or such like to communicate via http, so that
means adding that too on broker and console sides.
-----Original Message-----
From: aidan.skinner@gmail.com [mailto:aidan.skinner@gmail.com] On Behalf Of
Aidan Skinner
Sent: 01 December 2008 10:19
To: qpid-dev@incubator.apache.org
Subject: Re: [jira] Commented: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid
user[MESSAGE NOT SCANNED]
On Mon, Dec 1, 2008 at 1:24 AM, Robbie Gemmell <ge...@dcs.gla.ac.uk>
wrote:
> One issue with making it on by default is that everyone will need to
download the jmxremote_optional.jar and add it to the classpath to start the
broker, even for testing...which I believe is the reason it was turned off
by default in the first place, I recall seeing it in a commit message when
scouring the backlog previously.
We should probably integrate MX4J (http://mx4j.sourceforge.net/)
instead, this is what Tomcat, Geronimo etc use. The OpenDMK stuff
seems to still be propreitary, although it's a little hard to tell if
that's intentional or not.
- 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
Re: [jira] Commented: (QPID-1469) AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Dec 1, 2008 at 1:24 AM, Robbie Gemmell <ge...@dcs.gla.ac.uk> wrote:
> One issue with making it on by default is that everyone will need to download the jmxremote_optional.jar and add it to the classpath to start the broker, even for testing...which I believe is the reason it was turned off by default in the first place, I recall seeing it in a commit message when scouring the backlog previously.
We should probably integrate MX4J (http://mx4j.sourceforge.net/)
instead, this is what Tomcat, Geronimo etc use. The OpenDMK stuff
seems to still be propreitary, although it's a little hard to tell if
that's intentional or not.
- 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
RE: [jira] Commented: (QPID-1469) AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by Robbie Gemmell <ge...@dcs.gla.ac.uk>.
One issue with making it on by default is that everyone will need to download the jmxremote_optional.jar and add it to the classpath to start the broker, even for testing...which I believe is the reason it was turned off by default in the first place, I recall seeing it in a commit message when scouring the backlog previously.
Regardless, it is probably worth maintaining the ability to connect with a normal RMIConnector based jmx client when needed, which will require putting a fix in place for this issue, and possibly addressing the current ability of an unauthenticated RMIConnector based client to get access to the usermanagement area/mbean (which is a result of the rmiconnector server being started directly using the mbeanserver, whereas the security enabled jmxmp based connector server deals with an MBeanInvocationHandlerImpl mbeanserverforwarder proxy which checks the user credentials).
Without taking the usermanagement access issue into account, one fix would simply be making the AMQUserManagementMBean.getCurrentJMXUser() method handle the unathenticated rmi situation by returning the equivalent of "unathenticated user", preventing the abortive jmxremote.access file update that currently occurs and later results in the broker being unable to start. An alternative would be to modify the JMXManagedObjectRegistry's use of the rmiconnector server to be authenticated, giving the getCurrentJMXUser() something to retrieve and allowing use of the MBeanInvocationHandlerImpl proxy to fix the usermanagement access issue as well. The former is obviously a little hackish and no more secure than it is now, whereas the latter will require implementation of a JAAS JMXAuthenticator (http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/JMXAuthenticator.html ) and is complicated by the choice between plain and hashed principal database files just like the jmxmp based connection is, which requires the management console to know which type of database the broker is using so that its sasl callback handler knows what to do.
-----Original Message-----
From: Marnie McCormack (JIRA) [mailto:qpid-dev@incubator.apache.org]
Sent: 28 November 2008 11:30
To: qpid-dev@incubator.apache.org
Subject: [jira] Commented: (QPID-1469) AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user[MESSAGE NOT SCANNED]
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651527#action_12651527 ]
Marnie McCormack commented on QPID-1469:
----------------------------------------
Discussed, think once QPID-794 fixed we should force authentication on with broker. We don't really have a scenario where this doesnot apply even in dev. MR to raise other JIRAs to cover changes required please ? Thanks vm.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652425#action_12652425 ]
Martin Ritchie commented on QPID-1469:
--------------------------------------
I hadn't realised that the <security> and jmxremote_optional jar were required for authentication to take place. I thought plain text authentication was going on.
We really do need to get authentication going over JMX, using something Apache friendly like, mx4j from sourceforge.net would be ideal.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner reassigned QPID-1469:
-----------------------------------
Assignee: Martin Ritchie (was: Aidan Skinner)
-> Martin for review
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch, QPID-1469_test_style_fix_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Robert Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Gemmell updated QPID-1469:
---------------------------------
Attachment: QPID-1469_8dec2008.patch
Hi Martin, this patch (QPID-1469_8dec2008.patch) will take care of the NPE causing the issue when unauthenticated users utilize the method.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Robert Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Gemmell updated QPID-1469:
---------------------------------
Attachment: QPID-1469_test_9dec2008.patch
Test patch for the previous patch. uses there deleteUser() method to show the failure and its correction.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie resolved QPID-1469.
----------------------------------
Resolution: Fixed
Fix Version/s: M4
This change is looks good to me.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: M4
>
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch, QPID-1469_test_style_fix_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Robert Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650356#action_12650356 ]
Robert Gemmell commented on QPID-1469:
--------------------------------------
Using a broker with configured to use management security with CRAM-MD5 authentication I was able to successfully create users, delete users, and set rights, as can be seen from the modified jmxremote.access file contents below:
#Generated by AMQUserManagementMBean Console : Last edited by user:robbie
#Mon Nov 24 22:15:02 GMT 2008
admin=readonly
robbie=admin
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Robert Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Gemmell updated QPID-1469:
---------------------------------
Attachment: QPID-1469_test_style_fix_9dec2008.patch
In my haste to get the patch submitted for the RC I forgot to make sure the test's coding style was correct.
QPID-1469_test_style_fix_9dec2008.patch corrects the numerous style issues.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch, QPID-1469_test_style_fix_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651527#action_12651527 ]
Marnie McCormack commented on QPID-1469:
----------------------------------------
Discussed, think once QPID-794 fixed we should force authentication on with broker. We don't really have a scenario where this doesnot apply even in dev. MR to raise other JIRAs to cover changes required please ? Thanks vm.
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-1469:
------------------------------------
Assignee: Aidan Skinner (was: Martin Ritchie)
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Aidan Skinner
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch, QPID-1469_test_style_fix_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner updated QPID-1469:
--------------------------------
Status: Ready To Review (was: In Progress)
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Aidan Skinner
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch, QPID-1469_test_style_fix_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Robert Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650392#action_12650392 ]
Robert Gemmell commented on QPID-1469:
--------------------------------------
Using a broker configured with PLAIN authenticated management security (using the patches i provided) gives mixed results. It is not able to create or delete user accounts, or view the user accounts. It is however still able to set user rights successfully, so it would appear that the AMQUserManagementMBean.getCurrentJMXUser() method does still work, although something else isnt when using PLAIN.
Using no security/authentication, upon attempting to set rights the broker leave only the .tmp and .old jmxremote.access files and thus will fail to lad on restart, as you reported. I do not see an NPEoutput though, is it being caught elsewhere?
I see from your log that you were using the RMIConnector when creating the log, ie without management security enabled. No username/password is transmitted to the broker when 'logging in' with the security disabled (the MC merely mandates you type something, it doesnt do anything with it though unless you use security), so it is perhaps not surprising it should return a null value for the current jmx user in such a case?
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack reassigned QPID-1469:
--------------------------------------
Assignee: Martin Ritchie
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-1469:
-----------------------------------
Fix Version/s: (was: M4)
Eclipse MC M5
Affects Version/s: (was: M4)
Sscoping items for early 2009 release of Java Eclipse Mgt Console
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Reporter: Martin Ritchie
> Assignee: Martin Ritchie
> Fix For: Eclipse MC M5
>
> Attachments: QPID-1469-NPE-AMQUMMBean.log, QPID-1469_8dec2008.patch, QPID-1469_test_9dec2008.patch, QPID-1469_test_style_fix_9dec2008.patch
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-1469:
---------------------------------
Attachment: QPID-1469-NPE-AMQUMMBean.log
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-1469)
AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
Posted by "Robert Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650425#action_12650425 ]
Robert Gemmell commented on QPID-1469:
--------------------------------------
Just had another peek at it now before going to bed (or more likely, watching some TV)...looking at the PlainPasswordPrincipleDatabase, ahhhh so that would be why none of the above things worked using PLAIN, //denied or //todo :)
> AMQUserManagementMBean.getCurrentJMXUser no longer returns a valid user
> -----------------------------------------------------------------------
>
> Key: QPID-1469
> URL: https://issues.apache.org/jira/browse/QPID-1469
> Project: Qpid
> Issue Type: Bug
> Components: Java Management : JMX Console
> Affects Versions: M4
> Reporter: Martin Ritchie
> Attachments: QPID-1469-NPE-AMQUMMBean.log
>
>
> Summary:
> Currently when the password and jmxremote.access files are updated the current username is written in to the file as an audit trail.
> This used to work fine however we are now seeing a NullPointerException when performing any updates such as:
> Set Rights
> Delete User
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.