Este contenido no está disponible en el idioma seleccionado.
Chapter 5. Securing brokers
5.1. Securing connections
When brokers are connected to messaging clients, or brokers are connected to other brokers, you can secure these connections using Transport Layer Security (TLS).
There are two TLS configurations that you can use:
- One-way TLS, where only the broker presents a certificate. This is the most common configuration.
- Two-way (or mutual) TLS, where both the broker and the client (or other broker) present certificates.
5.1.1. Configuring one-way TLS
The following procedure shows how to configure a given acceptor for one-way TLS.
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. For a given acceptor, add the
sslEnabled
key and set the value totrue
. In addition, add thekeyStorePath
andkeyStorePassword
keys. Set values that correspond to your broker key store. For example:<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!</acceptor>
5.1.2. Configuring two-way TLS
The following procedure shows how to configure two-way TLS.
Prerequisites
- You must have already configured your given acceptor for one-way TLS. For more information, see Section 5.1.1, “Configuring one-way TLS”.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. For the acceptor that you previously configured for one-way TLS, add the
needClientAuth
key. Set the value totrue
. For example:<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true</acceptor>
The configuration in the preceding step assumes that the client’s certificate is signed by a trusted provider. If the client’s certificate is not signed by a trusted provider (it is self-signed, for example) then the broker needs to import the client’s certificate into a trust store. In this case, add the
trustStorePath
andtrustStorePassword
keys. Set values that correspond to your broker trust store. For example:<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true;trustStorePath=../etc/client.truststore;trustStorePassword=5678!</acceptor>
AMQ Broker supports multiple protocols, and each protocol and platform has different ways to specify TLS parameters. However, in the case of a client using Core Protocol (a bridge), the TLS parameters are configured on the connector URL, much like on the broker’s acceptor.
If a self-signed certificate is listed as a trusted certificate in a Java Virtual Machine (JVM) truststore, the JVM does not validate the expiry date of the certificate. In a production environment, Red Hat recommends that you use a certificate that is signed by a Certificate Authority.
5.1.3. TLS configuration options
The following table shows all of the available TLS configuration options.
Option | Note |
---|---|
|
Specifies whether SSL is enabled for the connection. Must be set to |
| When used on an acceptor: Path to the TLS keystore on the broker that holds the broker certificates (whether self-signed or signed by an authority).
When used on a connector: Path to the TLS keystore on the client that holds the client certificates. This is relevant for a connector only if you are using two-way TLS. Although you can configure this value on the broker, it is downloaded and used by the client. If the client needs to use a different path from that set on the broker, it can override the broker setting by using either the standard |
| When used on an acceptor: Password for the keystore on the broker.
When used on a connector: Password for the keystore on the client. This is relevant for a connector only if you are using two-way TLS. Although you can configure this value on the broker, it is downloaded and used by the client. If the client needs to use a different password from that set on the broker, then it can override the broker setting by using either the standard |
| When used on an acceptor: Path to the TLS truststore on the broker that holds the keys of all clients that the broker trusts. This is relevant for an acceptor only if you are using two-way TLS.
When used on a connector: Path to TLS truststore on the client that holds the public keys of all brokers that the client trusts. Although you can configure this value on the broker, it is downloaded and used by the client. If the client needs to use a different path from that set on the server then it can override the server-side setting by using either using the standard |
| When used on an acceptor: Password for the truststore on the broker. This is relevant for an acceptor only if you are using two-way TLS.
When used on a connector: Password for the truststore on the client. Although you can configure this value on the broker, it is downloaded and used by the client. If the client needs to use a different password from that set on the broker, then it can override the broker setting by using either the standard |
| A comma-separated list of cipher suites used for TLS communication for both acceptors or connectors.
Specify the most secure cipher suite(s) supported by your client application. If you specify a comma-separated list of cipher suites that are common to both the broker and the client, or you do not specify any cipher suites, the broker and client mutually negotiate a cipher suite to use. If you do not know which cipher suites to specify, you can first establish a broker-client connection with your client running in debug mode to verify the cipher suites that are common to both the broker and the client. Then, configure
The cipher suites available depend on the TLS protocol versions used by the broker and clients. If the default TLS protocol version changes after you upgrade the broker, you might need to select an earlier TLS protocol version to ensure that the broker and the clients can use a common cipher suite. For more information, see |
| Whether used on an acceptor or connector, this is a comma-separated list of protocols used for TLS communication. If you don’t specify a TLS protocol version, the broker uses the JVM’s default version.
If the broker uses the default TLS protocol version for the JVM and that version changes after you upgrade the broker, the TLS protocol versions used by the broker and clients might be incompatible. While it is recommended that you use the later TLS protocol version, you can specify an earlier version in |
|
This property is only for an acceptor. It instructs a client connecting to the acceptor that two-way TLS is required. Valid values are |
5.2. Authenticating clients
5.2.1. Client authentication methods
To configure client authentication on the broker, you can use the following methods:
- User name- and password-based authentication
Directly validate user credentials using one of these options:
- Check the credentials against a set of properties files stored locally on the broker. You can also configure a guest account that allows limited access to the broker and combine login modules to support more complex use cases.
- Configure a Lightweight Directory Access Protocol (LDAP) login module to check client credentials against user data stored in a central X.500 directory server.
- Certificate-based authentication
- Configure two-way Transport Layer Security (TLS) to require both the broker and client to present certificates for mutual authentication. An administrator must also configure properties files that define approved client users and roles. These properties files are stored on the broker.
- Kerberos-based authentication
- Configure the broker to authenticate Kerberos security credentials for the client using the GSSAPI mechanism from the Simple Authentication and Security Layer (SASL) framework.
The sections that follow describe how to configure both user-and-password- and certificate-based authentication.
Additional resources
To learn about complete authentication and authorization workflows for LDAP and Kerberos, see:
5.2.2. Configuring user and password authentication based on properties files
AMQ Broker supports a flexible role-based security model for applying security to queues based on their addresses. Queues are bound to addresses either one-to-one (for point-to-point messaging) or many-to-one (for publish-subscribe messaging). When a message is sent to an address, the broker looks up the set of queues that are bound to that address and routes the message to that set of queues.
When you require basic user and password authentication, use PropertiesLoginModule
to define it. This login module checks user credentials against the following configuration files that are stored locally on the broker:
artemis-users.properties
- Used to define users and corresponding passwords
artemis-roles.properties
- Used to define roles and assign users to those roles
login.config
- Used to configure login modules for user and password authentication and guest access
The artemis-users.properties
file can contain hashed passwords, for security.
The following sections show how to configure:
5.2.2.1. Configuring basic user and password authentication
The following procedure shows how to configure basic user and password authentication.
Procedure
Open the
<broker_instance_dir>/etc/login.config
configuration file. By default, this file in a new AMQ Broker 7.12 instance includes the following lines:activemq { org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient debug=false reload=true org.apache.activemq.jaas.properties.user="artemis-users.properties" org.apache.activemq.jaas.properties.role="artemis-roles.properties"; };
activemq
- Alias for the configuration.
org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule
- The implementation class.
sufficient
Flag that specifies what level of success is required for the
PropertiesLoginModule
. The values that you can set are:-
required
: The login module is required to succeed. Authentication continues to proceed down the list of login modules configured under the given alias, regardless of success or failure. -
requisite
: The login module is required to succeed. A failure immediately returns control to the application. Authentication does not proceed down the list of login modules configured under the given alias. -
sufficient
: The login module is not required to succeed. If it is successful, control returns to the application and authentication does not proceed further. If it fails, the authentication attempt proceeds down the list of login modules configured under the given alias. -
optional
: The login module is not required to succeed. Authentication continues down the list of login modules configured under the given alias, regardless of success or failure.
-
org.apache.activemq.jaas.properties.user
- Specifies the properties file that defines a set of users and passwords for the login module implementation.
org.apache.activemq.jaas.properties.role
- Specifies the properties file that maps users to defined roles for the login module implementation.
-
Open the
<broker_instance_dir>/etc/artemis-users.properties
configuration file. Add users and assign passwords to the users. For example:
user1=secret user2=access user3=myPassword
-
Open the
<broker_instance_dir>/etc/artemis-roles.properties
configuration file. Assign role names to the users you previously added to the
artemis-users.properties
file. For example:admin=user1,user2 developer=user3
-
Open the
<broker_instance_dir>/etc/bootstrap.xml
configuration file. If necessary, add your security domain alias (in this instance, activemq) to the file, as shown below:
<jaas-security domain="activemq"/>
5.2.2.2. Configuring guest access
For a user who does not have login credentials, or whose credentials fail authentication, you can grant limited access to the broker using a guest account.
You can create a broker instance with guest access enabled using the command-line switch; --allow-anonymous
(the converse of which is --require-login
).
The following procedure shows how to configure guest access.
Prerequisites
- This procedure assumes that you have already configured basic user and password authentication. To learn more, see Section 5.2.2.1, “Configuring basic user and password authentication”.
Procedure
-
Open the
<broker_instance_dir>/etc/login.config
configuration file that you previously configured for basic user and password authentication. After the properties login module configuration that you previously added, add a guest login module configuration. For example:
activemq { org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient debug=true org.apache.activemq.jaas.properties.user="artemis-users.properties" org.apache.activemq.jaas.properties.role="artemis-roles.properties"; org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule sufficient debug=true org.apache.activemq.jaas.guest.user="guest" org.apache.activemq.jaas.guest.role="restricted"; };
org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule
- The implementation class.
org.apache.activemq.jaas.guest.user
- The user name assigned to anonymous users.
org.apache.activemq.jaas.guest.role
- The role assigned to anonymous users.
Based on the preceding configuration, user and password authentication module is activated if the user supplies credentials. Guest authentication is activated if the user supplies no credentials, or if the credentials supplied are incorrect.
5.2.2.2.1. Guest access example
The following example shows configuration of guest access for the use case where only those users with no credentials are logged in as guests. In this example, observe that the order of the login modules is reversed compared with the previous configuration procedure. Also, the flag attached to the properties login module is changed to requisite
.
activemq { org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule sufficient debug=true credentialsInvalidate=true org.apache.activemq.jaas.guest.user="guest" org.apache.activemq.jaas.guest.role="guests"; org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule requisite debug=true org.apache.activemq.jaas.properties.user="artemis-users.properties" org.apache.activemq.jaas.properties.role="artemis-roles.properties"; };
Based on the preceding configuration, the guest authentication module is activated if no login credentials are supplied.
For this use case, the credentialsInvalidate
option must be set to true
in the configuration of the guest login module.
The properties login module is activated if credentials are supplied. The credentials must be valid.
Additional resources
-
For more information on the Java Authentication and Authorization Service (JAAS), see the documentation from your Java vendor. For example, for an Oracle tutorial on configuring
login.config
, see JAAS Login Configuration File in the Oracle Java documentation. - To learn how to configure an LDAP login module to validate client credentials, see Section 5.4.1, “Configuring LDAP to authenticate clients”.
- For more information about encrypting passwords in configuration files, see Section 5.9.2, “Encrypting a password in a configuration file”.
5.2.3. Configuring certificate-based authentication
The Java Authentication and Authorization Service (JAAS) certificate login module handles authentication and authorization for clients that are using Transport Layer Security (TLS). The module requires two-way Transport Layer Security (TLS) to be in use and clients to be configured with their own certificates. Authentication is performed during the TLS handshake, not directly by the JAAS certificate login module.
The role of the certificate login module is to:
- Constrain the set of acceptable users. Only the user Distinguished Names (DNs) explicitly listed in the relevant properties file are eligible to be authenticated.
- Associate a list of groups with the received user identity. This facilitates authorization.
- Require the presence of an incoming client certificate (by default, the TLS layer is configured to treat the presence of a client certificate as optional).
The certificate login module stores a collection of certificate DNs in a pair of flat text files. The files associate a user name and a list of group IDs with each DN.
The certificate login module is implemented by the org.apache.activemq.artemis.spi.core.security.jaas.TextFileCertificateLoginModule
class.
5.2.3.1. Configuring the broker to use certificate-based authentication
The following procedure shows how to configure the broker to use certificate-based authentication.
Prerequisites
- You must have configured the broker to use two-way Transport Layer Security (TLS). For more information, see Section 5.1.2, “Configuring two-way TLS”.
Procedure
Obtain the Subject Distinguished Names (DNs) from user certificates previously imported to the broker key store.
Export the certificate from the key store file into a temporary file. For example:
keytool -export -file <file_name> -alias broker-localhost -keystore broker.ks -storepass <password>
Print the contents of the exported certificate:
keytool -printcert -file <file_name>
The output is similar to that shown below:
Owner: CN=localhost, OU=broker, O=Unknown, L=Unknown, ST=Unknown, C=Unknown Issuer: CN=localhost, OU=broker, O=Unknown, L=Unknown, ST=Unknown, C=Unknown Serial number: 4537c82e Valid from: Thu Oct 19 19:47:10 BST 2006 until: Wed Jan 17 18:47:10 GMT 2007 Certificate fingerprints: MD5: 3F:6C:0C:89:A8:80:29:CC:F5:2D:DA:5C:D7:3F:AB:37 SHA1: F0:79:0D:04:38:5A:46:CE:86:E1:8A:20:1F:7B:AB:3A:46:E4:34:5C
The
Owner
entry is the Subject DN. The format used to enter the Subject DN depends on your platform. The string above could also be represented as;Owner: `CN=localhost,\ OU=broker,\ O=Unknown,\ L=Unknown,\ ST=Unknown,\ C=Unknown`
Configure certificate-based authentication.
Open the
<broker_instance_dir>/etc/login.config
configuration file. Add the certificate login module and reference the user and roles properties files. For example:activemq { org.apache.activemq.artemis.spi.core.security.jaas.TextFileCertificateLoginModule debug=true org.apache.activemq.jaas.textfiledn.user="artemis-users.properties" org.apache.activemq.jaas.textfiledn.role="artemis-roles.properties"; };
org.apache.activemq.artemis.spi.core.security.jaas.TextFileCertificateLoginModule
- The implementation class.
org.apache.activemq.jaas.textfiledn.user
- Specifies the properties file that defines a set of users and passwords for the login module implementation.
org.apache.activemq.jaas.textfiledn.role
- Specifies the properties file that maps users to defined roles for the login module implementation.
Open the
<broker_instance_dir>/etc/artemis-users.properties
configuration file. Users and their corresponding DNs are defined in this file. For example:system=CN=system,O=Progress,C=US user=CN=humble user,O=Progress,C=US guest=CN=anon,O=Progress,C=DE
Based on the preceding configuration, for example, the user named
system
is mapped to theCN=system,O=Progress,C=US
Subject DN.Open the
<broker_instance_dir>/etc/artemis-roles.properties
configuration file. The available roles and the users who hold those roles are defined in this file. For example:admins=system users=system,user guests=guest
In the preceding configuration, for the
users
role, you list multiple users as a comma-separated list.Ensure that your security domain alias (in this instance, activemq) is referenced in
bootstrap.xml
, as shown below:<jaas-security domain="activemq"/>
5.2.3.2. Configuring certificate-based authentication for AMQP clients
Use the Simple Authentication and Security Layer (SASL) EXTERNAL mechanism configuration parameter to configure your AQMP client for certificate-based authentication when connecting to a broker.
The broker authenticates the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) certificate of your AMQP client in the same way that it authenticates any certificate:
- The broker reads the TLS/SSL certificate of the client to obtain an identity from the certificate’s subject.
- The certificate subject is mapped to a broker identity by the certificate login module. The broker then authorizes users based on their roles.
The following procedure shows how to configure certificate-based authentication for AMQP clients. To enable your AMQP client to use certificate-based authentication, you must add configuration parameters to the URI that the client uses to connect to the broker.
Prerequisites
You must have configured:
- Two-way TLS. For more information, see Section 5.1.2, “Configuring two-way TLS”.
- The broker to use certificate-based authentication. For more information, see Section 5.2.3.1, “Configuring the broker to use certificate-based authentication”.
Procedure
Open the resource containing the URI for editing:
amqps://localhost:5500
Add the parameter
sslEnabled=true
to enable TSL/SSL for the connection:amqps://localhost:5500?sslEnabled=true
Add parameters related to the client trust store and key store to enable the exchange of TSL/SSL certificates with the broker:
amqps://localhost:5500?sslEnabled=true&trustStorePath=<trust_store_path>&trustStorePassword=<trust_store_password>&keyStorePath=<key_store_path>&keyStorePassword=<key_store_password>
Add the parameter
saslMechanisms=EXTERNAL
to request that the broker authenticate the client by using the identity found in its TSL/SSL certificate:amqps://localhost:5500?sslEnabled=true&trustStorePath=<trust_store_path>&trustStorePassword=<trust_store_password>&keyStorePath=<key_store_path>&keyStorePassword=<key_store_password>&saslMechanisms=EXTERNAL
Additional resources
- For more information about certificate-based authentication in AMQ Broker, see Section 5.2.3.1, “Configuring the broker to use certificate-based authentication”.
- For more information about configuring your AMQP client, go to the Red Hat Customer Portal for product documentation specific to your client.
5.3. Authorizing clients
5.3.1. Client authorization methods
To authorize clients to perform operations on the broker such as creating and deleting addresses and queues, and sending and consuming messages, you can use the following methods:
- User- and role-based authorization
- Configure broker security settings for authenticated users and roles.
- Configure LDAP to authorize clients
- Configure the Lightweight Directory Access Protocol (LDAP) login module to handle both authentication and authorization. The LDAP login module checks incoming credentials against user data stored in a central X.500 directory server and sets permissions based on user roles.
- Configure Kerberos to authorize clients
-
Configure the Java Authentication and Authorization Service (JAAS)
Krb5LoginModule
login module to pass credentials toPropertiesLoginModule
orLDAPLoginModule
login modules, which map the Kerberos-authenticated users to AMQ Broker roles.
5.3.2. Configuring user- and role-based authorization
5.3.2.1. Setting permissions
Permissions are defined against queues (based on their addresses) via the <security-setting>
element in the broker.xml
configuration file. You can define multiple instances of <security-setting>
in the <security-settings>
element of the configuration file. You can specify an exact address match or you can define a wildcard match using the number sign (#
) and asterisk (*
) wildcard characters.
Different permissions can be given to the set of queues that match an address. Those permissions are shown in the following table.
To allow users to… | Use this parameter… |
---|---|
Create addresses |
|
Delete addresses |
|
Create a durable queue under matching addresses |
|
Delete a durable queue under matching addresses |
|
Create a non-durable queue under matching addresses |
|
Delete a non-durable queue under matching addresses |
|
Send a message to matching addresses |
|
Consume a message from a queue bound to matching addresses |
|
Invoke management operations by sending management messages to the management address |
|
Browse a queue bound to the matching address |
|
Have read-only access to a subset of management operations |
|
Access the mutating management operations, which is any operation not granted access with the |
|
For each permission, you specify a list of roles that are granted the permission. If a given user has any of the roles, they are granted the permission for that set of addresses.
The sections that follow show some configuration examples for permissions.
5.3.2.1.1. Configuring message production for a single address
The following procedure shows how to configure message production permissions for a single address.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Add a single
<security-setting>
element within the<security-settings>
element. For thematch
key, specify an address. For example:<security-settings> <security-setting match="my.destination"> <permission type="send" roles="producer"/> </security-setting> </security-settings>
Based on the preceding configuration, members of the
producer
role havesend
permissions for addressmy.destination
.
5.3.2.1.2. Configuring message consumption for a single address
The following procedure shows how to configure message consumption permissions for a single address.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Add a single
<security-setting>
element within the<security-settings>
element. For thematch
key, specify an address. For example:<security-settings> <security-setting match="my.destination"> <permission type="consume" roles="consumer"/> </security-setting> </security-settings>
Based on the preceding configuration, members of the
consumer
role haveconsume
permissions for addressmy.destination
.
5.3.2.1.3. Configuring complete access on all addresses
The following procedure shows how to configure complete access to all addresses and associated queues.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Add a single
<security-setting>
element within the<security-settings>
element. For thematch
key, to configure access to all addresses, specify the number sign (#
) wildcard character. For example:<security-settings> <security-setting match="#"> <permission type="createDurableQueue" roles="guest"/> <permission type="deleteDurableQueue" roles="guest"/> <permission type="createNonDurableQueue" roles="guest"/> <permission type="deleteNonDurableQueue" roles="guest"/> <permission type="createAddress" roles="guest"/> <permission type="deleteAddress" roles="guest"/> <permission type="send" roles="guest"/> <permission type="browse" roles="guest"/> <permission type="consume" roles="guest"/> <permission type="manage" roles="guest"/> </security-setting> </security-settings>
Based on the preceding configuration, all permissions are granted to members of the guest role on all queues. This can be useful in a development scenario where anonymous authentication was configured to assign the
guest
role to every user.
Additional resources
- To learn about configuring more complex use cases, see Section 5.3.2.1.4, “Configuring multiple security settings”.
5.3.2.1.4. Configuring multiple security settings
The following example procedure shows how to individually configure multiple security settings for a matching set of addresses. This contrasts with the preceding example in this section, which shows how to grant complete access to all addresses.
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Add a single
<security-setting>
element within the<security-settings>
element. For thematch
key, include the number sign (#
) wildcard character to apply the settings to a matching set of addresses. For example:<security-setting match="globalqueues.europe.#"> <permission type="createDurableQueue" roles="admin"/> <permission type="deleteDurableQueue" roles="admin"/> <permission type="createNonDurableQueue" roles="admin, guest, europe-users"/> <permission type="deleteNonDurableQueue" roles="admin, guest, europe-users"/> <permission type="send" roles="admin, europe-users"/> <permission type="consume" roles="admin, europe-users"/> </security-setting>
match=globalqueues.europe.#
-
The number sign (
#
) wildcard character is interpreted by the broker as "any sequence of words". Words are delimited by a period (.
). In this example, the security settings apply to any address that starts with the string globalqueues.europe. permission type="createDurableQueue"
-
Only users that have the
admin
role can create or delete durable queues bound to an address that starts with the string globalqueues.europe. permission type="createNonDurableQueue"
-
Any users with the roles
admin
,guest
, oreurope-users
can create or delete temporary queues bound to an address that starts with the string globalqueues.europe. permission type="send"
-
Any users with the roles
admin
oreurope-users
can send messages to queues bound to an address that starts with the string globalqueues.europe. permission type="consume"
-
Any users with the roles
admin
oreurope-users
can consume messages from queues bound to an address that starts with the string globalqueues.europe.
(Optional) To apply different security settings to a more narrow set of addresses, add another
<security-setting>
element. For thematch
key, specify a more specific text string. For example:<security-setting match="globalqueues.europe.orders.#"> <permission type="send" roles="europe-users"/> <permission type="consume" roles="europe-users"/> </security-setting>
In the second
security-setting
element, theglobalqueues.europe.orders.#
match is more specific than theglobalqueues.europe.#
match specified in the firstsecurity-setting
element. For any addresses that matchglobalqueues.europe.orders.#
, the permissionscreateDurableQueue
,deleteDurableQueue
,createNonDurableQueue
,deleteNonDurableQueue
are not inherited from the firstsecurity-setting
element in the file. For example, for the addressglobalqueues.europe.orders.plastics
, the only permissions that exist aresend
andconsume
for the roleeurope-users
.Therefore, because permissions specified in one
security-setting
block are not inherited by another, you can effectively deny permissions in more specificsecurity-setting
blocks simply by not specifying those permissions.
5.3.2.1.5. Configuring a queue with a user
When a queue is automatically created, the queue is assigned the user name of the connecting client. This user name is included as metadata on the queue. The name is exposed by JMX and in the AMQ Broker management console.
The following procedure shows how to add a user name to a queue that you have manually defined in the broker configuration.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. For a given queue, add the
user
key. Assign a value. For example:<address name="ExampleQueue"> <anycast> <queue name="ExampleQueue"> <user>admin</user> </queue> </anycast> </address>
Based on the preceding configuration, the
admin
user is assigned to queueExampleQueue
.
- Configuring a user on a queue does not change any of the security semantics for that queue - it is only used for metadata on that queue.
The mapping between users and what roles they have is handled by a component called the security manager. The security manager reads user credentials from a properties file stored on the broker. By default, AMQ Broker uses the
org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager
security manager. This default security manager provides integration with JAAS and Red Hat JBoss Enterprise Application Platform (JBoss EAP) security.To learn how to use a custom security manager, see Section 5.6.2, “Specifying a custom security manager”.
5.3.2.2. Configuring role-based access control
Role-based access control (RBAC) is used to restrict access to the attributes and methods of MBeans. MBeans are the way the management API is exposed by AMQ Broker to support management operations.
You can restrict access to MBeans by using either of the following methods:
-
Configure the
authorisation
element in themanagement.xml
file, which is the default method. -
Configure security settings in the
broker.xml
file.
Unlike when you update the management.xml
file, you do not need to restart the broker after you make changes to security settings in the broker.xml
file.
5.3.2.2.1. Configuring role-based access control in the management.xml
file.
The default method of configuring role based access control for management operations is by configuring the authorisation
element in the management.xml
file.
The following example procedure shows how to map roles to particular MBeans and their attributes and methods.
Prerequisites
- You defined users and roles. For more information, see Section 5.2.2.1, “Configuring basic user and password authentication”.
Procedure
-
Open the
<broker_instance_dir>/etc/management.xml
configuration file. Search for the
role-access
element and edit the configuration. For example:<role-access> <match domain="org.apache.activemq.artemis"> <access method="list*" roles="view,update,amq"/> <access method="get*" roles="view,update,amq"/> <access method="is*" roles="view,update,amq"/> <access method="set*" roles="update,amq"/> <access method="*" roles="amq"/> </match> </role-access>
-
In this case, a match is applied to any MBean attribute that has the domain name
org.apache.activemq.apache
. -
Access of the
view
,update
, oramq
role to a matching MBean attribute is controlled by which of thelist*
,get*
,set*
,is*
, and*
access methods that you add the role to. Themethod="*"
(wildcard) syntax is used as a catch-all way to specify every other method that is not listed in the configuration. Each of the access methods in the configuration is converted to an MBean method call. -
An invoked MBean method is matched against the methods listed in the configuration. For example, if you invoke a method called
listMessages
on an MBean with theorg.apache.activemq.artemis
domain, then the broker matches access back to the roles defined in the configuration for thelist
method. You can also configure access by using the full MBean method name. For example:
<access method="listMessages" roles="view,update,amq"/>
-
In this case, a match is applied to any MBean attribute that has the domain name
Start or restart the broker.
-
On Linux:
<broker_instance_dir>/bin/artemis run
On Windows:
<broker_instance_dir>\bin\artemis-service.exe start
You can also match specific MBeans within a domain by adding a
key
attribute that matches an MBean property.
-
On Linux:
5.3.2.2.1.1. Role-based access examples
This section shows the following examples of applying role-based access control:
The following example shows how to use the key
attribute to map roles to all queues in a specified domain.
<match domain="org.apache.activemq.artemis" key="subcomponent=queues"> <access method="list*" roles="view,update,amq"/> <access method="get*" roles="view,update,amq"/> <access method="is*" roles="view,update,amq"/> <access method="set*" roles="update,amq"/> <access method="*" roles="amq"/> </match>
The following example shows how to use the key
attribute to map roles to a specific, named queue. In this example, the named queue is exampleQueue
.
<match domain="org.apache.activemq.artemis" key="queue=exampleQueue"> <access method="list*" roles="view,update,amq"/> <access method="get*" roles="view,update,amq"/> <access method="is*" roles="view,update,amq"/> <access method="set*" roles="update,amq"/> <access method="*" roles="amq"/> </match>
The following example shows how to map roles to every queue whose name includes a specified prefix. In this example, an asterisk (*
) wildcard operator is used to match all queue names that start with the prefix example.
<match domain="org.apache.activemq.artemis" key="queue=example*"> <access method="list*" roles="view,update,amq"/> <access method="get*" roles="view,update,amq"/> <access method="is*" roles="view,update,amq"/> <access method="set*" roles="update,amq"/> <access method="*" roles="amq"/> </match>
You might want to map roles differently for different sets of the same attribute (for example, different sets of queues). In this case, you can include multiple match
elements in your configuration file. However, it is then possible to have multiple matches in the same domain.
For example, consider two <match>
elements configured as follows:
<match domain="org.apache.activemq.artemis" key="queue=example*">
and
<match domain="org.apache.activemq.artemis" key="queue=example.sub*">
Based on this configuration, a queue named example.sub.queue
in the org.apache.activemq.artemis
domain matches both wildcard key expressions. Therefore, the broker needs a prioritization scheme to decide which set of roles to map to the queue; the roles specified in the first match
element, or those specified in the second match
element.
When there are multiple matches in the same domain, the broker uses the following prioritization scheme when mapping roles:
- Exact matches are prioritized over wildcard matches
- Longer wildcard matches are prioritized over shorter wildcard matches
In this example, because the longer wildcard expression matches the queue name of example.sub.queue
most closely, the broker applies the role-mapping configured in the second <match>
element.
The default-access
element is a catch-all element for every method call that is not handled using the role-access
or whitelist
configurations. The default-access
and role-access
elements have the same match
element semantics.
5.3.2.2.1.2. Configuring the allowlist
element
An allowlist is a set of pre-approved domains or MBeans that do not require user authentication. You can provide a list of domains, or list of MBeans, or both, that must bypass the authentication. For example, you might use an allowlist
to specify any MBeans that are needed by the AMQ Broker management console to run.
The following example procedure shows how to configure the allowlist
element.
Procedure
-
Open the
<broker_instance_dir>/etc/management.xml
configuration file. Search for the
allowlist
element and edit the configuration:<allowlist> <entry domain="hawtio"/> </allowlist>
In this example, any MBean with the domain
hawtio
is allowed access without authentication. You can also use wildcard entries of the form<entry domain="hawtio" key="type=*"/>
for the MBean properties to match.Start or restart the broker.
-
On Linux:
<broker_instance_dir>/bin/artemis run
-
On Windows:
<broker_instance_dir>\bin\artemis-service.exe start
-
On Linux:
5.3.2.2.2. Configuring role-based access control in the broker.xml
file
You can configure role based access control for management operations in the broker.xml
file instead of the management.xml
file. Updates to permissions in the broker.xml
file do not require a broker restart to take effect.
In the broker.xml
file, you can grant either view
or edit
permissions for management operations. The specific management operations that are available to a role that has view
or edit
permissions is controlled by a predefined regular expression. Any operation that matches the regular expression can be accessed by a role that has the view
permission and all other operations require the edit
permission.
Prerequisites
- You defined users and roles. For more information, see Section 5.2.2.1, “Configuring basic user and password authentication”.
Procedure
Delete the
authorisation
element configuration from themanagement.xml
file to prevent the broker from using the default RBAC configuration in this file.-
Edit the
<broker_instance_dir>/etc/management.xml
file. -
Delete the
authorisation
element configuration from the file. -
Save the
<broker_instance_dir>/etc/management.xml
file.
-
Edit the
Add an environment variable to the broker JVM to configure the broker to use the RBAC configuration in the
broker.xml
file.-
Open the
<broker_instance_dir>/etc/artemis.profile
file. Add the following argument to the
JAVA_ARGS list
of Java system arguments:-Djavax.management.builder.initial=org.apache.activemq.artemis.core.server.management.ArtemisRbacMBeanServerBuilder
-
Save the
artemis.profile
file.
-
Open the
-
Open the
<broker_instance_dir>/etc/broker.xml
file to configure RBAC for management operations. Search for the
security-settings
element and add asecurity-setting
element for management operations.The format of the match addresses for management operations is:
<_management-rbac-prefix_>.<_resource type_>.<_resource name_>.<_operation_>
The default value of the
management-rbac-prefix
parameter ismops
.In following example RBAC configuration, the number sign (#) in the match address grants the
admin
roleview
andedit
permissions to all MBeans.<security-settings> .. <security-setting match="mops.#"> <permission type="view" roles="admin"/> <permission type="edit" roles="admin"/> </security-setting> .. </security-setting>
-
Save the
<broker_instance_dir>/etc/broker.xml
configuration file.
Other examples of role-based access control for management operations
The following example grants a manager
role view
and edit
permission to an address of activemq.management
. The asterisk (*) in the operation position grants access to all operations.
<security-setting match="mops.address.activemq.management.*"> <permission type="view" roles="manager"/> </security-setting>
The following example has an empty roles list, which denies all users permission to perform the specified operation, forceFailover
, using the broker MBean.
<security-setting match="mops.broker.forceFailover"> <permission type="edit" roles=""/> </security-setting>
5.3.2.3. Setting resource limits
Sometimes it is helpful to set particular limits on what certain users can do beyond the normal security settings related to authorization and authentication.
5.3.2.3.1. Configuring connection and queue limits
The following example procedure shows how to limit the number of connections and queues that a user can create.
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Add a
resource-limit-settings
element. Specify values formax-connections
andmax-queues
. For example:<resource-limit-settings> <resource-limit-setting match="myUser"> <max-connections>5</max-connections> <max-queues>3</max-queues> </resource-limit-setting> </resource-limit-settings>
max-connections
-
Defines how many sessions the matched user can create on the broker. The default is
-1
, which means that there is no limit. If you want to limit the number of sessions, take into account that each connection to the broker from an AMQ Core Protocol JMS client creates two sessions. max-queues
-
Defines how many queues the matched user can create. The default is
-1
, which means that there is no limit.
Unlike the match
string that you can specify in the address-setting
element of a broker configuration, the match
string that you specify in resource-limit-settings
cannot use wildcard syntax. Instead, the match string defines a specific user to which the resource limit settings are applied.
5.4. Using LDAP for authentication and authorization
The LDAP login module enables authentication and authorization by checking the incoming credentials against user data stored in a central X.500 directory server. It is implemented by org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule
.
5.4.1. Configuring LDAP to authenticate clients
The following example procedure shows how to use LDAP to authenticate clients.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Within the
security-settings
element, add asecurity-setting
element to configure permissions. For example:<security-settings> <security-setting match="#"> <permission type="createDurableQueue" roles="user"/> <permission type="deleteDurableQueue" roles="user"/> <permission type="createNonDurableQueue" roles="user"/> <permission type="deleteNonDurableQueue" roles="user"/> <permission type="send" roles="user"/> <permission type="consume" roles="user"/> </security-setting> </security-settings>
The preceding configuration assigns specific permissions for all queues to members of the
user
role.-
Open the
<broker_instance_dir>/etc/login.config
file. Configure the LDAP login module, based on the directory service you are using.
If you are using the Microsoft Active Directory directory service, add a configuration that resembles this example:
activemq { org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule required debug=true initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory connectionURL="LDAP://localhost:389" connectionUsername="CN=Administrator,CN=Users,OU=System,DC=example,DC=com" connectionPassword=redhat.123 connectionProtocol=s connectionTimeout="5000" authentication=simple userBase="dc=example,dc=com" userSearchMatching="(CN={0})" userSearchSubtree=true readTimeout="5000" roleBase="dc=example,dc=com" roleName=cn roleSearchMatching="(member={0})" roleSearchSubtree=true ; };
NoteIf you are using Microsoft Active Directory, and a value that you need to specify for an attribute of
connectionUsername
contains a space (for example,OU=System Accounts
), then you must enclose the value in a pair of double quotes (""
) and use a backslash (\
) to escape each double quote in the pair. For example,connectionUsername="CN=Administrator,CN=Users,OU=\"System Accounts\",DC=example,DC=com"
.If you are using the ApacheDS directory service, add a configuration that resembles this example:
activemq { org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule required debug=true initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory connectionURL="ldap://localhost:10389" connectionUsername="uid=admin,ou=system" connectionPassword=secret connectionProtocol=s connectionTimeout=5000 authentication=simple userBase="dc=example,dc=com" userSearchMatching="(uid={0})" userSearchSubtree=true userRoleName= readTimeout=5000 roleBase="dc=example,dc=com" roleName=cn roleSearchMatching="(member={0})" roleSearchSubtree=true ; };
debug
-
Turn debugging on (
true
) or off (false
). The default value isfalse
. initialContextFactory
-
Must always be set to
com.sun.jndi.ldap.LdapCtxFactory
connectionURL
-
Location of the directory server using an LDAP URL, __<ldap://Host:Port>. One can optionally qualify this URL, by adding a forward slash,
/
, followed by the DN of a particular node in the directory tree. The default port of Apache DS is10389
while for Microsoft AD the default is389
. connectionUsername
-
Distinguished Name (DN) of the user that opens the connection to the directory server. For example,
uid=admin,ou=system
. Directory servers generally require clients to present username/password credentials in order to open a connection. connectionPassword
-
Password that matches the DN from
connectionUsername
. In the directory server, in the Directory Information Tree (DIT), the password is normally stored as auserPassword
attribute in the corresponding directory entry. connectionProtocol
- Any value is supported but is effectively unused. This option must be set explicitly because it has no default value.
connectionTimeout
Specify the maximum time, in milliseconds, that the broker can take to connect to the directory server. If the broker cannot connect to the directory sever within this time, it aborts the connection attempt. If you specify a value of zero or less for this property, the timeout value of the underlying TCP protocol is used instead. If you do not specify a value, the broker waits indefinitely to establish a connection, or the underlying network times out.
When connection pooling has been requested for a connection, then this property specifies the maximum time that the broker waits for a connection when the maximum pool size has already been reached and all connections in the pool are in use. If you specify a value of zero or less, the broker waits indefinitely for a connection to become available. Otherwise, the broker aborts the connection attempt when the maximum wait time has been reached.
authentication
-
Specifies the authentication method used when binding to the LDAP server. This parameter can be set to either
simple
(which requires a username and password) ornone
(which allows anonymous access). userBase
-
Select a particular subtree of the DIT to search for user entries. The subtree is specified by a DN, which specifies the base node of the subtree. For example, by setting this option to
ou=User,ou=ActiveMQ,ou=system
, the search for user entries is restricted to the subtree beneath theou=User,ou=ActiveMQ,ou=system
node. userSearchMatching
-
Specify an LDAP search filter, which is applied to the subtree selected by
userBase
. See the Section 5.4.1.1, “Search matching parameters” section below for more information. userSearchSubtree
-
Specify the search depth for user entries, relative to the node specified by
userBase
. This option is a Boolean. Specifying a value offalse
means that the search tries to match one of the child entries of theuserBase
node (maps tojavax.naming.directory.SearchControls.ONELEVEL_SCOPE
). Specifying a value oftrue
means that the search tries to match any entry belonging to the subtree of theuserBase
node (maps tojavax.naming.directory.SearchControls.SUBTREE_SCOPE
). userRoleName
- Name of the attribute of the user entry that contains a list of role names for the user. Role names are interpreted as group names by the broker’s authorization plug-in. If this option is omitted, no role names are extracted from the user entry.
readTimeout
- Specify the maximum time, in milliseconds, that the broker can wait to receive a response from the directory server to an LDAP request. If the broker does not receive a response from the directory server in this time, the broker aborts the request. If you specify a value of zero or less, or you do not specify a value, the broker waits indefinitely for a response from the directory server to an LDAP request.
roleBase
-
If role data is stored directly in the directory server, one can use a combination of role options (
roleBase
,roleSearchMatching
,roleSearchSubtree
, androleName
) as an alternative to (or in addition to) specifying theuserRoleName
option. This option selects a particular subtree of the DIT to search for role/group entries. The subtree is specified by a DN, which specifies the base node of the subtree. For example, by setting this option toou=Group,ou=ActiveMQ,ou=system
, the search for role/group entries is restricted to the subtree beneath theou=Group,ou=ActiveMQ,ou=system
node. roleName
- Attribute type of the role entry that contains the name of the role/group (such as C, O, OU, etc.). If this option is omitted the role search feature is effectively disabled.
roleSearchMatching
-
Specify an LDAP search filter, which is applied to the subtree selected by
roleBase
. See the Section 5.4.1.1, “Search matching parameters” section below for more information. roleSearchSubtree
Specify the search depth for role entries, relative to the node specified by
roleBase
. If set tofalse
(which is the default) the search tries to match one of the child entries of theroleBase
node (maps tojavax.naming.directory.SearchControls.ONELEVEL_SCOPE
). Iftrue
it tries to match any entry belonging to the subtree of the roleBase node (maps tojavax.naming.directory.SearchControls.SUBTREE_SCOPE
).NoteApache DS uses the
OID
portion of DN path. Microsoft Active Directory uses theCN
portion. For example, you might use a DN path such asoid=testuser,dc=example,dc=com
in Apache DS, while you might use a DN path such ascn=testuser,dc=example,dc=com
in Microsoft Active Directory.
- Start or restart the broker (service or process).
5.4.1.1. Search matching parameters
userSearchMatching
Before passing to the LDAP search operation, the string value provided in this configuration parameter is subjected to string substitution, as implemented by the
java.text.MessageFormat
class.
This means that the special string,
{0}
, is substituted by the username, as extracted from the incoming client credentials. After substitution, the string is interpreted as an LDAP search filter (the syntax is defined by the IETF standard RFC 2254).
For example, if this option is set to
(uid={0})
and the received username isjdoe
, the search filter becomes(uid=jdoe)
after string substitution.
If the resulting search filter is applied to the subtree selected by the user base,
ou=User,ou=ActiveMQ,ou=system
, it would match the entry,uid=jdoe,ou=User,ou=ActiveMQ,ou=system
.
roleSearchMatching
This works in a similar manner to the
userSearchMatching
option, except that it supports two substitution strings.
The substitution string
{0}
substitutes the full DN of the matched user entry (that is, the result of the user search). For example, for the user,jdoe
, the substituted string could beuid=jdoe,ou=User,ou=ActiveMQ,ou=system
.
The substitution string
{1}
substitutes the received user name. For example,jdoe
.
If this option is set to
(member=uid={1})
and the received user name isjdoe
, the search filter becomes(member=uid=jdoe)
after string substitution (assuming ApacheDS search filter syntax).
If the resulting search filter is applied to the subtree selected by the role base,
ou=Group,ou=ActiveMQ,ou=system
, it matches all role entries that have amember
attribute equal touid=jdoe
(the value of amember
attribute is a DN).
This option must always be set, even if role searching is disabled, because it has no default value. If OpenLDAP is used, the syntax of the search filter is
(member:=uid=jdoe)
.
Additional resources
- For a short introduction to the search filter syntax, see Oracle JNDI tutorial.
5.4.2. Configuring LDAP authorization
The LegacyLDAPSecuritySettingPlugin
security settings plugin reads the security information previously handled in AMQ 6 by LDAPAuthorizationMap
and cachedLDAPAuthorizationMap
and converts this information to corresponding AMQ 7 security settings, where possible.
The security implementations for brokers in AMQ 6 and AMQ 7 do not match exactly. Therefore, the plugin performs some translation between the two versions to achieve near-equivalent functionality.
The following example shows how to configure the plugin.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Within the
security-settings
element, add thesecurity-setting-plugin
element. For example:<security-settings> <security-setting-plugin class-name="org.apache.activemq.artemis.core.server.impl.LegacyLDAPSecuritySettingPlugin"> <setting name="initialContextFactory" value="com.sun.jndi.ldap.LdapCtxFactory"/> <setting name="connectionURL" value="ldap://localhost:1024"/>`ou=destinations,o=ActiveMQ,ou=system` <setting name="connectionUsername" value="uid=admin,ou=system"/> <setting name="connectionPassword" value="secret"/> <setting name="connectionProtocol" value="s"/> <setting name="authentication" value="simple"/> </security-setting-plugin> </security-settings>
class-name
-
The implementation is
org.apache.activemq.artemis.core.server.impl.LegacyLDAPSecuritySettingPlugin
. initialContextFactory
-
The initial context factory used to connect to LDAP. It must always be set to
com.sun.jndi.ldap.LdapCtxFactory
(that is, the default value). connectionURL
-
Specifies the location of the directory server using an LDAP URL, <ldap://Host:Port>. You can optionally qualify this URL by adding a forward slash,
/
, followed by the distinguished name (DN) of a particular node in the directory tree. For example,ldap://ldapserver:10389/ou=system
. The default value isldap://localhost:1024
. connectionUsername
-
The DN of the user that opens the connection to the directory server. For example,
uid=admin,ou=system
. Directory servers generally require clients to present username/password credentials in order to open a connection. connectionPassword
-
The password that matches the DN from
connectionUsername
. In the directory server, in the Directory Information Tree (DIT), the password is normally stored as auserPassword
attribute in the corresponding directory entry. connectionProtocol
- Currently unused. In the future, this option might allow you to select the Secure Socket Layer (SSL) for the connection to the directory server. This option must be set explicitly because it has no default value.
authentication
Specifies the authentication method used when binding to the LDAP server. Valid values for this parameter are
simple
(username and password) ornone
(anonymous). The default value issimple
.NoteSimple Authentication and Security Layer (SASL) authentication is not supported.
Other settings not shown in the preceding configuration example are:
destinationBase
-
Specifies the DN of the node whose children provide the permissions for all destinations. In this case, the DN is a literal value (that is, no string substitution is performed on the property value). For example, a typical value of this property is
ou=destinations,o=ActiveMQ,ou=system
The default value isou=destinations,o=ActiveMQ,ou=system
. filter
-
Specifies an LDAP search filter, which is used when looking up the permissions for any kind of destination. The search filter attempts to match one of the children or descendants of the queue or topic node. The default value is
(cn=*)
. roleAttribute
-
Specifies an attribute of the node matched by
filter
whose value is the DN of a role. The default value isuniqueMember
. adminPermissionValue
-
Specifies a value that matches the
admin
permission. The default value isadmin
. readPermissionValue
-
Specifies a value that matches the
read
permission. The default value isread
. writePermissionValue
-
Specifies a value that matches the
write
permission. The default value iswrite
. enableListener
-
Specifies whether to enable a listener that automatically receives updates made in the LDAP server and update the broker’s authorization configuration in real time. The default value is
true
. mapAdminToManage
Specifies whether to map the legacy (that is, AMQ 6)
admin
permission to the AMQ 7manage
permission. See details of the mapping semantics in the table below. The default value isfalse
.The name of the queue or topic defined in LDAP serves as the "match" for the security setting, the permission value is mapped from the AMQ 6 type to the AMQ 7 type, and the role is mapped as-is. Because the name of the queue or topic defined in LDAP serves as the match for the security setting, the security setting may not be applied as expected to JMS destinations. This is because AMQ 7 always prefixes JMS destinations with "jms.queue." or "jms.topic.", as necessary.
AMQ 6 has three permission types -
read
,write
, andadmin
. These permission types are described on the ActiveMQ website; Security.AMQ 7 has the following permission types:
-
createAddress
-
deleteAddress
-
createDurableQueue
-
deleteDurableQueue
-
createNonDurableQueue
-
deleteNonDurableQueue
-
send
-
consume
-
manage
browse
This table shows how the security settings plugin maps AMQ 6 permission types to AMQ 7 permission types:
Table 5.3. Mapping AMQ 6 permission types to AMQ 7 AMQ 6 permission type AMQ 7 permission type read
consume, browse
write
send
admin
createAddress, deleteAddress, createDurableQueue, deleteDurableQueue, createNonDurableQueue, deleteNonDurableQueue, manage (if
mapAdminToManage
is set totrue
)As described below, there are some cases in which the plugin performs some translation between the AMQ 6 and AMQ 7 permission types to achieve equivalence:
-
The mapping does not include the AMQ 7
manage
permission type by default because there is no analogous permission type in AMQ 6. However, ifmapAdminToManage
is set totrue
, the plugin maps the AMQ 6admin
permission to the AMQ 7manage
permission. -
The
admin
permission type in AMQ 6 determines whether the broker automatically creates a destination if the destination does not exist and the user sends a message to it. AMQ 7 automatically allows automatic creation of a destination if the user has permission to send messages to the destination. Therefore, the plugin maps the legacyadmin
permission to the AMQ 7 permissions shown above, by default. The plugin also maps the AMQ 6admin
permission to the AMQ 7manage
permission ifmapAdminToManage
is set totrue
.
-
The mapping does not include the AMQ 7
-
allowQueueAdminOnRead
Whether or not to map the legacy read permission to the createDurableQueue, createNonDurableQueue, and deleteDurableQueue permissions so that JMS clients can create durable and non-durable subscriptions without needing the admin permission. This was allowed in AMQ 6. The default value is false.
This table shows how the security settings plugin maps AMQ 6 permission types to AMQ 7 permission types when
allowQueueAdminOnRead
istrue
:Table 5.4. Mapping AMQ 6 permission types to AMQ 7 when allowQueueAdminOnRead is true AMQ 6 permission type AMQ 7 permission type read
consume, browse, createDurableQueue, createNonDurableQueue, deleteDurableQueue
write
send
admin
createAddress, deleteAddress, deleteNonDurableQueue, manage (if
mapAdminToManage
is set totrue
)
5.4.3. Encrypting the password in the login.config file
Because organizations frequently securely store data with LDAP, the login.config
file can contain the configuration required for the broker to communicate with the organization’s LDAP server. This configuration file usually includes a password to log in to the LDAP server, so this password needs to be encrypted.
Prerequisites
-
Ensure that you have modified the
login.config
file to add the required properties, as described in Section 5.4.2, “Configuring LDAP authorization”.
Procedure
The following procedure shows how to mask the value of the connectionPassword
parameter found in the <broker_instance_dir>/etc/login.config
file.
From a command prompt, use the
mask
utility to encrypt the password:$ <broker_instance_dir>/bin/artemis mask <password>
result: 3a34fd21b82bf2a822fa49a8d8fa115d
Open the
<broker_instance_dir>/etc/login.config
file. Locate theconnectionPassword
parameter:connectionPassword = <password>
Replace the plain-text password with the encrypted value:
connectionPassword = 3a34fd21b82bf2a822fa49a8d8fa115d
Wrap the encrypted value with the identifier
"ENC()"
:connectionPassword = "ENC(3a34fd21b82bf2a822fa49a8d8fa115d)"
The login.config
file now contains a masked password. Because the password is wrapped with the "ENC()"
identifier, AMQ Broker decrypts it before it is used.
Additional resources
- For more information about the configuration files included with AMQ Broker, see AMQ Broker configuration files and locations.
5.4.4. Mapping external roles
You can map roles from external authentication providers such as LDAP to roles used internally by the broker.
To map external roles, create role-mapping entries in a security-settings
element in the broker.xml
configuration file. For example:
<security-settings> ... <role-mapping from="cn=admins,ou=Group,ou=ActiveMQ,ou=system" to="my-admin-role"/> <role-mapping from="cn=users,ou=Group,ou=ActiveMQ,ou=system" to="my-user-role"/> </security-settings>
- Role mapping is additive. That means the user will keep the original role(s) as well as the newly assigned role(s).
- Role mapping only affects the roles authorizing queue access and does not provide a method to enable web console access.
5.5. Using Kerberos for authentication and authorization
When sending and receiving messages with the AMQP protocol, clients can send Kerberos security credentials that AMQ Broker authenticates by using the GSSAPI mechanism from the Simple Authentication and Security Layer (SASL) framework. Kerberos credentials can also be used for authorization by mapping an authenticated user to an assigned role configured in an LDAP directory or text-based properties file.
You can use SASL in tandem with Transport Layer Security (TLS) to secure your messaging applications. SASL provides user authentication, and TLS provides data integrity.
You must deploy and configure a Kerberos infrastructure before AMQ Broker can authenticate and authorize Kerberos credentials. See your operating system documentation for more information about deploying Kerberos.
- For RHEL 7, see Using Kerberos.
- For Windows, see Kerberos Authentication Overview.
- Users of an Oracle or IBM JDK should install the Java Cryptography Extension (JCE). See the documentation from the Oracle version of the JCE or the IBM version of the JCE for more information.
The following procedures show how to configure Kerberos for authentication and authorization.
5.5.1. Configuring network connections to use Kerberos
AMQ Broker integrates with Kerberos security credentials by using the GSSAPI mechanism from the Simple Authentication and Security Layer (SASL) framework. To use Kerberos in AMQ Broker, each acceptor authenticating or authorizing clients that use a Kerberos credential must be configured to used the GSSAPI mechanism.
The following procedure shows how to configure an acceptor to use Kerberos.
Prerequisites
- You must deploy and configure a Kerberos infrastructure before AMQ Broker can authenticate and authorize Kerberos credentials.
Procedure
Stop the broker.
On Linux:
<broker_instance_dir>/bin/artemis stop
On Windows:
<broker_instance_dir>\bin\artemis-service.exe stop
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. Add the name-value pair
saslMechanisms=GSSAPI
to the query string of the URL for theacceptor
.<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI </acceptor>
The preceding configuration means that the acceptor uses the GSSAPI mechanism when authenticating Kerberos credentials.
(Optional) The
PLAIN
andANONYMOUS
SASL mechanisms are also supported. To specify multiple mechanisms, use a comma-separated list. For example:<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI,PLAIN </acceptor>
The result is an acceptor that uses both the
GSSAPI
andPLAIN
SASL mechanisms.Start the broker.
On Linux:
<broker_instance_dir>/bin/artemis run
On Windows:
<broker_instance_dir>\bin\artemis-service.exe start
Additional resources
- For more information about acceptors, see Section 2.1, “About acceptors”.
5.5.2. Authenticating clients with Kerberos credentials
AMQ Broker supports Kerberos authentication of AMQP connections that use the GSSAPI mechanism from the Simple Authentication and Security Layer (SASL) framework.
A broker acquires its Kerberos acceptor credentials by using the Java Authentication and Authorization Service (JAAS). The JAAS library included with your Java installation is packaged with a login module, Krb5LoginModule
, that authenticates Kerberos credentials. See the documentation from your Java vendor for more information about their Krb5LoginModule
. For example, Oracle provides information about their Krb5LoginModule
login module as part of their Java 8 documentation.
Prerequisites
- You must enable the GSSAPI mechanism of an acceptor before it can authenticate AMQP connections using Kerberos security credentials. For more information, see Section 5.5.1, “Configuring network connections to use Kerberos”.
Procedure
Stop the broker.
On Linux:
<broker_instance_dir>/bin/artemis stop
On Windows:
<broker_instance_dir>\bin\artemis-service.exe stop
-
Open the
<broker_instance_dir>/etc/login.config
configuration file. Add a configuration scope named
amqp-sasl-gssapi
. The following example shows configuration for theKrb5LoginModule
found in Oracle and OpenJDK versions of the JDK.amqp-sasl-gssapi { com.sun.security.auth.module.Krb5LoginModule required isInitiator=false storeKey=true useKeyTab=true principal="amqp/my_broker_host@example.com" debug=true; };
amqp-sasl-gssapi
-
By default, the GSSAPI mechanism implementation on the broker uses a JAAS configuration scope named
amqp-sasl-gssapi
to obtain its Kerberos acceptor credentials. Krb5LoginModule
-
This version of the
Krb5LoginModule
is provided by the Oracle and OpenJDK versions of the JDK. Verify the fully qualified class name of theKrb5LoginModule
and its available options by referring to the documentation from your Java vendor. useKeyTab
-
The
Krb5LoginModule
is configured to use a Kerberos keytab when authenticating a principal. Keytabs are generated using tooling from your Kerberos environment. See the documentation from your vendor for details about generating Kerberos keytabs. principal
-
The Principal is set to
amqp/my_broker_host@example.com
. This value must correspond to the service principal created in your Kerberos environment. See the documentation from your vendor for details about creating service principals.
Start the broker.
On Linux:
<broker_instance_dir>/bin/artemis run
On Windows:
<broker_instance_dir>\bin\artemis-service.exe start
5.5.2.1. Using an alternative configuration scope
You can specify an alternative configuration scope by adding the parameter saslLoginConfigScope
to the URL of an AMQP acceptor. In the following configuration example, the parameter saslLoginConfigScope
is given the value alternative-sasl-gssapi
. The result is an acceptor that uses the alternative scope named alternative-sasl-gssapi
, declared in the <broker_instance_dir>/etc/login.config
configuration file.
<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI,PLAIN;saslLoginConfigScope=alternative-sasl-gssapi` </acceptor>
5.5.3. Authorizing clients with Kerberos credentials
AMQ Broker includes an implementation of the JAAS Krb5LoginModule
login module for use by other security modules when mapping roles. The module adds a Kerberos-authenticated Peer Principal to the Subject’s principal set as an AMQ Broker UserPrincipal. The credentials can then be passed to a PropertiesLoginModule
or LDAPLoginModule
module, which maps the Kerberos-authenticated Peer Principal to an AMQ Broker role.
The Kerberos Peer Principal does not exist as a broker user, only as a role member.
Prerequisites
- You must enable the GSSAPI mechanism of an acceptor before it can authorize AMQP connections using Kerberos security credentials.
Procedure
Stop the broker.
On Linux:
<broker_instance_dir>/bin/artemis stop
On Windows:
<broker_instance_dir>\bin\artemis-service.exe stop
-
Open the
<broker_instance_dir>/etc/login.config
configuration file. Add configuration for the AMQ Broker
Krb5LoginModule
and theLDAPLoginModule
. Verify the configuration options by referring to the documentation from your LDAP provider.An example configuration is shown below.
org.apache.activemq.artemis.spi.core.security.jaas.Krb5LoginModule required ; org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule optional initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory connectionURL="ldap://localhost:1024" authentication=GSSAPI saslLoginConfigScope=broker-sasl-gssapi connectionProtocol=s userBase="ou=users,dc=example,dc=com" userSearchMatching="(krb5PrincipalName={0})" userSearchSubtree=true authenticateUser=false roleBase="ou=system" roleName=cn roleSearchMatching="(member={0})" roleSearchSubtree=false ;
NoteThe version of the
Krb5LoginModule
shown in the preceding example is distributed with AMQ Broker and transforms the Kerberos identity into a broker identity that can be used by other AMQ modules for role mapping.Start the broker.
On Linux:
<broker_instance_dir>/bin/artemis run
On Windows:
<broker_instance_dir>\bin\artemis-service.exe start
Additional resources
- See Section 5.5.1, “Configuring network connections to use Kerberos” for more information about enabling the GSSAPI mechanism in AMQ Broker.
-
See Section 5.2.2.1, “Configuring basic user and password authentication” for more information about
PropertiesLoginModule
. -
See Section 5.4.1, “Configuring LDAP to authenticate clients” for more information about
LDAPLoginModule
.
5.6. Specifying a security manager
The broker uses a component called the security manager to handle authentication and authorization.
AMQ Broker includes two security managers:
-
The
ActiveMQJAASSecurityManager
security manager. This security manager provides integration with JAAS and Red Hat JBoss Enterprise Application Platform (JBoss EAP) security. This is the default security manager used by AMQ Broker. -
The
ActiveMQBasicSecurityManager
security manager. This basic security manager doesn’t support JAAS. Instead, it supports authentication and authorization through user name and password credentials. This security manager supports adding, removing, and updating users using the management API. All user and role data is stored in the broker bindings journal. This means that any changes made to a live broker are also available to its backup broker.
As an alternative to the included security managers, a system administrator might want more control over the implementation of broker security. In this case, it is also possible to specify a custom security manager in the broker configuration. A custom security manager is a user-defined class that implements the org.apache.activemq.artemis.spi.core.security.ActiveMQSecurityManager5
interface.
The examples in the following sub-sections show how to configure the broker to use:
- The basic security manager instead of the default JAAS security manager
- A custom security manager
5.6.1. Using the basic security manager
In addition to the default ActiveMQJAASSecurityManager
security manager, AMQ Broker also includes the ActiveMQBasicSecurityManager
security manager.
When you use the basic security manager, all user and role data is stored in the bindings journal (or the bindings table, if you are using JDBC persistence). Therefore, if you have configured a live-backup broker group, any user management that you peform on the live broker is automatically reflected on the backup broker upon failover. This avoids the need to separately administer an LDAP server, which is the alternative way to achieve this behavior.
Before you configure and use the basic security manager, be aware of the following:
- The basic security manager is not pluggable like the default JAAS security manager.
- The basic security manager does not support JAAS. Instead, it supports only authentication and authorization through user name and password credentials.
-
AMQ Management Console requires JAAS. Therefore, if you use the basic security manager and want to use the console, you also need to configure the
login.config
configuration file for user and password authentication. For more information about configuring user and password authentication, see Section 5.2.2.1, “Configuring basic user and password authentication”. - In AMQ Broker, user management is provided by the broker management API. This management includes the ability to add, list, update, and remove users and roles. You can perform these functions using JMX, management messages, HTTP (using Jolokia or AMQ Management Console), and the AMQ Broker command-line interface. Because the broker directly store this data, the broker must be running in order to manage users. There is no way to manually modify the bindings data.
- Any management access through HTTP (for example, using Jolokia or AMQ Management Console) is handled by the console JAAS login module. MBean access through JConsole or other remote JMX tools is handled by the basic security manager. Management messages are handled by the basic security manager.
5.6.1.1. Configuring the basic security manager
The following procedure shows how to configure the broker to use the basic security manager.
Procedure
-
Open the
<broker-instance-dir>/etc/boostrap.xml
configuration file. In the
security-manager
element, for theclass-name
attribute, specify the fullActiveMQBasicSecurityManager
class name.<broker xmlns="http://activemq.org/schema"> ... <security-manager class-name="org.apache.activemq.artemis.spi.core.security.ActiveMQBasicSecurityManager"> </security-manager> ... </broker>
Because you cannot manually modify the bindings data that holds user and role data, and because the broker must be running to manage users, it is advisable to secure the broker upon first boot. To achieve this, define a bootstrap user whose credentials can then be used to add other users.
In the
security-manager
element, add thebootstrapUser
,bootstrapPassword
, andbootstrapRole
properties and specify values. For example:<broker xmlns="http://activemq.org/schema"> ... <security-manager class-name="org.apache.activemq.artemis.spi.core.security.ActiveMQBasicSecurityManager"> <property key="bootstrapUser" value="myUser"/> <property key="bootstrapPassword" value="myPass"/> <property key="bootstrapRole" value="myRole"/> </security-manager> ... </broker>
bootstrapUser
- Name of the bootstrap user.
bootstrapPassword
- Passsword of the boostrap user. You can also specify an encrypted password.
bootstrapRole
Role of the boostrap user.
NoteIf you define the preceding properties for the bootstrap user in your configuration, those credentials are set each time that you start the broker, regardless of any changes you make while the broker is running.
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. In the
broker.xml
configuration file, locate theaddress-setting
element that is defined by default for theactivemq.management#
address match. These default address settings are shown below.<address-setting match="activemq.management#"> <dead-letter-address>DLQ</dead-letter-address> <expiry-address>ExpiryQueue</expiry-address> <redelivery-delay>0</redelivery-delay> <!--...--> <max-size-bytes>-1</max-size-bytes> <message-counter-history-day-limit>10</message-counter-history-day-limit> <address-full-policy>PAGE</address-full-policy> <auto-create-queues>true</auto-create-queues> <auto-create-addresses>true</auto-create-addresses> <auto-create-jms-queues>true</auto-create-jms-queues> <auto-create-jms-topics>true</auto-create-jms-topics> </address-setting>
Within the address settings for the
activemq.management#
address match, for the bootstrap role name that you specified earlier in this procedure, add the following required permissions:-
createNonDurableQueue
-
createAddress
-
consume
-
manage
-
send
For example:
<address-setting match="activemq.management#"> ... <permission type="createNonDurableQueue" roles="myRole"/> <permission type="createAddress" roles="myRole"/> <permission type="consume" roles="myRole"/> <permission type="manage" roles="myRole"/> <permission type="send" roles="myRole"/> </address-setting>
-
Additional resources
-
For more information about the
ActiveMQBasicSecurityManager
class, see Class ActiveMQBasicSecurityManager in the ActiveMQ Artemis Core API documentation. - To learn how to encrypt passwords in configuration files, see Section 5.9, “Encrypting passwords in configuration files”.
5.6.2. Specifying a custom security manager
The following procedure shows how to specify a custom security manager in your broker configuration.
Procedure
-
Open the
<broker_instance_dir>/etc/boostrap.xml
configuration file. In the
security-manager
element, for theclass-name
attribute, specify the class that is a user-defined implementation of theorg.apache.activemq.artemis.spi.core.security.ActiveMQSecurityManager5
interface. For example:<broker xmlns="http://activemq.org/schema"> ... <security-manager class-name="com.myclass.MySecurityManager"> <property key="myKey1" value="myValue1"/> <property key="myKey2" value="myValue2"/> </security-manager> ... </broker>
Additional resources
-
For more information about the
ActiveMQSecurityManager5
interface, see Interface ActiveMQSecurityManager5 in the ActiveMQ Artemis Core API documentation.
5.6.3. Running the custom security manager example program
AMQ Broker has an example program that demonstrates how to implement a custom security manager. In the example, the custom security manager logs details for authentication and authorization and then passes the details to an instance of ActiveMQJAASSecurityManager
(that is, the default security manager).
The following procedure shows how to run the custom security manager example program.
Prerequisites
- Your machine is set up to run AMQ Broker example programs. For more information, see Running the AMQ Broker examples.
You downloaded the custom security manager example.
Procedure
Navigate to the directory that contains the custom security manager example. The following example assumed that you downloaded the example to a directory called
amq-broker-examples
.$ cd amq-broker-examples/examples/features/standard/security-manager
Run the example.
$ mvn verify
If you prefer to manually create and start a broker instance when running the example program, replace the command in the preceding step with mvn -PnoServer verify
.
Additional resources
-
For more information about the
ActiveMQJAASSecurityManager
class, see Class ActiveMQJAASSecurityManager in the ActiveMQ Artemis Core API documentation.
5.7. Disabling security
Security is enabled by default. The following procedure shows how to disable broker security.
Procedure
-
Open the
<broker_instance_dir>/etc/broker.xml
configuration file. In the
core
element, set the value ofsecurity-enabled
tofalse
.<security-enabled>false</security-enabled>
-
If necessary, specify a new value, in milliseconds, for
security-invalidation-interval
. The value of this property specifies when the broker periodically invalidates secure logins. The default value is10000
.
5.8. Tracking messages from validated users
To enable tracking and logging the origins of messages (for example, for security-auditing purposes), you can use the _AMQ_VALIDATED_USER
message key.
In the broker.xml
configuration file, if the populate-validated-user
option is set to true
, then the broker adds the name of the validated user to the message using the _AMQ_VALIDATED_USER
key. For JMS and STOMP clients, this message key maps to the JMSXUserID
key.
The broker cannot add the validated user name to a message produced by an AMQP JMS client. Modifying the properties of an AMQP message after it has been sent by a client is a violation of the AMQP protocol.
For a user authenticated based on his/her SSL certificate, the validated user name populated by the broker is the name to which the certificate’s Distinguished Name (DN) maps.
In the broker.xml
configuration file, if security-enabled
is false
and populate-validated-user
is true
, then the broker populates whatever user name, if any, that the client provides. The populate-validated-user
option is false
by default.
You can configure the broker to reject a message that doesn’t have a user name (that is, the JMSXUserID
key) already populated by the client when it sends the message. You might find this option useful for AMQP clients, because the broker cannot populate the validated user name itself for messages sent by these clients.
To configure the broker to reject messages without JMSXUserID
set by the client, add the following configuration to the broker.xml
configuration file:
<reject-empty-validated-user>true</reject-empty-validated-user>
By default, reject-empty-validated-user
is set to false
.
5.9. Encrypting passwords in configuration files
By default, AMQ Broker stores all passwords in configuration files as plain text. Be sure to secure all configuration files with the correct permissions to prevent unauthorized access. You can also encrypt, or mask, the plain text passwords to prevent unwanted viewers from reading them.
5.9.1. About encrypted passwords
An encrypted, or masked, password is the encrypted version of a plain text password. The encrypted version is generated by the mask
command-line utility provided by AMQ Broker. For more information about the mask
utility, see the command-line help documentation:
$ <broker_instance_dir>/bin/artemis help mask
To mask a password, replace its plain-text value with the encrypted one. The masked password must be wrapped by the identifier ENC()
so that it is decrypted when the actual value is needed.
In the following example, the configuration file <broker_instance_dir>/etc/bootstrap.xml
contains masked passwords for the keyStorePassword
and trustStorePassword
parameters.
<web bind="https://localhost:8443" path="web" keyStorePassword="ENC(-342e71445830a32f95220e791dd51e82)" trustStorePassword="ENC(32f94e9a68c45d89d962ee7dc68cb9d1)"> <app url="activemq-branding" war="activemq-branding.war"/> </web>
You can use masked passwords with the following configuration files.
- broker.xml
- bootstrap.xml
- management.xml
- artemis-users.properties
-
login.config (for use with the
LDAPLoginModule
)
Configuration files are found at <broker_instance_dir>/etc
.
artemis-users.properties
supports only masked passwords that have been hashed. When a user is created upon broker creation, artemis-users.properties
contains hashed passwords by default. The default PropertiesLoginModule
will not decode the passwords in artemis-users.properties
file but will instead hash the input and compare the two hashed values for password verification. Changing the hashed password to a masked password does not allow access to the AMQ Broker management console.
broker.xml
, bootstrap.xml
, management.xml
, and login.config
support passwords that are masked but not hashed.
5.9.2. Encrypting a password in a configuration file
The following example shows how to mask the value of cluster-password
in the broker.xml
configuration file.
Procedure
From a command prompt, use the
mask
utility to encrypt a password:$ <broker_instance_dir>/bin/artemis mask <password>
result: 3a34fd21b82bf2a822fa49a8d8fa115d
Open the
<broker_instance_dir>/etc/broker.xml
configuration file containing the plain-text password that you want to mask:<cluster-password> <password> </cluster-password>
Replace the plain-text password with the encrypted value:
<cluster-password> 3a34fd21b82bf2a822fa49a8d8fa115d </cluster-password>
Wrap the encrypted value with the identifier
ENC()
:<cluster-password> ENC(3a34fd21b82bf2a822fa49a8d8fa115d) </cluster-password>
The configuration file now contains an encrypted password. Because the password is wrapped with the ENC()
identifier, AMQ Broker decrypts it before it is used.
Additional resources
- For more information about the configuration files included with AMQ Broker, see Section 1.1, “AMQ Broker configuration files and locations”.
5.9.3. Setting a codec key to encrypt and decrypt passwords
A codec is required to encrypt and decrypt passwords. If a custom codec is not configured, the mask
utility uses a default codec to encrypt passwords and AMQ Broker uses the same default codec to decrypt a password. The codec is configured with a default key, which it provides to the underlying encryption algorithm to encrypt and decrypt passwords. Using the default key exposes a risk that the key might be used by a malicious actor to decrypt your passwords.
When you use the mask
utility to encrypt passwords, you can specify you own key string to avoid using the default codec key. You must then set the same key string in the ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY
environment variable, so the broker can decrypt the passwords. Setting the key in an environment variable makes it more secure because it is not persisted in a configuration file. In addition, you can set the key immediately before you start the broker and unset it immediately after the broker starts.
Procedure
Use the
mask
utility to encrypt each password in a configuration file. For thekey
parameter, specify a string of characters with which to encrypt the password. Use the same key string to encrypt each password.$ <broker_instance_dir>/bin/artemis mask --key <key> <password>
WarningEnsure that you keep a record of the key string that you specify when you run the
mask
utility to encrypt passwords. You must configure the same key value in an environment variable to allow the broker to decrypt passwords.For more information about encrypting passwords in configuration files, see Section 5.9.2, “Encrypting a password in a configuration file”.
From a command prompt, set the
ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY
environment variable to the key string that you specified when you encrypted each password.$ export ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY= <key>
Start the broker.
$ ./artemis run
Unset the
ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY
environment variable.$ unset ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY
NoteIf you unset the
ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY
environment variable after you start the broker, you must set it again to the same key string before you start the broker each subsequent time.
5.10. Configuring authentication and authorization caching
By default, AMQ Broker stores information about successful authentication and authorization responses in separate caches. You can change the default number of entries allowed in each cache and the duration for which entries are cached.
-
Open the
<broker-instance-dir>/etc/broker.xml
configuration file. To change the default maximum number of entries,
1000
, allowed in each cache, set theauthentication-cache-size
and theauthorization-cache-size
parameters. For example:<configuration> ... <core> ... <authentication-cache-size>2000</authentication-cache-size> <authorization-cache-size>1500</authorization-cache-size> ... </core> ... </configuration>
NoteIf a cache reaches the limit set, the least recently used entry is removed from the cache.
To change the default duration,
10000
milliseconds, for which entries are cached, set thesecurity-invalidation-interval
parameter. For example:<configuration> ... <core> ... <security-invalidation-interval>20000</security-invalidation-interval> ... </core> ... </configuration>
NoteIf you set the
security-invalidation-interval
parameter to0
, authentication and authorization caching is disabled.