title: Securing JBoss, Part 1 link: https://onemoretech.wordpress.com/2008/10/23/securing-jboss-part-1/ author: lembobro description: post_id: 437 created: 2008/10/23 16:07:32 created_gmt: 2008/10/23 16:07:32 comment_status: open post_name: securing-jboss-part-1 status: publish post_type: post

This will be a two-parter, if only because I need to get the obvious stuff done first, before I can begin to research the tougher issues.

What I’ll cover here is securing the JBoss JMX and Web Consoles. The instructions for this are, more or less, found in the “Getting Started Guide” for the version of JBoss Application Server you are running, specifically in chapter 2, under heading 2.2.3 “Security Service”. In my case this was the doc for version 4.

In the text below $JBOSS_HOME is the directory into which JBoss has been installed, for example, /opt/jboss/jboss-4.0.3SP1. In my installations I usually make this the home directory for a system jboss user under whose account the jboss processes actually run.

While the documentation directs you to $JBOSS_HOME/server/default, in fact in many deployments the correct location is going to be $JBOSS_HOME/server/all, if only because the sample init scripts actually launch the application server from there. One reason for this is that “all” includes server features such as JAXR, IIOP, and clustering, while “default” does not. If in your case the server is being run out of “default”, be sure to change any path references below to reflect that.

There are two files that must be edited to secure the JMX Console.

There are both found under

$JBOSS_HOME/server/all/deploy/jmx-console.war/WEB-INF

First, edit jboss-web.xml to remove the comment around the security-domain attribute (comments are set out in these files as in standard HTML, any text surrounded by a <!-- and a \--> is considered commented out). It should then look like this:

`

<jboss-web>
    <security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>

`

Next, go into the web.xml file and remove the comments around the security-constraint block. It should then look like this:

`

<security-constraint>
  <web-resource-collection>
    <web-resource-name>HtmlAdaptor</web-resource-name>
     <description>
        An example security config that only allows users with the
        role JBossAdmin to access the HTML JMX console web application
     </description>
     <url-pattern>/*</url-pattern>
     <http-method>GET</http-method>
     <http-method>POST</http-method>
 </web-resource-collection>
 <auth-constraint>
   <role-name>JBossAdmin</role-name>
 </auth-constraint>
</security-constraint>

`

Once you’ve saved the changes to web.xml, jboss should redeploy the app so that you’ll get a login box when you open it in a new browser session.

Role definitions, user accounts and passwords are found in two other files. Both are under $JBOSS_HOME/server/all/conf/props. The jms-console-roles.properties file defines what privileges different roles carry, and the jmx-console-users.properties file contains the usernames and passwords (with the pattern being [username]:[password]. The server comes seeded with a user named “admin”, with the password “admin”. I usually change the password to something a little less obvious.

The Web Console is secured in much the same way. In this case the files are located under:

$JBOSS_HOME/server/all/deploy/management/console-mgr.sar/web-console.war/WEB-INF

The files, once again, are named jboss-web.xml and web.xml.

In jboss-web.xml, once again uncomment the line:

<security-domain>java:/jaas/jmx-console</security-domain>

Then go into the web.xml and remove the comment around the security-constraint block.

The role and user (username=password) definitions for the Web Console are located under $JBOSS_HOME/server/all/deploy/management/console-mgr.sar/web-console.war/WEB-INF/classes in web-console-roles.properties and web-console-users.properties, respectively. Again, I would at least change the password for the admin user from the default “admin”.

After making all these changes it’s a good idea to stop and then start jboss, making sure to leave a “decent interval” between for it to completely shut down.

Copyright 2004-2019 Phil Lembo