Jboss Admin Tutorial: Security on JBoss

We will explore each one of these in turn

Security is a fundamental part of any enterprise application. You need to be able to restrict who is allowed to access your applications and control what operations application users may perform.

Element <login-config> configures the login method for the secured resource.

In this case we just use HTTP BASIC authentication, but other options for JBoss are: DIGEST, FORM, and CLIENT-CERT. We will cover some of these later.

Database Login Module depends on our ability to set up (and link to) a JBoss-managed DataSource (database connection pool).

term#> mysql/bin/mysql -u root -p
mysql> CREATE DATABASE Authority;
mysql> USE Authority;
mysql> CREATE TABLE Users (Username VARCHAR(32) NOT NULL PRIMARY KEY,Password VARCHAR(32) NOT NULL);
mysql> CREATE TABLE Roles (Username VARCHAR(32) NOT NULL,Rolename VARCHAR(32) NOT NULL,PRIMARY KEY (Username, Rolename));
mysql> GRANT SELECT ON Authority.* TO authority@localhost IDENTIFIED BY "authsecret";

INSERT INTO Users VALUES ("john", "secret");
INSERT INTO Roles VALUES ("john", "MyRole");
INSERT INTO Users VALUES ("bob", "abc123");
INSERT INTO Roles VALUES ("bob", "MyRole");
INSERT INTO Roles VALUES ("bob", "Manager");
INSERT INTO Users VALUES ("mike", "passwd");
INSERT INTO Roles VALUES ("mike", "Manager");
INSERT INTO Roles VALUES ("mike", "Admin");

For example, run the following from within ${jboss.server.home.url} directory:

keytool -genkey -keystore conf/ssl.ks  -storepass secret
        -alias tomcat -keyalg RSA -keypass secret
What is your first and last name?
  [Unknown]:  localhost
What is the name of your organizational unit?
  [Unknown]:  IT
What is the name of your organization?
  [Unknown]:  Secure Org
What is the name of your City or Locality?
  [Unknown]:  San Francisco
What is the name of your State or Province?
  [Unknown]:  CA
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=localhost, OU=IT, O=Secure Org, L=San Francisco, ST=CA, C=US correct?
  [no]:  yes

Refer to http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html for more info.

If you change the port to 443 (or any other port number), make sure that you also set redirectPort="443" in both the non-SSL HTTP and AJP connector elements.

See http://tomcat.apache.org/tomcat-6.0-doc/config/http.html for additional <Connector> options.

When starting up JBoss AS, the console should print the following lines:

...
14:41:01,002 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080
14:41:02,195 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8443
...

When you point your browser to http://localhost:8443/status you will get a browser warning telling you that the SSL certificate has not been signed by a certification authority that you trust. This is expected, since we signed our own certificate. Skipping the warning should show the SSL-protected page (pad-lock).

To filter clients by their source IP see Section 16.2, “Filtering Clients by Source”

To implement authentication and authorization (Section 16.3, “Authentication & Authorization”):

To add support for SSL (Section 16.8, “Configuring JBoss AS for SSL”):

	Note
	JBM_USER and JBM_ROLE tables have been created by the JMSUserManager component when we have set up the persistence to use MySQL.

First, declare a new security domain in the conf/login-config.xml file in your server configuration set folder:

<policy>
  ...
  <application-policy name="JMSRealm">
    <authentication>
      <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule"
        flag="required">
         <module-option name="dsJndiName">java:/MySqlDS</module-option>

                 <module-option name="principalsQuery">
                   SELECT passwd FROM jbm_user WHERE user_id=?
                 </module-option>

                 <module-option name="rolesQuery">
                   SELECT role_id, 'Roles' FROM jbm_role WHERE user_id=?
                 </module-option>
      </login-module>
    </authentication>
  </application-policy>
  ...
</policy>

Then, add the security domain you just created to the configuration of JBM security store that you can find in the deploy/messaging/messaging-jboss-beans.xml:

<bean name="SecurityStore" class="org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore">
  ...
  <property name="securityDomain">JMSRealm</property> <!--  -->
  ...
</bean>

Create now a secured Topic:

<mbean code="org.jboss.jms.server.destination.TopicService"
  name="jboss.messaging.destination:service=Topic,name=securedTopic"
  xmbean-dd="xmdesc/Topic-xmbean.xml">
  <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
  <depends>jboss.messaging:service=PostOffice</depends>

  <!--  -->
  <attribute name="SecurityConfig">
    <security>
          <role name="publisher" read="true" write="true"/>
    </security>
  </attribute>
</mbean>

	Note
	The publisher role has been automatically added by the persistence service at table creation. One user that has the publisher role is also created (user_id: dynsub , passwd: dynsub)

Finally, If a developer want to use the secured connection for this Topic:

connection = cf.createConnection("dynsub","dynsub");

We will examine each of these in turn.

Creating low-privileged users for system services is a common practice on Unix/Linux environments. On Windows, JBoss AS would typically be configured to run with a default System account. Also, Windows does not have a concept of privileged ports like Unix/Linux systems.

Other users should in particular have no access to ${jboss.server.config.url} and ${jboss.server.home.url}/deploy directories as these often contain sensitive information like database or SSL-certificate passwords.

Although supported by NTFS, file system security is often not employed to secure system services like JBoss AS under Windows.

In deploy/jmx-invoker-adaptor-server.sar/META-INF/jboss-service.xml (JBoss 3.2.x) or deploy/jmx-invoker-service.xml (JBoss 4.x and JBoss 5.x) under ${jboss.server.home.url}, uncomment the following:

<!-- Uncomment to require authenticated users
<descriptors>
  <interceptors>
    <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
  </interceptors>
</descriptors>
-->

By default, the security domain java:/jaas/jmx-console authenticates against file default/conf/props/jmx-console-users.properties This file is in <user>=<password> format. Roles are not important.

To specify the username and password for twiddle or shutdown scripts, use -u <user> -p <password> command-line switches.

Requiring authentication and authorization for jmx-console:

Requiring authentication and authorization for web-console:

Restart JBoss for the changes to take effect.

To disable remote access to Hypersonic DB:

To enable, edit $JBOSS_HOME/bin/run.conf and add to JAVA_OPTS: * -Djava.security.manager and * -Djava.security.policy=<policy-file>

Enabling the security manager is easy. The hard part is to come up with a suitable security policy. To enable all permissions, start with security.policy:

grant {
  permission java.security.AllPermission;
};

To figure out which permissions you need, you can debug the security manager. Run java -Djava.security.debug=help to see a list of debugging options. Using -Djava.security.debug=all in JAVA_OPTS is the most verbose (probably too verbose), whereas setting java.security.debug to access,failure may be sufficient to determine a suitable security policy.

Listening ports in default configuration:

Additional listening ports in all configuration: