Chapter 8. Authorization
Abstract
Red Hat AMQ authorization implements group-based access control and allows you to control access at the granularity level of destinations or of individual messages.
8.1. Simple Authorization Plug-In
Overview
In a security system without authorization, every successfully authenticated user would have unrestricted access to every queue and every topic in the broker. Using the simple authorization plug-in, on the other hand, you can restrict access to specific destinations based on a user's group membership.
Configuring the simple authorization plug-in
To configure the simple authorization plug-in, add an
authorizationPlugin
element to the list of plug-ins in the broker's configuration, as shown in Example 8.1, “Simple Authorization Plug-In Configuration”.
Example 8.1. Simple Authorization Plug-In Configuration
<beans> <broker ... > ... <plugins> ... <jaasAuthenticationPlugin configuration="karaf" /> <authorizationPlugin> <map> <authorizationMap groupClass="org.apache.karaf.jaas.boot.principal.RolePrincipal"> <authorizationEntries> <authorizationEntry queue=">" read="admins" write="admins" admin="admins" /> <authorizationEntry queue="USERS.>" read="users" write="users" admin="users" /> <authorizationEntry queue="GUEST.>" read="guests" write="guests,users" admin="guests,users" /> <authorizationEntry topic=">" read="admins" write="admins" admin="admins" /> <authorizationEntry topic="USERS.>" read="users" write="users" admin="users" /> <authorizationEntry topic="GUEST.>" read="guests" write="guests,users" admin="guests,users" /> </authorizationEntries> <tempDestinationAuthorizationEntry> <tempDestinationAuthorizationEntry read="admins" write="admins" admin="admins"/> </tempDestinationAuthorizationEntry> </authorizationMap> </map> </authorizationPlugin> </plugins> ... </broker> </beans>
The simple authorization plug-in is specified as a map of destination entries. The map is entered in the configuration using a
authorizationMap
element wrapped in a map
element.
The authorization map is made up of two elements:
authorizationEntries
—a collection ofauthorizationEntry
elements that define the permissions assigned to authorized users have for destinations whose name matches the selectortempDestinationAuthorizationEntry
—defines the permissions assigned to authorized users have for temporary destinations
Integration with the Apache Karaf authentication module
The simple authorization plug-in was originally designed to work with the Apache ActiveMQ JAAS authentication module and is compatible with that module by default. In order to integrate with the Apache Karaf authentication module, however, it is necessary to set the
groupClass
attribute on the authorizationMap
element.
The
groupClass
attribute defines the type of the class that implements the role principal. For example, in order to reuse roles defined for the Apache Karaf JAAS authentication plug-in, you would need to set this property to org.apache.karaf.jaas.boot.principal.RolePrincipal
(as shown in Example 8.1, “Simple Authorization Plug-In Configuration”).
The default value is
org.apache.activemq.jaas.GroupPrincipal
.
Named destinations
A named destination is an ordinary JMS queue or topic.The authorization entries for ordinary destinations are defined by the
authorizationEntry
element, which supports the following attributes:
queue
ortopic
—specifies the name of the queue or topic to which you are assigning permissions. The greater-than symbol,>
, acts as a name segment wildcard. For example, an entry with,queue="USERS.>"
, would match any queue name beginning with theUSERS.
string.ImportantIn order for the>
wildcard to match multiple segments, it must be preceded by the.
segment-delimiter character. Hence,USERS.>
matches any queue name beginning withUSERS.
, butUSERS>
does not match.read
—specifies a comma-separated list of roles that have permission to consume messages from the matching destinations.write
—specifies a comma-separated list of roles that have permission to publish messages to the matching destinations.admin
—specifies a comma-separated list of roles that have permission to create destinations in the destination subtree.
Temporary destinations
A temporary destination is a special feature of JMS that enables you to create a queue for a particular network connection. The temporary destination exists only as long as the network connection remains open and, as soon as the connection is closed, the temporary destination is deleted on the server side. The original motivation for defining temporary destinations was to facilitate request-reply semantics on a destination, without having to define a dedicated reply destination.
Because temporary destinations have no name, there is only one entry in the map for them. This entry is specified using a
tempDestinationAuthorizationEntry
element the contains a tempDestinationAuthorizationEntry
child element. The permissions set by this entry are for all temporary destinations. The attributes supported by the inner tempDestinationAuthorizationEntry
element are:
read
—specifies a comma-separated list of roles that have permission to consume messages from all temporary destinations.write
—specifies a comma-separated list of roles that have permission to publish messages to all temporary destinations.admin
—specifies a comma-separated list of roles that have permission to create temporary destinations.
Advisory destinations
Advisory destinations are named destinations that Red Hat AMQ uses to communicate administrative information. Networks of brokers also use advisory destinations to coordinate between the brokers.
The authorization entries for advisory destinations are, like ordinary named destinations, defined by the
authorizationEntry
element. For advisory destinations, however, the topic
attribute is always used and the name is always starts with ActiveMQ.Advisory
.
Because advisory destinations are used by networks of brokers and a few other broker services, it is advised that full access permissions be granted for all of the advisory destinations by using an entry similar to Example 8.2, “Setting Access Permissions for Advisory Destinations”.
Example 8.2. Setting Access Permissions for Advisory Destinations
<authorizationEntry topic="ActiveMQ.Advisory.>" read="guests,users" write="guests,users" admin="guests,users" />
If you have specific advisories that you want to secure, you can add individual entries for them.