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:[EMAIL PROTECTED] Sent: 28 November 2008 11:30 To: [email protected] 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.
