ActiveMQ 4.x and greater provides pluggable security through various different providers.
The most common providers are
Typically you configure JAAS using a config file like this one and set the java.security.auth.login.config system property to point to it. If no system property is specified then by default the ActiveMQ JAAS plugin will look for login.config on the classpath and use that.
Here is an example login.config which then points to these files
If you have modest authentication requirements (or just want to quickly set up your testing environment) you can use SimpleAuthenticationPlugin. With this plugin you can define users and groups directly in the broker's XML configuration. Take a look at the following snippet for example:
Users and groups defined in this way can be later used with the appropriate authorization plugin.
From version 5.4.0 onwards, you can configure simple authentication plugin to allow anonymous access to the broker.
To allow anonymous access to the broker, use anonymousAccessAllowed attribute and set it to true as shown above. Now, when the client connects without username and password provided, a default username (anonymous) and group (anonymous) will be assigned to its security context. You can use this username and password to authorize client's access to appropriate broker resources (see the next section). You can also change username and group that will be assigned to anonymous users by using anonymousUser and anonymousGroup attributes.
In ActiveMQ we use a number of operations which you can associate with user roles and either individual queues or topics or you can use wildcards to attach to hierarchies of topics and queues.
Queues/Topics can specified using the ActiveMQ Wildcards syntax.
The following example shows these 2 plugins in operation. Though note its very easy to write your own plugin.
Note that full access rights should generally be given to the ActiveMQ.Advisory destinations because by default an ActiveMQConnection uses destination advisories to get early knowledge of temp destination creation and deletion. In addition, dynamic network connectors use advisories to determine consumer demand.
If you have enabled authentication for a particular message broker, then other brokers that wish to connect to that broker must provide the proper authentication credentials via their <networkConnector> element. For example, suppose that we have a network of brokers with the following configuration:
In order for BrokerB to connect to BrokerA, the corresponding <networkConnector> element in BrokerB's XML configuration file must be set up as follows.
Note how BrokerB's <networkConnector> element must provide the proper credentials in order to connect to BrokerA. If authorization has been enabled on BrokerA, then the userName assigned to the <networkConnector> element must also have the proper authorization credentials. Messages cannot be forwarded from BrokerB to BrokerA if BrokerA has authorization enabled and BrokerB's corresponding <networkConnector> element's userName has not been given the proper authorization credentials.
Also, if BrokerA is given a <networkConnector> element so that it can initiate a connection to BrokerB, then that <networkConnector> must be given a userName/password combination that is defined in the <simpleAuthenticationPlugin> element; this is required even though BrokerB does not have authentication services enabled.
To control access to temporary destinations, you will need to add a <tempDestinationAuthorizationEntry> element to the authorizationMap. Through this element, you control access to all temporary destinations. If this element is not present, read, write, and admin privileges for temporary destinations will be granted to all. In the example below, read, write, and admin privileges for temporary destinations are only granted to those clients that have been assigned to the 'admin' group.
1. Configure the JAAS LDAPLoginModule and the LDAPAuthorizationMap in activemq.xml:
2. Configure the JAAS login.config (I haven't de-duplicated the config yet):
3. Import the following LDIF file into the LDAP server:
4. Start up ActiveMQ
5. Test it out
Along with the message broker, you can optionally execute several additional "components", such as Camel and/or the Web console. These components establish connections with the broker; therefore, if you have secured your broker (i.e., enabled authentication), you will have to configure these components in order to have them provide the required security credentials (username, password) when they connect to the broker.
You may have the following Camel context defined in your broker's XML configuration file.
The above configuration is not set up to work within a secure environment.
If the application is running in an OSGi container, add the following line before the CamelContext definition:
This allows any pre-configured instance of the ActiveMQComponent deployed in the container to take precedence on the default ActiveMQComponent.
That is, with the above configuration, Camel will establish a connection with ActiveMQ, but will not provide a username and password. Therefore, when ActiveMQ security is enabled, the above configuration results in a security exception. The exception will be thrown multiple times, because Camel will continue to retry the connection. If you're not using Camel, comment out the above XML code. If you are using Camel, add the following bean definition to your broker's XML configuration:
With the above bean definition, Camel will pass the specified security credentials when it connects to the broker.
If the broker is running in an OSGi container, add the following line after the ActiveMQComponent bean definition:
If you want to use the Web Console with a secured broker, you have to change connectionFactory bean in your webapps/admin/WEB-INF/webconsole-embeded.xml to something like this:
Starting with version 5.3, all of the above configuration details are included in the default ActiveMQ configuration. Also, there is a central place where you can set credentials that these components will use to connect to the broker. Just set your desired username and password in the conf/credentials.properties file, which by default looks like this:
As of version 5.4.1 you can also use Encrypted passwords with your broker
We have a configurable MessageAuthorizationPolicy to allow you to authorize each message using some content based authorization policy of your choosing. To enable this policy configure on the broker directly using the * messageAuthorizationPolicy* property or add it to the XML as follows
All of the various security implementations are implemented as Interceptors so its very easy to add your own custom implementation. Its probably easier to start with one of the simple implementations though if you are using JAAS you could derive from the JAAS implementation.