Chapter 9. Configuring security
Secure the messaging-activemq subsystem by configuring authentication, transport-layer security, and role-based permissions. Secure remote connections and control access to messaging destinations.
9.1. Securing remote connections Copy linkLink copied to clipboard!
The recommended method for securing the messaging-activemq subsystem in JBoss EAP 8.x is to use the Elytron subsystem. Elytron security domains provide a unified security framework for enforcing authentication and authorization on remote messaging connections.
- Securing the transport
The default
http-connectorthat comes bundled with JBoss EAP messaging is not secured by default. You can secure the message transport and enable web traffic for SSL/TLS by following the instructions to configure one-way and two-way SSL/TLS for applications in How to Configure Server Security for JBoss EAP.NoteThe above approach to secure a message transport also works for securing the
http-acceptor.When you configure the transport as described above, you must perform the following additional steps.
-
By default, all HTTP acceptors are configured to use the default
http-listener, which listens on the HTTP port. You must configure HTTP acceptors to use thehttps-listener, which listens on the HTTPS port. -
The
socket-bindingelement for all HTTP connectors must be updated to usehttpsinstead ofhttp. -
Each
http-connectorthat communicates through SSL/TLS must set thessl-enabledparameter totrue. -
If an HTTP connector is used to connect to another server, you must configure the related parameters such as
trust-storeandkey-store. Securing thehttp-connectorrequires that you configure the same parameters as you do with aremote-connector, which is documented Securing a remote connector.
-
By default, all HTTP acceptors are configured to use the default
- Securing a remote connector
If you are not using the default
http-connectorand have instead created your ownremote-connectorandremote-acceptorfor TCP communications, you can configure each for SSL/TLS by using the properties in the table below. The properties appear in the configuration as part of the child<param>elements of the acceptor or connector.Typically, a server owns its private SSL/TLS key and shares its public key with clients. In this scenario, the server defines the
key-store-pathandkey-store-passwordparameters in aremote-acceptor. Since each client can have its truststore located at a different location, and be encrypted by a different password, specifying thetrust-store-pathandtrust-store-passwordproperties on theremote-connectoris not recommended. Instead, configure these parameters on the client side using the system propertiesjavax.net.ssl.trustStoreandjavax.net.ssl.trustStorePassword. The parameters you need to configure for aremote-connectoraressl-enabled=trueanduseDefaultSslContext=true. However, if the server usesremote-connectorto connect to another server, it makes sense in this case to set thetrust-store-pathandtrust-store-passwordparameters of theremote-connector.In the above use case, the
remote-acceptorwould be created using the following management CLI command:/subsystem=messaging-activemq/server=default/remote-acceptor=mySslAcceptor:add(socket-binding=netty,params={ssl-enabled=true, key-store-path=PATH/TO/server.jks, key-store-password=${VAULT::server-key::key-store-password::sharedKey}})To create the
remote-connectorfrom the above use case, use the following management CLI command:/subsystem=messaging-activemq/server=default/remote-connector=mySslConnector:add(socket-binding=netty,params={ssl-enabled=true, useDefaultSslContext=true})The management CLI also allows you to add a parameter to an already existing
remote-acceptororremote-connectoras well:/subsystem=messaging-activemq/server=default/remote-connector=myOtherSslConnector:map-put(name=params,key=ssl-enabled,value=true)Note that the
remote-acceptorandremote-connectorboth reference asocket-bindingto declare the port to be used for communication. See the Overview of the Messaging Subsystem Configuration for more information on socket bindings and their relationship to acceptors and connectors.Expand Table 9.1. SSL/TLS-related configuration properties for the NettyConnectorFactory Property Description enabled-cipher-suites
Can be used to configure an acceptor or connector. This is a comma separated list of cipher suites used for SSL/TLS communication. The default value is null which means the JVM’s default will be used.
enabled-protocols
Can be used to configure an acceptor or connector. This is a comma separated list of protocols used for SSL/TLS communication. The default value is null which means the JVM’s default will be used.
key-store-password
When used on an acceptor, this is the password for the server-side keystore.
When used on a connector, this is the password for the client-side keystore. This is only relevant for a connector if you are using two-way SSL/TLS. Although this value can be configured on the server, it is downloaded and used by the client.
If the client needs to use a different password from that set on the server, it can override the server-side setting by either using the standard
javax.net.ssl.keyStorePasswordsystem property. Use theorg.apache.activemq.ssl.keyStorePasswordproperty if another component on the client is already making use of the standard system property.key-store-path
When used on an acceptor, this is the path to the SSL/TLS keystore on the server which holds the server’s certificates. Use for certificates either self-signed or signed by an authority.
When used on a connector, this is the path to the client-side SSL/TLS keystore which holds the client certificates. This is only relevant for a connector if you are using two-way SSL/TLS.
Although this value is configured on the server, it is downloaded and used by the client. If the client needs to use a different path from that set on the server, it can override the server-side setting by using the standard
javax.net.ssl.keyStoresystem property. Use theorg.apache.activemq.ssl.keyStoresystem property if another component on the client is already making use of the standard property.key-store-provider
Defines the format of the file in which keys are stored, PKCS11 or PKCS12 for example. The accepted values are JDK specific.
needs-client-auth
This property is only for an acceptor. It tells a client connecting to this acceptor that two-way SSL/TLS is required. Valid values are
trueorfalse. Default isfalse.ssl-enabled
Must be
trueto enable SSL/TLS. Default isfalse.trust-store-password
When used on an acceptor, this is the password for the server-side truststore. This is only relevant for an acceptor if you are using two-way SSL/TLS.
When used on a connector, this is the password for the client-side truststore. Although this value can be configured on the server, it is downloaded and used by the client.
If the client needs to use a different password from that set on the server, it can override the server-side setting by using either the standard
javax.net.ssl.trustStorePasswordsystem property. Use theorg.apache.activemq.ssl.trustStorePasswordsystem property if another component on the client is already making use of the standard property.trust-store-path
When used on an acceptor, this is the path to the server-side SSL/TLS keystore that holds the keys of all the clients that the server trusts. This is only relevant for an acceptor if you are using two-way SSL/TLS.
When used on a connector, this is the path to the client-side SSL/TLS keystore which holds the public keys of all the servers that the client trusts. Although this value can be configured on the server, it is downloaded and used by the client.
If the client needs to use a different path from that set on the server, it can override the server-side setting by using either the standard
javax.net.ssl.trustStoresystem property. Use theorg.apache.activemq.ssl.trustStoresystem property if another component on the client is already making use of the standard system property.trust-store-provider
Defines the format of the file in which keys are stored, PKCS11 or PKCS12 for example. The accepted values are JDK specific.
9.2. Securing destinations Copy linkLink copied to clipboard!
In addition to securing remote connections into the messaging server, you can also configure security around specific destinations. This is done by adding a security constraint using the security-setting configuration element. JBoss EAP messaging comes with a security-setting configured by default, as shown in the output from the following management CLI command:
/subsystem=messaging-activemq/server=default:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
....
"security-setting" => {"#" => {"role" => {"guest" => {
"consume" => true,
"create-durable-queue" => false,
"create-non-durable-queue" => true,
"delete-durable-queue" => false,
"delete-non-durable-queue" => true,
"manage" => false,
"send" => true
}}}}
}
}
The security-setting option makes use of wildcards in the name field to handle which destinations to apply the security constraint. The value of a single # will match any address. For more information on using wildcards in security constraints, see Role Based Security for Addresses.