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
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: http://jira.jboss.com/jira/browse/JBAS-3311
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
<!-- <filter> <filter-name>JmxOpsAccessControlFilter</filter-name> <filter-class>org.jboss.jmx.adaptor.html.JMXOpsAccessControlFilter</filter-class> <init-param> <param-name>updateAttributes</param-name> <param-value>UpdateAttributeRole</param-value> <description>Comma-delimited Roles that define the JMX Operation denoting updation of Attributes</description> </init-param> <init-param> <param-name>invokeOp</param-name> <param-value>InvokeOpRole</param-value> <description>Comma-delimited Roles that define the JMX Operation denoting Invocation of Operations</description> </init-param> </filter> <filter-mapping> <filter-name>JmxOpsAccessControlFilter</filter-name> <servlet-name>HtmlAdaptor</servlet-name> </filter-mapping> -->
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/jmx-console-users.properties contains:
# A sample users.properties file for use with the UsersRolesLoginModule admin=admin admin2=admin
my conf/props/jmx-console-roles.properties contains:
# A sample roles.properties file for use with the UsersRolesLoginModule admin=JBossAdmin,HttpInvoker,UpdateAttributeRole admin2=JBossAdmin,HttpInvoker,InvokeOpRole
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:
<init-param> <param-name>authorizationDelegate</param-name> <param-value>fully qualified name of your delegate</param-value> <description>Authorization Delegate</description> </init-param>
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.