ActiveMQ(5.10.0) - Destination-level authorization

To build upon authentication, consider a use case requiring more fine-grained control over clients to authorize certain tasks. ActiveMQ provides two levels of authorization: operation-level authorization and message-level authorization. These two types of authorization provide a more detailed level of control than simple authentication. This section discusses these two types of authorization and walks through some examples to demonstrate each.

There are three types of user-level operations with JMS destinations:

• Read — The ability to receive messages from the destination
• Write — The ability to send messages to the destination
• Admin — The ability to administer the destination

Through these well-known operations, you can control the ability to perform the operations. Using the ActiveMQ XML configuration file, such authorization can be easily defined. Take a look at the following listing to add some operation-specific authorization to some destinations.

...
<plugins>
    <plugins>
        <jaasAuthenticationPlugin configuration="activemq-domain"/>
    </plugins>    
    <authorizationPlugin>
        <map>
            <authorizationMap>
                <authorizationEntries>
                    <authorizationEntry queue=">" read="admins" write="admins" admin="admins"/>
                    <authorizationEntry queue="EXAMPLE.>" read="consumers" write="producers" admin="producers"/>
                    <authorizationEntry queue="EXAMPLE.HelloQueue" read="guests"/>
                    <authorizationEntry topic="ActiveMQ.Advisory.>" 
                        read="admins,producers,consumers,guests" 
                        write="admins,producers,consumers,guests" 
                        admin="admins,producers,consumers,guests"/>
                </authorizationEntries>
            </authorizationMap>
        </map>
    </authorizationPlugin>
</plugins>
...

In the listing, the JAAS authorization plug-in has been defined and pointed at the activemq-domain configuration in the login.config file. It has also been provided with a map of authorization entries. When configuring the map of authorization entries, the first task is to define the destination to be secured. This is achieved through the use of either a topic or a queue attribute on the entry. The next task is to declare which users and/or groups have privileges for operations on that destination.

A handy feature is the ability to define the destination value using wildcards. For example, EXAMPLE.> means the entry applies to all destinations in the EXAMPLE path recursively. Also, the authorization operations will accept either a single group or a comma-separated list of groups as a value.

Considering this explanation, the configuration used in the previous example can be translated as follows:

• Users from the admins group have full access to all queues
• Consumers can consume and producers can send messages to the destinations in the EXAMPLE path
• Guests can only consume from the EXAMPLE.HelloQueue queue