Setting up RBAC on Red Hat AMQ Broker

One thing that is common in the enterprise world, especially in highly regulated industries, is to have separation of duties. Role-based access controls (RBAC) have built-in support for separation of duties. Roles determine what operations a user can and cannot perform. This post provides an example of how to configure proper RBAC on top of Red Hat AMQ, a flexible, high-performance messaging platform based on the open source Apache ActiveMQ Artemis project.

In most of the cases, separation of duties on Red Hat AMQ can be divided into three primary roles:

1. Administrator role, which will have all permissions
2. Application role, which will have permission to publish, consume, or produce messages to a specific address, subscribe to topics or queues, or create and delete addresses.
3. Operation role, which will have read-only permission via the web console or supported protocols

To implement those roles, Red Hat AMQ has several security features that need be configured, as described in the following sections.

AMQ Broker authentication

Out of the box, AMQ ships with the Java Authentication and Authorization Service (JAAS) security manager. It provides a default PropertiesLogin JAAS login module that reads user, password, and roles information from properties files (artemis-users.properties and artemis-roles.properties).

Thus, to add a user and role, we can use this artemis command:

// artemis user add --user <username> --password <password> --role <role_comma_seperated>

For example, to add three users and their roles—one user with the Administrator role, one user with the Application role, and one user with the Operation role—we can use an artemis command such as this:

$ artemis user add --user amqadmin --password amqadmin --role amqadmin
$ artemis user add --user amqapps --password amqapps --role amqapps
$ artemis user add --user amqops --password amqops --role amqops

On top of that, Red Hat AMQ also provides other authentication plugins. For more information, see the official documentation.

AMQ Broker authorization

AMQ Broker authorization policies provide a flexible, role-based security model for applying security to queues based on their respective addresses. For instance, operations such as publishing, consuming, and producing a message to an address as well as creating and deleting an address are supported out of the box. In addition, the policies support protocols such as AMQP, OpenWire, MQTT, STOMP, HornetQ, and the native Artemis Core protocol. To clarify, authorization policies are not meant for setting the permission of the web console.

To configure permissions, we can edit the broker.xml file in the etc folder. By default, it has eight different permissions per address pattern. Thus, to implement the above roles, we can use permissions like this:

<security-settings>
  <security-setting match="#">
    <permission type="createNonDurableQueue" roles="amqadmin,amqapps"/>
    <permission type="deleteNonDurableQueue" roles="amqadmin,amqapps"/>
    <permission type="createDurableQueue" roles="amqadmin,amqapps"/>
    <permission type="deleteDurableQueue" roles="amqadmin,amqapps"/>
    <permission type="createAddress" roles="amqadmin,amqapps"/>
    <permission type="deleteAddress" roles="amqadmin,amqapps"/>
    <permission type="consume" roles="amqadmin,amqapps"/>
    <permission type="browse" roles="amqadmin,amqapps,amqops"/>
    <permission type="send" roles="amqadmin,amqapps"/>
    <!-- we need this; otherwise ./artemis data imp wouldn't work -->
    <permission type="manage" roles="amqadmin,amqapps"/>
  </security-setting>
</security-settings>

Based on the example above, only users belonging to roles amqadminand amqapps have permission to do operations (send/consume/browse/manage messages) to an AMQ address (queue/topic) as well as create and delete queues. In contrast, users belonging to the amqops role have permission only to browse an address for monitoring purposes.

AMQ web console authorization

The web console in RedHat AMQ is based on Hawtio, which reads JMX operations using Jolokia. Therefore, to configure the permissions for the web console, we need to set the JMX permission. Specifically, it can be set through the management.xml file in the same folder as the broker.xml file (the etc folder). In short, to implement the primary roles described above, we can implement something like the following:

<role-access>
  <match domain="org.apache.activemq.artemis" >
    <access method="list*" roles="amqops,amqadmin"/>
    <access method="get*" roles="amqops,amqadmin"/>
    <access method="is*" roles="amqops,amqadmin"/>
    <access method="set*" roles="amqadmin"/>
    <access method="browse*" roles="amqops,amqadmin"/>
    <access method="create*" roles="amqadmin"/>
    <access method="delete*" roles="amqadmin"/>
    <access method="send*" roles="amqadmin"/>
    <access method="*" roles="amqadmin"/>
  </match>
</role-access>

To sum up, only users belonging to amqadmin have full permissions. However, amqops users have read-only permission to monitor the broker using the web console. Similarly, the amqapps role has no permission to use any JMX operation nor to log in through the web console.

Furthermore, the example above shows us that the method setting for a permission is actually a pattern for a JMX operation. It is important to realize that a role that is allowed to log in to the web console is read from the Java system property hawtio.role. Hence, we need to configure the etc/artemis.profile file as shown in the example below:

JAVA_ARGS=" -XX:+PrintClassHistogram -XX:+UseG1GC -XX:+AggressiveOpts 
-XX:+UseFastAccessorMethods 
-Xms512M -Xmx2G -Dhawtio.realm=activemq  
-Dhawtio.offline="true" -Dhawtio.role="amqadmin,amqops" 
-Dhawtio.rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal 
-Djolokia.policyLocation=${ARTEMIS_INSTANCE_ETC_URI}jolokia-access.xml 
-Djon.id=amq"

In the example configuration above, the only thing that needed to be changed is -Dhawtio.role="amqadmin,amqops", which specifies the roles (comma-delimited) that are allowed to log in.

Conclusion

By configuring the features described above, you can implement proper RBAC on top of Red Hat AMQ to improve security and enforce separation of duties. It is especially important to do this if you are in a highly regulated industry.

For more information on users and roles in Red Hat AMQ Broker, see the Users and Roles chapter of the Using AMQ Broker guide.