Securing JBoss messaging

This topic describes about securing JBoss messaging.

Note: The following information references JMS queues. If you use JMS topics for JMS messaging, follow similar security recommendations.

Note: The sample configuration provided, using JBoss Messaging version 4.3, is an example for illustration purposes only. The sample is by no means exhaustive or optimal. There are other approaches to securing message queue, each with its own strengths and weaknesses. Since message queueing software is provided by third party vendors, we strongly encourage you to discuss your approach to hardening or securing message queues with JBoss messaging specialists. Products can evolve; hence, processes for hardening them might change over time. If you have any problems with the processes discussed here, we ask you work with JBoss directly. You should use the following recommendations as a starting point and customize the configuration for your specific operating environment.

Configuring JBoss queue security

JBoss has two different JMS options. In version 4.2 of JBoss, the server software shipped with a JMS feature known as JBoss MQ. However, in Release 4.3, the JMS offering was revamped to improve performance and to provide additional features. The new JMS feature is called JBoss Messaging.

Note: This document assumes you have installed the JBoss Messaging package. These instructions will not work with JBoss MQ.

Install JBoss Messaging with the following ant release script to create a queue called testQueue. To verify that the messaging installation was successful, look at:

JBOSS_HOME/server/messaging/deploy/jboss-messaging.sar/destination-service.xml

<mbean code="org.jboss.jms.server.destination.QueueService" 
  name="jboss.messaging.destination:service=Queue,name=testQueue" xmbean-
  dd="xmdesc/Queue-xmbean.xml"> 
  <depends optional-attribute-name="ServerPeer">
  jboss.messaging:service=ServerPeer</depends>
  <depends>jboss.messaging:service=PostOffice</depends> 
  <attribute name="SecurityConfig">
    <security>
      <role name="guest" read="true" write="true"/> 
      <role name="publisher" read="true" write="true" create="false"/> 
      <role name="noacc" read="false" write="false" create="false"/>
    </security> 
  </attribute>
</mbean>

If you are using the out-of-the-box JBOSS configuration that was installed from these steps, you can start the new server:

JBOSS_HOME/bin/run.sh -b 0 -c messaging

Configuring queue security in JBoss

As shown in the XML snippet above, the destination-service.xml Queue definition contains a SecurityConfig element that defines what activities can be performed by a role or group. The users and groups are defined in JBOSS_HOME/server/messaging/conf/props/messaging-roles.properties.

Note: If you chose to configure messaging for a different server name, replace "messaging" in the user and role property file paths with the name of the server you configured.

The following is an example:

#
# user=role1,role2,...
guest=guest
vinay=vinay
noacc=noacc

The user and passwords are defined in JBOSS_HOME/server/messaging/conf/props/messaging-users.properties:

#
# user=password
guest=guest
vinay=vinay
noacc=noacc

At this point, you have defined user authentication to the JBoss queues.

Configuring JBoss messaging to use SSL

The first step is to set up the keystore. The messaging package includes a sample keystore and truststore. You can use this keystore or you can create your own. In either case, copy the keystore to the JBOSS_HOME/server/servername/conf/ directory.

These will be referenced from the SSL Bisocket configuration xml (see Enabling the SSL Bisocket Transport in this topic).

Adding a secure connection factory

In the directory JBOSS_HOME/server/servername/deploy/, create a new xml file called messaging-secure-socket-service.xml. A sample of this file is included with the JBoss messaging installation package in the location examples/secure-socket/etc/messaging-secure-socket-service.xml.

This file should have the following contents:

<?xml version="1.0" encoding="UTF-8"?> 
<!--     
Secure Socket Transport Example: the deployment descriptor for the 
secure socket factory service, secure connector and secure connection factory. 
$Id: messaging-secure-socket-service.xml 2773 2007-06-12 13:31:30Z cvs_login $
 -->
<server>
  <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
    name="jboss.messaging.destination:service=SecureConnectionFactory" xmbean-
    dd="xmdesc/ConnectionFactory-xmbean.xml">
  <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer
  </depends>
  <depends optional-attribute-name="Connector">jboss.messaging:service=
  Connector,transport=sslbisocket</depends>
  <attribute name="JNDIBindings"> <bindings>
  <binding>/SecureConnectionFactory</binding> </bindings>
  </attribute>
  </mbean>
</server>

Enabling the SSL bisocket transport

In the directory JBOSS_HOME/server/servername/deploy/, create a new xml file called remoting-sslbisocket-service.xml. A sample of this file is included with the JBoss messaging installation package in the location examples/config/remoting-sslbisocket-service.xml.

In the event that you are using your own keystore with a different filename or password, edit the file to point to the keystore and password you have chosen. The path of the keystore appears to be relative to the JBOSS_HOME/server/servername/conf directory.

<?xml version="1.0" encoding="UTF-8"?> 
<!--     
  The deployment descriptor for the secure socket factory service and secure 
    connector.
    $Id: remoting-sslbisocket-service.xml 3409 2007-12-04 21:32:54Z cvs_login $
