이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 7. Authorization


Abstract

Red Hat JBoss A-MQ authorization implements group-based access control and allows you to control access at the granularity level of destinations or of individual messages.

7.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 7.1, “Simple Authorization Plug-In Configuration”.

Example 7.1. 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 name segment wildcard. For example, an entry with, queue="USERS.>", would match any queue name beginning with the USERS. string.
    Important
    In order for the > wildcard to match multiple segments, it must be preceded by the . segment-delimiter character. Hence, USERS.> matches any queue name beginning with USERS., but USERS> 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 JBoss A-MQ 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 7.2, “Setting Access Permissions for Advisory Destinations”.

Example 7.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.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.