AccessControlForJMXConsole

    Prerequisite

    http://wiki.jboss.org/wiki/Wiki.jsp?page=SecureTheJmxConsole

     

    Description

    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: 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:

     

     

    displayMBeans

     

      inspectMBean

     

       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

     <!--
           <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.

     

    Example:

    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>
    

     

    where

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

     

    Notes

     

    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'.

     

    Support/Questions:

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

     

     

     

     

     

    -


    Technical White Paper

    Technical White Paper on Securing JMX