SupportConsoleDevelopersStart a trialContact

Chapter 10. Configuring authorization

You can configure policies to secure messaging resources in your messaging environment. Policies ensure that only authorized users can access messaging endpoints through the router network, and that the resources on those endpoints are used in an authorized way.

10.1. Types of policies

AMQ Interconnect provides the following types of policies to control connection and resource limits:

Global policies
Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all messaging endpoints), and defines how the router should use vhost policies.
Vhost policies
Connection and AMQP resource limits for a router ingress port (called an AMQP virtual host, or vhost). A vhost policy defines what a client using a particular connection can access on any messaging endpoint in the router network.

The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints.

Access to an AMQP resource allowed by policy for a given user connection to a given vhost is granted across the entire router network. Access restrictions are applied only at the router port to which a client is connected and only to resource requests originated by the client.

10.2. How policies enforce connection and resource limits

AMQ Interconnect uses policies to determine whether to permit a connection, and if it is permitted, to apply the appropriate resource limits.

When a client creates a connection to a router, the router first determines whether to allow or deny the connection. This decision is based on the following criteria:

  • Whether the connection will exceed the router’s global connection limit (defined in the global policy)
  • Whether the connection will exceed the vhost’s connection limits (defined in the vhost policy that matches the host to which the connection is directed)

If the connection is allowed, the router assigns the user (the authenticated user name from the connection) to a user group, and enforces the user group’s resource limits for the lifetime of the connection.

10.3. Setting global limits

You can create a global policy to set the incoming connection and message size limits for a router.

Procedure

  • In the /etc/qpid-dispatch/qdrouterd.conf configuration file, add a policy section and set the limits.

    This example sets the incoming connection limit and message size: 

    policy {
    maxConnections: 10000
    maxMessageSize: 2000000
}
    maxConnections
    The total number of concurrent client connections that can be open for this router. This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default (and the maximum) value is 65535.
    maxMessageSize
    The maximum size in bytes of AMQP message transfers allowed for this router as messages enter the router network. This limit is applied to transfers over user connections and to transfers to interior routers from edge routers. This limit is not applied to interior-to-interior router connections. This limit may be overridden by vhost or by vhost user group settings. A value of 0 disables this limit. Administrators are advised not set interior router maximum message sizes so low that edge router management requests or responses are blocked. Administrators are also advised to set edge router maximum message sizes lower than the attached interior router maximum message size.

10.4. Setting connection and resource limits for messaging endpoints

You can define the connection limit and AMQP resource limits for a messaging endpoint by configuring a vhost policy. Vhost policies define what resources clients are permitted to access on a messaging endpoint over a particular connection.

Note

A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the amqp://mybroker.example.com:5672/queue01 URL, the vhost would be mybroker.example.com.

10.4.1. Enabling vhost policies

You must enable the router to use vhost policies before you can create the policies.

Procedure

  • In the /etc/qpid-dispatch/qdrouterd.conf configuration file, add a policy section if one does not exist, and enable vhost policies for the router. 

    policy {
    ...
    enableVhostPolicy: true
    enableVhostNamePatterns: true
    defaultVhost: $default
}
    enableVhostPolicy
    Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is false, which means that the router will not enforce any vhost policies.
    enableVhostNamePatterns
    Enables pattern matching for vhost hostnames. If set to true, you can use wildcards to specify a range of hostnames for a vhost. If set to false, vhost hostnames are treated as literal strings. This means that you must specify the exact hostname for each vhost. The default is false.
    defaultVhost
    The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is $default. If defaultVhost is not defined, then default vhost processing is disabled.

10.4.2. Creating vhost policies

A vhost policy defines the connection limits and resource limits for users connecting to the router from a remote host. You must create one vhost policy for each remote host.

Prerequisites

Vhost policies must be enabled for the router. For more information, see Section 10.4.1, “Enabling vhost policies”.

