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