When users want to enforce access control for the various JMX operations on the JMX Console,

it is not possible with the default setup (that relies on the security mandated by the

Servlet Specification).


To do this, a new feature has been added as of JBoss AS 3.2.8.SP2, JBoss AS 4.0.5 and JBoss AS 5.0:


On the JMX Console, we have various coarse-grained JMX operations possible with respect to

the implementation of the HtmlAdaptorServlet. These operation identifiers as passed through

the request are:







   updateAttributes - Operations that involve updation of jmx attributes


   invokeOp and invokeOpByName  - Operations that involve "invoke"




To apply access control to the JMX operations, please uncomment the filter in the web.xml

under deploy/jmx-console.war/WEB-INF

           <description>Comma-delimited Roles that define the JMX Operation denoting updation of Attributes</description>
           <description>Comma-delimited Roles that define the JMX Operation denoting Invocation of Operations</description>

What this basically means is that if an authenticated user needs to invoke operations (click the "Invoke" button), he needs to have the InvokeOpRole. If he wants to update the attributes (Click the "Apply Changes" button), he needs to have the updateAttributeRole. 

Note the roles defined in the filter config do not need to be defined in the web.xml because the generation of roles in the authenticated subject is a side-effect of the authentication process.




Note: The commented out filter definition does not exist in the web.xml if you run the installer.  In this case you can just paste the filter definition into the web.xml and configure as needed.


Note: Do not forget to activate the security domain in jboss-web.xml


Note: If the init params to the filter are left out, then all authenticated users to the jmx console will become read-only users.



As an example,


my conf/props/ contains:

 # A sample file for use with the UsersRolesLoginModule


my conf/props/ contains:

 # A sample file for use with the UsersRolesLoginModule


What this basically means is that the user called as "admin" will be able to click "Apply Changes" button in the jmx-console whereas the user "admin2" will be able to click "Invoke" button.


Untested feature (Authorization Delegate):

If the customer wants deeper access control, there is an untested feature applicable in the filter. This is the feature of plugging in Authorization Delegates. A delegate should have a default constructor available and a method with the following signature:

 public Boolean authorize(ServletRequest request, ServletResponse response, List listToCheck)


Here you can do any kind of authorization decision. To get the JMX operation identifier, do

 String action = request.getParameter("action");


When the authorization delegate is plugged in, it is the ultimate authority in decision making. The delegate can make use of external stores for its configuration (Database, Ldap etc) in making its authorization decisions.


To plugin the authorization delegate, add an init param to the filter as follows:

    <param-value>fully qualified name of your delegate</param-value>
    <description>Authorization Delegate</description>



the fully qualified name can be like com.mycompany.jmx.authorization.AuthorizationDelegate




invokeOp and invokeOpByName


The internals of the JMX console either invoke the operations by their name or by their index after calling getOperations() on the MBeanInfo

representation of the bean being invoked, the choice of which of these operation is used is entirely dependent on the page in the JMX console visited.



For the purpose of authorization both of these operations are considered equal and the list of roles configured for 'invokeOp' is the same list that is used for 'invokeOpByName'.



Use the official JBoss support channel or use the public forums.







Technical White Paper

Technical White Paper on Securing JMX