Chapter 30. Security

This chapter describes how security works with JBoss Messaging and how you can configure it. To disable security completely simply set the security-enabled property to false in the jbm-configuration.xml file.

For performance reasons security is cached and invalidated every so long. To change this period set the property security-invalidation-interval, which is in milliseconds. The default is 10000 ms.

30.1. Role based security for addresses

JBoss Messaging contains a flexible role-based security model for applying security to queues, based on their addresses.

As explained in Chapter 6, Using Core, JBoss Messaging core consists mainly of sets of queues bound to addresses. A message is sent to an address and the server looks up the set of queues that are bound to that address, the server then routes the message to those set of queues.

JBoss Messaging allows sets of permissions to be defined against the queues based on their address. An exact match on the address can be used or a wildcard match can be used using the wildcard characters '#' and '*'.

Seven different permissions can be given to the set of queues which match the address. Those permissions are:

  • createDurableQueue. This permission allows the user to create a durable queue under matching addresses.

  • deleteDurableQueue. This permission allows the user to delete a durable queue under matching addresses.

  • createTempQueue. This permission allows the user to create a temporary queue under matching addresses.

  • deleteTempQueue. This permission allows the user to delete a temporarry queue under matching addresses.

  • send. This permission allows the user to send a message to matching addresses.

  • consume. This permission allows the user to consume a message from a queue bound to matching addresses.

  • manage. This permission allows the user to invoke management operations by sending management messages to the management address.

For each permission, a list of roles who are granted that permission is specified. If the user has any of those roles, he/she will be granted that permission for that set of addresses.

Let's take a simple example, here's a security block from jbm-configuration.xml or jbm-queues.xml file:

<security-setting match="globalqueues.europe.#">
    <permission type="createDurableQueue" roles="admin"/>
    <permission type="deleteDurableQueue" roles="admin"/>
    <permission type="createTempQueue" roles="admin, guest, europe-users"/>
    <permission type="deleteTempQueue" roles="admin, guest, europe-users"/>
    <permission type="send" roles="admin, europe-users"/>
    <permission type="consume" roles="admin, europe-users"/>
</security-setting>            
        

The '#' character signifies "any sequence of words". Words are delimited by the '.' character. For a full description of the wildcard syntax please see Chapter 11, Understanding the JBoss Messaging Wildcard Syntax. The above security block applies to any address that starts with the string "globalqueues.europe.":

Only users who have the admin role can create or delete durable queues bound to an address that starts with the string "globalqueues.europe."

Only users who have the admin role can create or delete durable queues bound to an address that starts with the string "globalqueues.europe."

Any users with the roles admin, guest, or europe-users can create or delete temporary queues bound to an address that starts with the string "globalqueues.europe."

Any users with the roles admin or europe-users can send messages to these addresses or consume messages from queues bound to an address that starts with the string "globalqueues.europe."

The mapping between a user and what roles they have is handled by the security manager. JBoss Messaging ships with a user manager that reads user credentials from a file on disk, and can also plug into JAAS or JBoss Application Server security.

For more information on configuring the security manager, please see Section 30.4, “Changing the security manager”.

There can be zero or more security-setting elements in each xml file. Where more than one match applies to a set of addresses the more specific match takes precedence.

Let's look at an example of that, here's another security-setting block:

<security-setting match="globalqueues.europe.orders.#">
    <permission type="send" roles="europe-users"/>
    <permission type="consume" roles="europe-users"/>
</security-setting>            
        

In this security-setting block the match 'globalqueues.europe.orders.#' is more specific than the previous match 'globalqueues.europe.#'. So any addresses which match 'globalqueues.europe.orders.#' will take their security settings only from the latter security-setting block.

Note that settings are not inherited from the former block. All the settings will be taken from the more specific matching block, so for the address 'globalqueues.europe.orders.plastics' the only permissions that exist are send and consume for the role europe-users. The permissions createDurableQueue, deleteDurableQueue, createTempQueue, deleteTempQueue are not inherited from the other security-setting block.

By not inheriting permissions, it allows you to effectively deny permissions in more specific security-setting blocks by simply not specifying them. Otherwise it would not be possible to deny permissions in sub-groups of addresses.

30.2. Secure Sockets Layer (SSL) Transport