--> 
<server>
  <mbean code="org.jboss.remoting.transport.Connector"          
    name="jboss.messaging:service=Connector,transport=sslbisocket" display-
    name="SSL Bisocket Transport Connector">
  <attribute name="Configuration">
    <config>
      <invoker transport="sslbisocket">
        <!-- There should be no reason to change these parameters - warning!
          Changing them may stop JBoss Messaging working correctly -->
  <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat
  </attribute>
  <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat
  </attribute>
  <attribute name="dataType" isParam="true">jms</attribute>
  <attribute name="socket.check_connection" isParam="true">false</attribute>
  <attribute name="timeout" isParam="true">0</attribute>
  <attribute 
  name="serverBindAddress">${jboss.bind.address}</attribute>
  <attribute name="serverBindPort">5457</attribute>               
  <attribute name="clientSocketClass" 
    isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper
  </attribute>
  <attribute 
    name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrap
    per</attribute>
  <attribute 
    name="serverSocketFactory">jboss.messaging:service=ServerSocketFactory,
    type=SSL</attribute>
  <attribute name="numberOfCallRetries" isParam="true">1</attribute>
  <attribute name="pingFrequency" isParam="true">214748364</attribute>
  <attribute name="pingWindowFactor" 
    isParam="true">10</attribute>
  <attribute 
    name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool<
    /attribute>
  <!-- End immutable parameters -->
                              
  <!-- Periodicity of client pings. Server window by default is twice this 
    figure -->                               
  <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
  <!-- Number of seconds to wait for a connection in the client pool to 
    become free -->
  <attribute name="numberOfRetries" isParam="true">10</attribute>
  <!-- Max Number of connections in client pool. This should be 
    significantly higher than
  the max number of sessions/consumers you expect -->
  <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute>
  <!-- Use these parameters to specify values for binding and connecting 
    control connections to work with your firewall/NAT configuration
  <attribute name="secondaryBindPort">xyz</attribute> <attribute 
    name="secondaryConnectPort">abc</attribute> -->
 </invoker>
 <handlers>
    <handler 
      subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandle
      r</handler>
    </handlers>
    </config>      
</attribute>
  <depends>jboss.messaging:service=ServerSocketFactory,type=SSL</depends>
</mbean>
<!-- This section is for custom (SSL) server socket factory  -->   
<!--        
    The server socket factory mbean to be used as attribute to socket invoker 
      (see serverSocketFactory attribute above for where it is used). This 
      service provides the exact same API as the ServerSocketFactory, so can be
      set as an attribute of that type on any
    MBean requiring an ServerSocketFactory.
   -->
   <mbean code="org.jboss.remoting.security.SSLServerSocketFactoryService"
     name="jboss.messaging:service=ServerSocketFactory,type=SSL" display-name="SSL 
     Server Socket Factory">
     <depends optional-attribute-name="SSLSocketBuilder" proxy-
       type="attribute">jboss.messaging:service=SocketBuilder,type=SSL</depends>
   </mbean>
   <!--
     This service is used to build the SSL Server socket factory. This will be 
       where all the store/trust information will be set. If do not need to make 
       any custom configurations, no extra attributes need to be set for the 
       SSLSocketBuilder and just need to set the javax.net.ssl.keyStore and 
       javax.net.ssl.keyStorePassword system properties. This can be done by just 
       adding something like the following to the run script for JBoss (this one is 
       for run.bat):
     set JAVA_OPTS=-Djavax.net.ssl.keyStore=.keystore -
       Djavax.net.ssl.keyStorePassword=opensource %JAVA_OPTS%
     Otherwise, if want to customize the attributes for SSLSocketBuilder, will need 
       to uncomment them below.
   -->
   <mbean code="org.jboss.remoting.security.SSLSocketBuilder"
     name="jboss.messaging:service=SocketBuilder,type=SSL" display-name="SSL Server 
     Socket Factory Builder">
   <!-- IMPORTANT - If making ANY customizations, this MUST be set to false.
     Otherwise, will used default settings and the following attributes will be
     ignored. -->
   <attribute name="UseSSLServerSocketFactory">false</attribute>
   <!-- This is the url string to the key store to use -->
   <attribute name="KeyStoreURL">messaging.keystore</attribute>
   <!-- The password for the key store -->
   <attribute name="KeyStorePassword">secureexample</attribute>
   <!-- The password for the keys (will use KeystorePassword if this is not set
     explicitly. -->
   <attribute name="KeyPassword">secureexample</attribute>
   <!-- The protocol for the SSLContext. Default is TLS. -->
   <attribute name="SecureSocketProtocol">TLS</attribute>
      <!-- The algorithm for the key manager factory.  Default is SunX509. -->
      <attribute name="KeyStoreAlgorithm">SunX509</attribute>
      <!-- The type to be used for the key store.
        Defaults to JKS. Some acceptable values are JKS (Sun's keystore format),
         JCEKS (Java Cryptography Extension keystore - More secure JKS), and PKCS12 
         (Public-Key Cryptography Standards #12 keystore - Keystore - version of
         RSA's Personal Information Exchange Syntax Standard). These are not case 
         sensitive.
      -->
      <attribute name="KeyStoreType">JKS</attribute>
   </mbean> 
</server>

Once you have completed these steps, you can restart your server. Thereafter, you can use the connection factory SecureConnectionFactory. It will require you to set up your client to use SSL to connect to the JMS queues.