Chapter 6. Security
AMQ Broker 7 provides transport layer security to secure incoming network connections, and authorization to secure access to queues based on their respective addresses. In both of these areas, the security model is very similar to AMQ 6. However, the configuration processes are different.
6.1. How Transport Layer Security is Configured
Like AMQ 6, AMQ Broker 7 enables you to secure incoming network connections using SSL/TLS. However, there are some differences in configuration syntax and configuration properties.
In AMQ 6, transport layer security was configured by creating an SSL context to define the keystores and truststores, and then adding SSL attributes to each transport connector that you wanted to secure.
In AMQ Broker 7, the transport layer is based on Netty, which uses SSL natively. This means that to configure transport layer security, you just add the necessary SSL attributes to each acceptor that you want to secure. You do not need to add a separate SSL context.
For example, the following configuration accepts secure connections from an OpenWire client:
In AMQ 6
Define the SSL context in the
INSTALL_DIR/etc/activemq.xmlfile:<sslContext> <sslContext keyStore="file:${activemq.conf}/broker.ks" keyStorePassword="password"/> </sslContext>In the broker configuration file, create a transport connector to accept secure connections from the OpenWire client:
<transportConnector name="ssl" uri="ssl://localhost:61617?transport.needClientAuth=true"/>
In AMQ Broker 7
In the
BROKER_INSTANCE_DIR/etc/broker.xmlconfiguration file, create or update an acceptor to accept secure connections from the OpenWire client:<acceptor name="netty-ssl-acceptor">tcp://localhost:61617?sslEnabled=true;keyStorePath=${data.dir}/../etc/broker.ks;keyStorePassword=password;needClientAuth=true</acceptor>
You can configure either one-way or two-way TLS. The following table describes these methods:
| Method | Description |
|---|---|
| One-way TLS | Only the broker presents a certificate. This method requires you to have a Java KeyStore for the server-side certificates. For more information, see Securing connections in Configuring AMQ Broker. |
| Two-way TLS (mutual authentication) | Both the broker and the client present certificates. This method requires you to have a Java KeyStore for the server-side certificates, and a TrustStore that holds the keys of the clients that the broker trusts. For more information, see Securing connections in Configuring AMQ Broker. |
To reuse your existing keystores and truststores for AMQ Broker 7, copy them to your AMQ Broker 7 broker instance.
Related Information
- For a full list of all transport layer security configuration properties, see Netty TLS Parameters in Configuring AMQ Broker.
6.2. Authorization
AMQ Broker 7 provides a role-based security model in which you apply security settings to queues based on their addresses. This security model is similar to AMQ 6; however, the permissions and wildcard syntax are different, and authorization is configured differently.
6.2.1. Authorization Changes
AMQ Broker 7 uses a different set of permissions and a slightly different wildcard syntax than AMQ 6.
The following table describes the different types of permissions that you can apply in AMQ 6 and AMQ Broker 7:
| Permission in AMQ 6 | Corresponding Permissions in AMQ Broker 7 |
|---|---|
|
|
|
|
|
|
|
|
|
For more information about permissions in AMQ Broker 7, see Configuring user- and role-based authorization in Configuring AMQ Broker.
The wildcard syntax for matching addresses is also different in AMQ Broker 7.
| To… | In AMQ 6 | In AMQ Broker 7 |
|---|---|---|
| Separate words in the path |
|
|
| Match a single word |
|
|
| Match any word recursively |
|
|
6.2.2. How Authorization is Configured
You use the BROKER_INSTANCE_DIR/etc/broker.xml configuration file to assign security settings to queues.
The broker.xml configuration file contains the following default security settings, which provide complete access to all addresses and queues for the default role that you created when you created the broker instance:
<configuration ...>
<core ...>
...
<security-settings>
<security-setting match="#"> 1
<permission type="createNonDurableQueue" roles="admin"/> 2
<permission type="deleteNonDurableQueue" roles="admin"/>
<permission type="createDurableQueue" roles="admin"/>
<permission type="deleteDurableQueue" roles="admin"/>
<permission type="createAddress" roles="admin"/>
<permission type="deleteAddress" roles="admin"/>
<permission type="consume" roles="admin"/>
<permission type="browse" roles="admin"/>
<permission type="send" roles="admin"/>
<permission type="manage" roles="admin"/>
</security-setting>
</security-settings>
...
</core>
</configuration>- 1
- The address or address prefix to which a set of security permissions are applied. The permissions are applied to the set of queues that match the address. In this example, the
#wildcard matches all addresses. - 2
- A permission granted to a role. In this example, all users belonging to the
adminrole are granted permission to create non-durable queues.
You can configure authorization for a queue or set of queues by specifying an address that matches the queues, and then specifying the roles that should be granted each permission type.
Related Information
- Configuring user- and role-based authorization in Configuring AMQ Broker
