LibraryToggle FramesPrintFeedback

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 20.

Example 20. Simple Authorization Plug-In Configuration

<beans>
  <broker ... >
    ...
    <plugins>
      ...
      <authorizationPlugin>
        <map>
          <authorizationMap>
            <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 of authroizationEntry elements that define the permissions assigned to authorized users have for destinations whose name matches the selector

  • tempDestinationAuthorizationEntry—defines the permissions assigned to authorized users have for temporary destinations

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 or topic—specifies the name of the queue or topic to which you are assigning permissions. The greater-than symbol, >, acts as a wildcard. For example, an entry with, queue="USERS.>", would match any queue name beginning with the USERS. string.

  • 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 Fuse Message Broker 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 21.

Example 21. 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.

Comments powered by Disqus