Procedure

  1. Add a vhost section and define the connection and message size limits for the messaging endpoint.

    The connection limits apply to all users that are connected to the vhost. These limits control the number of users that can be connected simultaneously to the vhost. 

    vhost {
    hostname: example.com
    aliases: example.org, example.net
    maxConnections: 10000
    maxMessageSize: 500000
    maxConnectionsPerUser: 100
    maxConnectionsPerHost: 100
    allowUnknownUser: true
    ...
}
    hostname

    The literal hostname of the vhost (the messaging endpoint) or a pattern that matches the vhost hostname. This vhost policy will be applied to any client connection that is directed to the hostname that you specify. This name must be unique; you can only have one vhost policy per hostname.

    If enableVhostNamePatterns is set to true, you can use wildcards to specify a pattern that matches a range of hostnames. For more information, see Section 10.4.6, “Vhost policy hostname pattern matching rules”.

    aliases

    Alternative literal hostnames or patterns that direct the router to use the settings in this vhost. Alias hostnames that match an incoming connection use the settings defined in the vhost section. In a multi-tenant configuration, a connection to a vhost alias uses the base vhost hostname for the tenant namespace. In this example if a connection is directed to vhost example.org then the settings from the base vhost hostname example.com apply and example.com becomes the tenant namespace. Vhost hostname and aliases settings from all vhosts must be unique.

    If enableVhostNamePatterns is set to true, you can use wildcards to specify a pattern that matches a range of hostname aliases. For more information, see Section 10.4.6, “Vhost policy hostname pattern matching rules”.

    maxConnections
    The global maximum number of concurrent client connections allowed for this vhost. The default is 65535.
    maxMessageSize
    The maximum size in bytes of AMQP message transfers allowed for connections to this vhost. This limit overrides the policy maxMessageSize value and may be overridden by vhost user group settings. A value of 0 disables this limit.
    maxConnectionsPerUser
    The maximum number of concurrent client connections allowed for any user. The default is 65535.
    maxConnectionsPerHost
    The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting). The default is 65535.
    allowUnknownUser
    Whether unknown users (users who are not members of a defined user group) are allowed to connect to the vhost. Unknown users are assigned to the $default user group and receive $default settings. The default is false, which means that unknown users are not allowed.

  2. In the vhost section, beneath the connection settings that you added, add a groups entity to define the resource limits.

    You define resource limits by user group. A user group specifies the messaging resources the members of the group are allowed to access.

    This example shows three user groups: admin, developers, and $default: 

    vhost {
    ...
    groups: {
        admin: {
            users: admin1, admin2
            remoteHosts: 127.0.0.1, ::1
            sources: *
            targets: *
        }
        developers: {
            users: dev1, dev2, dev3
            remoteHosts: *
            sources: myqueue1, myqueue2
            targets: myqueue1, myqueue2
        }
        $default: {
            remoteHosts: *
            allowDynamicSource: true,
            allowAdminStatusUpdate: true,
            sources: myqueue1, myqueue2
            targets: myqueue1, myqueue2
        }
    }
}
    users
    A list of authenticated users for this user group. Use commas to separate multiple users. A user may belong to only one vhost user group.
    remoteHosts
    A list of remote hosts from which the users may connect. A host can be a hostname, IP address, or IP address range. Use commas to separate multiple hosts. To allow access from all remote hosts, specify a wildcard *. To deny access from all remote hosts, leave this attribute blank.
    maxConnectionsPerUser
    The maximum number of connections that may be created by users in this user group. This value, if specified, overrides the vhost maxConnectionsPerUser value.
    maxConnectionsPerHost
    The maximum number of concurrent connections that may be created by users in this user group from any of the permitted remote hosts. This value, if specified, overrides the vhost maxConnectionsPerUser value.
    maxMessageSize
    The maximum size in bytes of AMQP message transfers allowed for connections created by users in this group. This limit overrides the policy and vhost maxMessageSize values. A value of 0 disables this limit.
    allowDynamicSource
    If true, connections from users in this group are permitted to attach receivers to dynamic sources. This permits creation of listeners to temporary addresses or temporary queues. If false, use of dynamic sources is not permitted.
    allowAdminStatusUpdate
    If true, connections from users in this group are permitted to modify the adminStatus of connections. This permits termination of sender or receiver connections. If false, the users of this group are prohibited from terminating any connections. Inter-router connections can never be terminated by any usee. The default is true, even if the policy is not configured.
    allowWaypointLinks
    If true, connections from users in this group are permitted to attach links using waypoint capabilities. This allows endpoints to act as waypoints (that is, brokers) without the need for configuring auto-links. If false, use of waypoint capabilities is not permitted.
    allowDynamicLinkRoutes
    If true, connections from users in this group may dynamically create connection-scoped link route destinations. This allows endpoints to act as link route destinations (that is, brokers) without the need for configuring link routes. If false, creation of dynamic link route destinations is not permitted.
    allowFallbackLinks
    If true, connections from users in this group are permitted to attach links using fallback-link capabilities. This allows endpoints to act as fallback destinations (and sources) for addresses that have fallback enabled. If false, use of fallback-link capabilities is not permitted.
    sources | sourcePattern

    A list of AMQP source addresses from which users in this group may receive messages.

    Use sources to specify one or more literal addresses. To specify multiple addresses, use a comma-separated list. To prevent users in this group from receiving messages from any addresses, leave this attribute blank. To allow access to an address specific to a particular user, specify the ${user} token. For more information, see Section 10.4.5, “Methods for specifying vhost policy source and target addresses”.

    Alternatively, you can use sourcePattern to match one or more addresses that correspond to a pattern. A pattern is a sequence of words delimited by either a . or / character. You can use wildcard characters to represent a word. The * character matches exactly one word, and the # character matches any sequence of zero or more words.

    To specify multiple address ranges, use a comma-separated list of address patterns. For more information, see ]. To allow access to address ranges that are specific to a particular user, specify the ${user} token. For more information, see xref:methods-specifying-vhost-policy-source-target-addresses-router-rhel[.

    targets | targetPattern
    A list of AMQP target addresses from which users in this group may send messages. You can specify multiple AMQP addresses and use user name substitution and address patterns the same way as with source addresses.

  3. If necessary, add any advanced user group settings to the vhost user groups.

    The advanced user group settings enable you to define resource limits based on the AMQP connection open, session begin, and link attach phases of the connection. For more information, see vhost in the qdrouterd.conf man page.

10.4.3. Creating vhost policies as JSON files

As an alternative to using the router configuration file, you can configure vhost policies in JSON files. If you have multiple routers that need to share the same vhost configuration, you can put the vhost configuration JSON files in a location accessible to each router, and then configure the routers to apply the vhost policies defined in these JSON files.

Prerequisites

Procedure

  1. In the /etc/qpid-dispatch/qdrouterd.conf configuration file, specify the directory where you want to store the vhost policy definition JSON files. 

    policy {
    ...
    policyDir: /etc/qpid-dispatch-policies
}
    policyDir
    The absolute path to the directory that holds vhost policy definition files in JSON format. The router processes all of the vhost policies in each JSON file that is in this directory.

  2. In the vhost policy definition directory, create a JSON file for each vhost policy.

    Example 10.1. Vhost Policy Definition JSON File

    [
    ["vhost", {
        "hostname": "example.com",
        "maxConnections": 10000,
        "maxConnectionsPerUser": 100,
        "maxConnectionsPerHost": 100,
        "allowUnknownUser": true,
        "groups": {
            "admin": {
                "users": ["admin1", "admin2"],
                "remoteHosts": ["127.0.0.1", "::1"],
                "sources": "*",
                "targets": "*"
            },
            "developers": {
                "users": ["dev1", "dev2", "dev3"],
                "remoteHosts": "*",
                "sources": ["myqueue1", "myqueue2"],
                "targets": ["myqueue1", "myqueue2"]
            },
            "$default": {
                "remoteHosts": "*",
                "allowDynamicSource": true,
                "sources": ["myqueue1", "myqueue2"],
                "targets": ["myqueue1", "myqueue2"]
            }
        }
    }]
]

    For more information about these attributes, see Section 10.4.2, “Creating vhost policies”.

10.4.4. Setting resource limits for outgoing connections

If a router establishes an outgoing connection to an external AMQP container (such as a client or broker), you can restrict the resources that the external container can access on the router by configuring a connector vhost policy.

The resource limits that are defined in a connector vhost policy are applied to links that are initiated by the external AMQP container. The connector vhost policy does not restrict links that the router creates.

A connector vhost policy can only be applied to a connector with a normal or route-container role. You cannot apply connector vhost policies to connectors that have inter-router or edge roles.

Prerequisites

Procedure

  1. In the /etc/qpid-dispatch/qdrouterd.conf configuration file, add a vhost section with a $connector user group. 

    vhost {
    hostname: my-connector-policy
    groups: {
        $connector: {
            sources: *
            targets: *
            maxSenders: 5
            maxReceivers: 10
            allowAnonymousSender: true
            allowWaypointLinks: true
        }
    }
}
    hostname
    A unique name to identify the connector vhost policy. This name does not represent an actual hostname; therefore, choose a name that will not conflict with an actual vhost hostname.
    $connector
    Identifies this vhost policy as a connector vhost policy. For more information about the resource limits you can apply, see Section 10.4.2, “Creating vhost policies”.

  2. Apply the connector vhost policy to the connector that establishes the connection to the external AMQP container.

    The following example applies the connector vhost policy that was configured in the previous step: 

    connector {
    host: 192.0.2.10
    port: 5672
    role: normal
    policyVhost: my-connector-policy
}

10.4.5. Methods for specifying vhost policy source and target addresses

If you want to allow or deny access to multiple addresses on a vhost, there are several methods you can use to match multiple addresses without having to specify each address individually.

The following table describes the methods a vhost policy can use to specify multiple source and target addresses:

To…​Do this…​

Allow all users in the user group to access all source or target addresses

Use a * wildcard character.

Example 10.2. Receive from any address

sources: *

Prevent all users in the user group from accessing all source or target addresses

Do not specify a value.

Example 10.3. Prohibit message transfers to all addresses

targets:

Allow access to some resources specific to each user

Use the ${user} username substitution token. You can use this token with source, target, sourcePattern, and targetPattern.

Note

You can only specify the ${user} token once in an AMQP address name or pattern. If there are multiple tokens in an address, only the leftmost token will be substituted.

Example 10.4. Receive from a user-specific address

This definition allows the users in the user group to receive messages from any address that meets any of the following rules:

  • Starts with the prefix tmp_ and ends with the user name
  • Starts with the prefix temp followed by any additional characters
  • Starts with the user name, is followed by -home-, and ends with any additional characters 
sources: tmp_${user}, temp*, ${user}-home-*

Example 10.5. User-specific address patterns

This definition allows the users in the user group to receive messages from any address that meets any of the following rules:

  • Starts with the prefix tmp and ends with the user name
  • Starts with the prefix temp followed by zero or more additional characters
  • Starts with the user name, is followed by home, and ends with one or more additional characters 
sourcePattern: tmp.${user}, temp/#, ${user}.home/*
Note

In an address pattern (sourcePattern or targetPattern), the username substitution token must be either the first or last token in the pattern. The token must also be alone within its delimited field, which means that it cannot be concatenated with literal text prefixes or suffixes.

10.4.6. Vhost policy hostname pattern matching rules

In a vhost policy, vhost hostnames can be either literal hostnames or patterns that cover a range of hostnames.

A hostname pattern is a sequence of words with one or more of the following wildcard characters:

  • * represents exactly one word
  • # represents zero or more words

The following table shows some examples of hostname patterns:

This pattern…​Matches…​But not…​

*.example.com

www.example.com

example.comsrv2.www.example.com

#.example.com

example.comwww.example.coma.b.c.d.example.com

myhost.com

www.*.test.example.com

www.a.test.example.com

www.test.example.comwww.a.b.c.test.example.com

www.#.test.example.com

www.test.example.comwww.a.test.example.comwww.a.b.c.test.example.com

test.example.com

Vhost hostname pattern matching applies the following precedence rules:

Policy patternPrecedence

Exact match

High

*

Medium

#

Low

Note

AMQ Interconnect does not permit you to create vhost hostname patterns that conflict with existing patterns. This includes patterns that can be reduced to be the same as an existing pattern. For example, you would not be able to create the #.#.#.#.com pattern if #.com already exists.

10.4.7. Vhost policy examples

These examples demonstrate how to use vhost policies to authorize access to messaging resources.

Example 10.6. Defining basic resource limits for a messaging endpoint

In this example, a vhost policy defines resource limits for clients connecting to the example.com host. 

[
    ["vhost", {
        "hostname": "example.com",  1
        "maxConnectionsPerUser": 10,  2
        "allowUnknownUser": true,  3
        "groups": {
            "admin": {
                "users": ["admin1", "admin2"],  4
                "remoteHosts": ["127.0.0.1", "::1"],  5
                "sources": "*",  6
                "targets": "*"  7
            },
            "$default": {
                "remoteHosts": "*",  8
                "sources": ["news*", "sports*" "chat*"],  9
                "targets": "chat*"  10
            }
        }
    }]
]
1
The rules defined in this vhost policy will be applied to any user connecting to example.com.
2
Each user can open up to 10 connections to the vhost.
3
Any user can connect to this vhost. Users that are not part of the admin group are assigned to the $default group.
4
If the admin1 or admin2 user connects to the vhost, they are assigned to the admin user group.
5
Users in the admin user group must connect from localhost. If the admin user attempts to connect from any other host, the connection will be denied.
6
Users in the admin user group can receive from any address.
7
Users in the admin user group can send to any address.
8
Any non-admin user is permitted to connect from any host.
9
Non-admin users are permitted to receive messages from any addresses that start with the news, sports, or chat prefixes.
10
Non-admin users are permitted to send messages to any addresses that start with the chat prefix.

Example 10.7. Limiting memory consumption

By using the advanced vhost policy attributes, you can control how much system buffer memory a user connection can potentially consume.

In this example, a stock trading site provides services for stock traders. However, the site must also accept high-capacity, automated data feeds from stock exchanges. To prevent trading activity from consuming memory needed for the feeds, a larger amount of system buffer memory is allotted to the feeds than to the traders.

This example uses the maxSessions and maxSessionWindow attributes to set the buffer memory consumption limits for each AMQP session. These settings are passed directly to the AMQP connection and session negotiations, and do not require any processing cycles on the router.

This example does not show the vhost policy settings that are unrelated to buffer allocation. 

[
    ["vhost", {
        "hostname": "traders.com",  1
        "groups": {
            "traders": {
                "users": ["trader1", "trader2"],  2
                "maxFrameSize": 10000,
                "maxSessionWindow": 5000000,  3
                "maxSessions": 1  4
            },
            "feeds": {
                "users": ["nyse-feed", "nasdaq-feed"],  5
                "maxFrameSize": 60000,
                "maxSessionWindow": 1200000000,  6
                "maxSessions": 3  7
            }
        }
    }]
]
1
The rules defined in this vhost policy will be applied to any user connecting to traders.com.
2
The traders group includes trader1, trader2, and any other user defined in the list.
3
At most, 5,000,000 bytes of data can be in flight on each session.
4
Only one session per connection is allowed.
5
The feeds group includes two users.
6
At most, 1,200,000,000 bytes of data can be in flight on each session.
7
Up to three sessions per connection are allowed.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

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

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

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

© 2024 Red Hat, Inc.