此内容没有您所选择的语言版本。

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

  1. Define the SSL context in the INSTALL_DIR/etc/activemq.xml file:

    <sslContext>
        <sslContext keyStore="file:${activemq.conf}/broker.ks" keyStorePassword="password"/>
    </sslContext>
  2. 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.xml configuration 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:

MethodDescription

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 Network 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 Network Connections in Configuring AMQ Broker.

Note

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 6Corresponding Permissions in AMQ Broker 7

write

send

read

consume

browse

admin

createAddress

deleteAddress

createNonDurableQueue

deleteNonDurableQueue

createDurableQueue

deleteDurableQueue

manage

For more information about permissions in AMQ Broker 7, see Setting Permissions in Configuring AMQ Broker.

The wildcard syntax for matching addresses is also different in AMQ Broker 7.

To…​In AMQ 6In 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 admin role 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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.