SupportConsoleDevelopersStart a trialContact

Chapter 10. Configuring role-based security for addresses

ProductShortName} messaging provides a flexible role-based security model for applying permissions to queues based on their addresses. Each address can have one or more associated roles, and each role can enable specific permissions related to queue management, message sending, and message consumption.

The core JBoss EAP messaging server is structured around queues bound to addresses. When a message is sent to an address, the server identifies all queues mapped to that address and routes the message accordingly.

Address-based permissions can be defined using exact address names or wildcard patterns. Wildcards include * for single-level matching and # for multi-level matching. For more information on wildcard syntax, see Address Settings.

You can create multiple roles for each security-setting, and there are 7 permission settings that can be applied to a role. Below is the complete list of the permissions available:

create-durable-queue
Allows the role to create a durable queue under matching addresses.
delete-durable-queue
Allows the role to delete a durable queue under matching addresses.
create-non-durable-queue
Allows the role to create a non-durable queue under matching addresses.
delete-non-durable-queue
Allows the role to delete a non-durable queue under matching addresses.
send
Allows the role to send a message to matching addresses.
consume
Allows the role to consume a message from a queue bound to matching addresses.
manage
Allows the role to invoke management operations by sending management messages to the management address.

Procedure

  1. Create a security-setting for an address or address pattern. The following example creates a security-setting for news.europe.#, applying to all destinations beginning with news.europe.: 

    /subsystem=messaging-activemq/server=default/security-setting=news.europe.#:add()
{"outcome" => "success"}

  2. Add a role to the security-setting and enable specific permissions. The following example creates the dev role with permissions to send and consume messages, and to create and delete non-durable queues: 

    /subsystem=messaging-activemq/server=default/security-setting=news.europe.#/role=dev:add(consume=true,delete-non-durable-queue=true,create-non-durable-queue=true,send=true)
{"outcome" => "success"}

  3. Create an additional role with different permissions. The following example creates an admin role with durable queue management and the ability to send management messages: 

    /subsystem=messaging-activemq/server=default/security-setting=news.europe.#/role=admin:add(manage=true,create-durable-queue=true,delete-durable-queue=true)
{"outcome" => "success"}

  4. Confirm the configuration of a security-setting, use the management CLI. Use the recursive=true option to get the full display of permissions: 

    /subsystem=messaging-activemq/server=default:read-children-resources(child-type=security-setting,recursive=true)
{
    "outcome" => "success",
    "result" => {
        "#" => {"role" => {"guest" => {
            "consume" => true,
            "create-durable-queue" => false,
            "create-non-durable-queue" => true,
            "delete-durable-queue" => false,
            "delete-non-durable-queue" => true,
            "manage" => false,
            "send" => true
        }}},
        "news.europe.#" => {"role" => {
            "dev" => {
                "consume" => true,
                "create-durable-queue" => false,
                "create-non-durable-queue" => true,
                "delete-durable-queue" => false,
                "delete-non-durable-queue" => true,
                "manage" => false,
                "send" => true
            },
            "admin" => {
                "consume" => false,
                "create-durable-queue" => true,
                "create-non-durable-queue" => false,
                "delete-durable-queue" => true,
                "delete-non-durable-queue" => false,
                "manage" => true,
                "send" => false
            }
        }}
    }

    The permissions for all addresses starting with news.europe. are shown. Only users with the admin role can create or delete durable queues, while only users with the dev role can create or delete non-durable queues. The dev role also enables sending and consuming messages, whereas users with the admin role can send management messages but cannot send or consume normal messages.

    Address-based matching is hierarchical and non-inheriting. When multiple address patterns match, the most specific match takes precedence. Permissions are not inherited, so you can restrict permissions at deeper address patterns simply by omitting them. For example, the pattern news.europe.tech.uk.# is more specific than news.europe.tech.#, allowing deeper-level restrictions.

    For more information on configuring the security manager, see the JBoss EAP Security Architecture guide.

Because an ObjectMessage can contain potentially dangerous objects, Artemis provides a simple class filtering mechanism to control which packages and classes are to be trusted and which are not. You can add objects whose classes are from trusted packages to a allow list to indicate they can be deserialized without a problem. You can add objects whose classes are from untrusted packages to a block list to prevent them from being deserialized.

Artemis filters objects for deserialization as follows.

  • If both the allow list and the block list are empty, which is the default, any serializable object is allowed to be deserialized.
  • If an object’s class or package matches one of the entries in the block list, it is not allowed to be deserialized.
  • If an object’s class or package matches an entry in the allow list, it is allowed to be deserialized.
  • If an object’s class or package matches an entry in both the block list and the allow list, the one in block list takes precedence, meaning it is not allowed to be deserialized.
  • If an object’s class or package matches neither the block list nor the allow list, the object deserialization is denied, unless the allow list is empty, meaning there is no allow list specified.

An object is considered a match if its full name exactly matches one of the entries in the list, if its package matches one of the entries in the list, or if it is a subpackage of one of the entries in the list.

You can specify which objects can be deserialized on a connection-factory and on a pooled-connection-factory using the deserialization-allow-list and deserialization-block-list attributes. The deserialization-allow-list attribute is used to define the list of classes or packages that are allowed to be deserialized. The deserialization-block-list attribute is used to define the list of classes or packages that are not allowed to be deserialized.

The following commands create a block list for the RemoteConnectionFactory connection factory and a allow list for the activemq-ra pooled connection factory for the default server. 

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=deserialization-block-list,value=[my.untrusted.package,another.untrusted.package])
/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=deserialization-allow-list,value=[my.trusted.package])

These commands generate the following configuration in the messaging-activemq subsystem. 

<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" deserialization-block-list="my.untrusted.package another.untrusted.package"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" deserialization-allow-list="my.trusted.package" transaction="xa"/>

For information about connection factories and pooled connection factories, see Configuring Connection Factories in this guide.

You can also specify which objects can be deserialized in an MDB by configuring the activation properties. The deserializationWhiteList property is used to define the list of classes or packages that are allowed to be deserialized. The deserializationBlackList property is used to define the list of classes or packages that are not allowed to be deserialized. For more information about activation properties, see Configuring MDBs Using a Deployment Descriptor in Developing Jakarta Enterprise Beans Applications for JBoss EAP.

10.2. Authorization invalidation management
Copy link

The security-invalidation-interval attribute on the server in the messaging-activemq subsystem determines how long an authorization is cached before an action must be re-authorized.

When the system authorizes a user to perform an action at an address, the authorization is cached. The next time the same user performs the same action at the same address, the system uses the cached authorization for the action.

For example, the user admin attempts to send a message to the address news. The system authorizes the action, and caches the authorization. The next time admin attempts to send a message to news, the system uses the cached authorization.

If the cached authorization is not used again within the time specified by the invalidation interval, the authorization is cleared from the cache. The system must re-authorize the user to perform the requested action at the requested address.

After installation, JBoss EAP assumes a default value of 10000 milliseconds (10 seconds). 

/subsystem=messaging-activemq/server=default:read-attribute(name=security-invalidation-interval)
{
    "outcome" => "success",
    "result" => 10000L
}

The security-invalidation-interval attribute is configurable. For example, the following command updates the interval to 60000 milliseconds (60 seconds or one minute). 

/subsystem=messaging-activemq/server=default:write-attribute(name=security-invalidation-interval,value=60000)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

You must reload the server for the modification of the configuration to take effect.

Reading the attribute shows the new result. 

/subsystem=messaging-activemq/server=default:read-attribute(name=security-invalidation-interval)
{
    "outcome" => "success",
    "result" => 60000L
}
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top