When messaging clients are connected to servers, or servers are connected to other servers (e.g. via bridges) over an untrusted network then JBoss Messaging allows that traffic to be encrypted using the Secure Sockets Layer (SSL) transport.

For more information on configuring the SSL transport, please see Chapter 14, Configuring the Transport.

30.3. Basic user credentials

JBoss Messaging ships with a security manager implementation that reads user credentials, i.e. user names, passwords and role information from an xml file on the classpath called jbm-users.xml. This is the default security manager.

If you wish to use this security manager, then users, passwords and roles can easily be added into this file.

Let's take a look at an example file:

<configuration xmlns="urn:jboss:messaging" 
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:jboss:messaging ../schemas/jbm-users.xsd ">
    
    <defaultuser name="guest" password="guest">
        <role name="guest"/>
    </defaultuser>
    
    <user name="tim" password="marmite">
        <role name="admin"/>      
    </user>
    
    <user name="andy" password="doner_kebab">
        <role name="admin"/>
        <role name="guest"/>
    </user>
    
    <user name="jeff" password="camembert">
        <role name="europe-users"/>
        <role name="guest"/>
    </user>
    
</configuration>
        

The first thing to note is the element default-user. This defines what user will be assumed when the client does not specify a username/password when creating a session. In this case they will be the user guest and have the role also called guest. Multiple roles can be specified for a default user.

We then have three more users, the user tim has the role admin. The user andy has the roles admin and guest, and the user jeff has the roles europe-users and guest.

30.4. Changing the security manager

If you do not want to use the default security manager then you can specify a different one by editing the jbm-jboss-beans.xml file and changing the class for the JBMSecurityManager bean.

Let's take a look at a snippet from the default beans file:

           
<bean name="JBMSecurityManager" 
      class="org.jboss.messaging.core.security.impl.JBMSecurityManagerImpl">
    <start ignored="true"/>
    <stop ignored="true"/>
</bean>            
        

The class org.jboss.messaging.core.security.impl.JBMSecurityManagerImpl is the default security manager that reads used by the standalone server.

JBoss Messaging ships with two other security manager implementations you can use off-the-shelf; one a JAAS security manager and another for integrating with JBoss Application Sever security, alternatively you could write your own implementation by implementing the org.jboss.messaging.core.security.SecurityManager interface, and specifying the classname of your implementation in the jbm-jboss-beans.xml file.

These two implementations are discussed in the next two sections.

30.5. JAAS Security Manager

JAAS stands for 'Java Authentication and Authorization Service' and is a standard part of the Java platform. It provides a common API for security authentication and authorization, allowing you to plugin your pre-built implementations.

To configure the JAAS security manager to work with your pre-built JAAS infrastructure you need to specify the security manager as a JAASSecurityManager in the beans file. Here's an example:

<bean name="JBMSecurityManager" 
      class="org.jboss.messaging.integration.security.JAASSecurityManager">      
    <start ignored="true"/>
    <stop ignored="true"/>
    
    <property name="ConfigurationName">org.jboss.jms.example.ExampleLoginModule</property>
    <property name="Configuration">
       <inject bean="ExampleConfiguration"/>
    </property>
    <property name="CallbackHandler">
       <inject bean="ExampleCallbackHandler"/>
    </property>
</bean>            
        

Note that you need to feed the JAAS security manager with three properties:

  • ConfigurationName: the name of the LoginModule implementation that JAAS must use

  • Configuration: the Configuration implementation used by JAAS

  • CallbackHandler: the CallbackHandler implementation to use if user interaction are required

30.5.1. Example

See Section 9.1.17, “JAAS” for an example which shows how JBoss Messaging can be configured to use JAAS.

30.6. JBoss AS Security Manager

The JBoss AS security manager is used when running JBoss Messaging inside the JBoss Application server. This allows tight integration with the JBoss Application Server's security model.

The class name of this security manager is org.jboss.messaging.integration.security.JBossASSecurityManager

Take a look at one of the default jbm-jboss-beans.xml files for JBoss Application Server that are bundled in the distribution for an example of how this is configured.

30.7. Changing the Management Password for Clustering

In order for cluster connections to work correctly, each node in the cluster must register for management notifications from other nodes. To do this they must perform these actions as a user with a role that has admin permissions on the management addresses.

This password should always be changed from its default after installation. Please see Chapter 29, Management for instructions on how to do this.