<commit_before>////
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License
////

[id='authorizing-access-to-messaging-resources']
= Authorizing Access to Messaging Resources

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.

{RouterName} provides the following types of policies:

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.

== How {RouterName} Enforces Connection and Resource Limits

{RouterName} 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 the 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.

== Setting Global Connection Limits

You can set the incoming connection limit for the router. This limit defines the total number of concurrent client connections that can be open for this router.

.Procedure

* In the router configuration file, add a `policy` section and set the `maxConnections`.
+
--
[options="nowrap",subs="+quotes"]
----
policy {
    maxConnections: 10000
}
----
`maxConnections`::
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`.
--

== 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`.
====

You can create vhost policies using either of the following methods:

* xref:configuring-vhost-policies-router[Configure vhost policies directly in the router configuration file]
* xref:configuring-vhost-policies-json[Configure vhost policies as JSON files]

[id='enabling-vhost-policies']
=== Enabling Vhost Policies

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

.Procedure

* In the router configuration file, add a `policy` section if one does not exist, and enable vhost policies for the router.
+
--
[options="nowrap",subs="+quotes"]
----
policy {
    ...
    enableVhostPolicy: true
    enableVhostNamePatterns: true | false
    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.
--

[id='configuring-vhost-policies-router']
=== Configuring Vhost Policies in the Router Configuration File

You can configure vhost policies in the router configuration file by configuring `vhost` entities. However, if multiple routers in your router network should be configured with the same vhost configuration, you will need to add the vhost configuration to each router’s configuration file.

.Prerequisites

Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies[].

.Procedure

. Add a `vhost` section and define the connection 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.

[options="nowrap",subs="+quotes"]
----
vhost {
    hostname: example.com
    maxConnections: 10000
    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 xref:pattern-matching-vhost-policy-hostnames[].

`maxConnections`::
The global maximum number of concurrent client connections allowed for this vhost. The default is 65535.

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

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

.User Groups in a Vhost Policy
====
This example shows three user groups: admin, developers, and $default:

[options="nowrap",subs="+quotes"]
----
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.

`allowDynamicSource`::
If true, connections from users in this group are permitted to attach receivers to dynamic sources.  This permits creation of listners to temporary addresses or termporary queues.  If false, use of dynamic sources is forbidden.

`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 user under any circumstance. Defaults to true, no policy required.


`allowWaypointLinks`::
If true, connections from users in this group are permitted to attach links using waypoint capabilities.  This allows endpoints to act as waypoints (i.e. brokers) without the need for configuring auto-links.  If false, use of waypoint capabilities is forbidden.

`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 (i.e. brokers) without the need for configuring link-routes.  If false, creation of dynamic link route destintations is forbidden.

`allowFallbackLinks`::<commit_msg>Doc attrs for vhost user group max connections. This closes #616.<commit_after>////
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License
////

[id='authorizing-access-to-messaging-resources']
= Authorizing Access to Messaging Resources

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.

{RouterName} provides the following types of policies:

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.

== How {RouterName} Enforces Connection and Resource Limits

{RouterName} 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 the 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.

== Setting Global Connection Limits

You can set the incoming connection limit for the router. This limit defines the total number of concurrent client connections that can be open for this router.

.Procedure

* In the router configuration file, add a `policy` section and set the `maxConnections`.
+
--
[options="nowrap",subs="+quotes"]
----
policy {
    maxConnections: 10000
}
----
`maxConnections`::
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`.
--

== 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`.
====

You can create vhost policies using either of the following methods:

* xref:configuring-vhost-policies-router[Configure vhost policies directly in the router configuration file]
* xref:configuring-vhost-policies-json[Configure vhost policies as JSON files]

[id='enabling-vhost-policies']
=== Enabling Vhost Policies

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

.Procedure

* In the router configuration file, add a `policy` section if one does not exist, and enable vhost policies for the router.
+
--
[options="nowrap",subs="+quotes"]
----
policy {
    ...
    enableVhostPolicy: true
    enableVhostNamePatterns: true | false
    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.
--

[id='configuring-vhost-policies-router']
=== Configuring Vhost Policies in the Router Configuration File

You can configure vhost policies in the router configuration file by configuring `vhost` entities. However, if multiple routers in your router network should be configured with the same vhost configuration, you will need to add the vhost configuration to each router’s configuration file.

.Prerequisites

Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies[].

.Procedure

. Add a `vhost` section and define the connection 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.

[options="nowrap",subs="+quotes"]
----
vhost {
    hostname: example.com
    maxConnections: 10000
    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 xref:pattern-matching-vhost-policy-hostnames[].

`maxConnections`::
The global maximum number of concurrent client connections allowed for this vhost. The default is 65535.

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

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

.User Groups in a Vhost Policy
====
This example shows three user groups: admin, developers, and $default:

[options="nowrap",subs="+quotes"]
----
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.

`allowDynamicSource`::
If true, connections from users in this group are permitted to attach receivers to dynamic sources.  This permits creation of listners to temporary addresses or termporary queues.  If false, use of dynamic sources is forbidden.

`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 user under any circumstance. Defaults to true, no policy required.


`allowWaypointLinks`::
If true, connections from users in this group are permitted to attach links using waypoint capabilities.  This allows endpoints to act as waypoints (i.e. brokers) without the need for configuring auto-links.  If false, use of waypoint capabilities is forbidden.

`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 (i.e. brokers) without the need for configuring link-routes.  If false, creation of dynamic link route destintations is forbidden.

`allowFallbackLinks`::
{'fraction_non_alphanumeric': 0.054531278664465235, 'fraction_numerical': 0.006191524490919097, 'mean_word_length': 4.215259507294905, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5443843', 'n_tokens_mistral': 5377, 'n_tokens_neox': 5198, 'n_words': 2987}