이 콘텐츠는 선택한 언어로 제공되지 않습니다.

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.