Remote ActiveMQ authentication and authorization
Haven't set up your remote ActiveMQ instance yet?
Read TORO's page on configuring a remote ActiveMQ instance to see the step-by-step procedures required to successfully deploy a stand-alone version of ActiveMQ and connect it to TORO Integrate.
Oftentimes, access to the message broker and its destinations must be restricted in order to prevent unwarranted incidences like the unauthorized deletion of data. Luckily, ActiveMQ provides "flexible and customizable security models"1 which make integrating with existing environment security policies easier.
Security in ActiveMQ is pluggable and achieved through the use of plugins from providers; two of the most common
of which are the JAAS plugin and the simple authentication plugin2. The simple authentication plugin,
as its name implies, will help us fulfill our authentication requirements. The JAAS plugin, on the other hand, allows us
to manage users and groups without having to modify the
broker.xml file directly (which is required for the
simple authentication plugin).
In this guide, we will see how to set-up a remote ActiveMQ instance's authentication and authorization mechanisms through the aforementioned plugins. There are many other plugins you can use to configure your ActiveMQ instance's security; but at the moment, this is what TORO recommends for those who want to use remote ActiveMQ with TORO Integrate.
Authentication and authorization
Authentication is the process by which the user or system proves its identity to the server or client. This is typically done through the use of username-password combinations and other similar methods like one-time passwords sent to verified devices. Authentication does not determine the capabilities of the user; it only identifies and verifies the user or system requesting access.
Authorization, on the other hand, is the process that determines the privileges of the user or system on a secured resource. It works hand in hand with authentication.
Configuring the ActiveMQ server
The security settings of your ActiveMQ instance should depend on how your organization uses the broker. The procedures below will help you create a simple security configuration for your server using the JAAS authentication plugin and the authorization plugin; modify settings as needed.
Go to ActiveMQ's configuration directory.
activemq.xmlfile and declare the
runtimeConfigurationPluginwill enable modified broker settings to be applied on-the-go while the
jaasAuthenticationPluginwill allow log-ins based on JMS username-password credentials sent by clients.
1 2 3 4
<plugins> <runtimeConfigurationPlugin checkPeriod="1000" /> <jaasAuthenticationPlugin configuration="activemq-domain" /> </plugins>
You may add this bit just underneath the
</managementContext>section. Save and close the file.
This plugin is in charge of monitoring and applying changes from the
broker.xmlfile to the running broker.
Define the JAAS realm.
Simply put, a realm is a 'database' of credentials, identifying the valid users of an application and their roles.3 To define our realm, we will use the
In this example, our
login.configfile will contain the snippet above, which will enable us to make use of Java property files to define users and groups.
reloadattribute which is now set to
truewill work with the
runtimeConfigurationPluginset earlier to give the broker the privilege to update broker settings on the fly.
Save your configuration once done.
Create and populate the Java property files specified in the preceding step. In this case, these files are named
users.properties, as its name implies, will contain the list of users and their passwords, declared using the format:
groups.properties, on the other hand, will contain the list of groups and the users belonging to them. Groups will be declared using the format:
authorizationPluginand define access privileges.
<authorizationEntry />elements to specify access privileges of previously defined groups for every destination (queue or topic). By entering the name of a group in a
readattribute, you allow this group to browse and consume from the destination;
writeallows the sending of messages; and
adminfor the ability to create non-existent destinations lazily.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
<plugins> <!-- ... --> <authorizationPlugin> <map> <authorizationMap> <authorizationEntries> <authorizationEntry topic="jmsPrefix.statistics.>" read="$yourGroup" write="$yourGroup" admin="$yourGroup" /> <authorizationEntry topic="jmsPrefix.io.toro.integrate.>" read="$yourGroup" write="$yourGroup" admin="$yourGroup" /> <authorizationEntry queue="jmsPrefix.io.toro.integrate.>" read="$yourGroup" write="$yourGroup" admin="$yourGroup" /> <authorizationEntry topic="ActiveMQ.Advisory.>" read="$yourGroup" write="$yourGroup" admin="$yourGroup" /> </authorizationEntries> </authorizationMap> </map> </authorizationPlugin> </plugins>
.to separate names in a path and create destination hierarchies;
*to match any name in a path; and
>to select destinations that match the path defined before the symbol.
Authorization entry that affects all destinations?
To create an entry that applies to all topics, the application needs be to configured to have a unique identifier that is prefixed on all of its topics; thereby making it easier to create an entry that matches all destinations using wildcards.
jms.prefixis a TORO Integrate-specific property that is used to prevent destination name collisions. This property is relevant especially when managing multiple TORO Integrate instances. The
jmsPrefixpath in the example
authorizationEntrys above is a modifiable value set via your TORO Integrate instance's application properties.
- Go to the
Run ActiveMQ on a separate terminal, using either the
start(for Windows) or
console(for Unix) command. This will allow us to check through ActiveMQ's logs easily.
$activemq_home/bin/activemq start $activemq_home/bin/activemq console
- Go to the
Verify if your new security configurations were applied. Your
activemq.xmlfile should now roughly look like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
<broker> <!-- ... --> <managementContext> <managementContext createConnector="false"/> </managementContext> <plugins> <jaasAuthenticationPlugin configuration="activemq-domain" /> <runtimeConfigurationPlugin checkPeriod="1000" /> <authorizationPlugin> <map> <authorizationMap> <authorizationEntries> <authorizationEntry topic="jmsPrefix.statistics.>" read="admins" write="admins" admin="admins" /> <authorizationEntry topic="jmsPrefix.io.toro.integrate.>" read="admins" write="admins" admin="admins" /> <authorizationEntry queue="jmsPrefix.io.toro.integrate.>" read="admins" write="admins" admin="admins" /> <authorizationEntry topic="ActiveMQ.Advisory.>" read="admins" write="admins" admin="admins" /> </authorizationEntries> </authorizationMap> </map> </authorizationPlugin> </plugins> <!-- ... --> </broker>
Configuring TORO Integrate
To let TORO Integrate connect to the remote ActiveMQ instance after updating its security policies, we must now edit
its application properties. If you're running on a Server Edition of TORO Integrate, you can
use the Server Admin UI to edit your instance's application properties; else, you must edit the
directly which requires access to the machine's file system.
Write your configurations in
override.properties instead of
toro-integrate.properties file contains the default configuration settings of TORO Integrate. Instead of
directly editing this file and overwriting the default configuration, TORO Integrate allows developers to create
override.properties file. This file takes priority over the
toro-integrate.properties file, overriding
properties already present there; effectively allowing you to retain the default configuration while being able to
customize it using a different file.
The steps below describe how to edit the
override.properties file directly.
Go to TORO Integrate's
Open and edit the
activemq.passwordproperties' values so that it contains the credentials necessary to connect to your remote ActiveMQ instance.
Edit the required
jms.*properties so that TORO Integrate knows the parameters required to connect to the ActiveMQ server.
1 2 3 4 5
# Use 'remote-activemq' instead of 'activemq-external' for versions below v3.1 jms.file=activemq-external jms.clientId=toro-integrate jms.url=tcp://<activemq-ip-address>:61616?closeAsync=true jms.prefix=your-prefix
It is recommended that you make the prefix match the username entered earlier in the
users.propertiesfile to easily track and refer to the topics and resources that will be generated by ActiveMQ.
Restart your TORO Integrate instance to reflect the changes you've made. Check logs if necessary.
Login to ActiveMQ and check if the topics were digested by the broker.
- Access and login as the administrator to ActiveMQ's web console.
- Go to the Topic panel to check.
As mentioned beforehand, you can use the Server Admin UI to edit the application properties instead. To do so:
- First, you must access TORO Integrate using your browser.
- Sign in.
Go to the Configuration menu > Integrate Properties.
From hereon, the following steps should be similar to the steps described above. Editing application properties this way
automatically pushes the changes to
override.properties instead of
Snyder, Bosanac, and Davies. (2011). ActiveMQ in Action. Retrieved from Safari Books Online database. ↩
Apache Tomcat. (n.d.). Realm Configuration HOW-TO. Retrieved January 6, 2019, from https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#What_is_a_Realm? ↩
override.properties, you can use a
.propertiesfile whose name or location differs using the