Repository: qpid-dispatch Updated Branches: refs/heads/master 0acbc8335 -> 7e16c4e87
DISPATCH-333 - Create new doc on policies: * Added new Authorization section to Security chapter * Removed old policies content * Updated policy configuration attribute descriptions This closes #255 Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/7e16c4e8 Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/7e16c4e8 Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/7e16c4e8 Branch: refs/heads/master Commit: 7e16c4e8785f39730608bf14d0575c266b3abe10 Parents: 0acbc83 Author: Ben Hardesty <bhard...@redhat.com> Authored: Fri Jan 26 17:02:29 2018 -0500 Committer: Ganesh Murthy <gmur...@redhat.com> Committed: Tue Mar 6 12:14:23 2018 -0500 ---------------------------------------------------------------------- doc/new-book/attributes.adoc | 3 + doc/new-book/book.adoc | 3 - doc/new-book/configuration-security.adoc | 385 ++++++++++++++++++++- doc/new-book/policy.adoc | 366 -------------------- python/qpid_dispatch/management/qdrouter.json | 40 +-- 5 files changed, 395 insertions(+), 402 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/7e16c4e8/doc/new-book/attributes.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/attributes.adoc b/doc/new-book/attributes.adoc index 6492bff..bfdd03d 100644 --- a/doc/new-book/attributes.adoc +++ b/doc/new-book/attributes.adoc @@ -64,6 +64,9 @@ under the License :qdrouterdManPageUrl: {BookUrlBase}/man/qdrouterd.html :qdrouterdManPageLink: link:{qdrouterdManPageUrl}[qdrouterd man page] +:qdrouterdConfManPageUrl: {BookUrlBase}/man/qdrouterd.conf.html +:qdrouterdConfManPageLink: link:{qdrouterdManPageUrl}[qdrouterd.conf man page] + :qdstatManPageUrl: {BookUrlBase}/man/qdstat.html :qdstatManPageLink: link:{qdstatManPageUrl}[qdstat man page] http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/7e16c4e8/doc/new-book/book.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/book.adoc b/doc/new-book/book.adoc index f84a1c2..3ce170f 100644 --- a/doc/new-book/book.adoc +++ b/doc/new-book/book.adoc @@ -45,9 +45,6 @@ include::routing.adoc[leveloffset=+1] // Logging include::logging.adoc[leveloffset=+1] -// Policies -include::policy.adoc[leveloffset=+1] - // Management include::management.adoc[leveloffset=+1] http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/7e16c4e8/doc/new-book/configuration-security.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/configuration-security.adoc b/doc/new-book/configuration-security.adoc index 9341f7e..f727700 100644 --- a/doc/new-book/configuration-security.adoc +++ b/doc/new-book/configuration-security.adoc @@ -20,18 +20,20 @@ under the License [[security_config]] = Security +Securing your router network involves configuring authentication and authorization. You can authenticate and encrypt the router's connections using SSL/TLS or SASL. Additionally, you can authorize access to messaging resources by setting user connection restrictions and defining AMQP resource access control. + +== Authenticating Remote Peers + You can configure {RouterName} to communicate with clients, routers, and brokers in a secure way by authenticating and encrypting the router's connections. {RouterName} supports the following security protocols: * _SSL/TLS_ for certificate-based encryption and mutual authentication * _SASL_ for authentication and payload encryption [[setting_up_ssl_for_encryption_and_authentication]] -== Setting Up SSL/TLS for Encryption and Authentication +=== Setting Up SSL/TLS for Encryption and Authentication Before you can secure incoming and outgoing connections using SSL/TLS encryption and authentication, you must first set up the SSL/TLS profile in the router's configuration file. -// This section assumes that you only need to set up a single SSL profile. Are there scenarios in which customers might need multiple SSL profiles? Would you typically use a single SSL profile for all incoming and outgoing connections, or would you use separate profiles? - .Prerequisites You must have the following files in PEM format: @@ -118,7 +120,7 @@ For information about additional `sslProfile` attributes, see xref:router_config -- [[setting_up_sasl_for_authentication_and_payload_encryption]] -== Setting Up SASL for Authentication and Payload Encryption +=== Setting Up SASL for Authentication and Payload Encryption If you plan to use SASL to authenticate connections, you must first add the SASL attributes to the `router` entity in the router's configuration file. These attributes define a set of SASL parameters that can be used by the router's incoming and outgoing connections. @@ -171,7 +173,7 @@ saslConfigName: qdrouterd_sasl -- [[securing_incoming_connections]] -== Securing Incoming Connections +=== Securing Incoming Connections You can secure incoming connections by configuring each connection's `listener` entity for encryption, authentication, or both. @@ -187,7 +189,7 @@ Before securing incoming connections, the security protocols you plan to use sho * xref:adding_sasl_payload_encryption_to_incoming_connection[Add SASL payload encryption] [[adding_ssl_encryption_to_incoming_connection]] -=== Adding SSL/TLS Encryption to an Incoming Connection +==== Adding SSL/TLS Encryption to an Incoming Connection You can configure an incoming connection to accept encrypted connections only. By adding SSL/TLS encryption, to connect to this router, a remote peer must first start an SSL/TLS handshake with the router and be able to validate the server certificate received by the router during the handshake. @@ -211,7 +213,7 @@ listener { -- [[adding_sasl_authentication_to_incoming_connection]] -=== Adding SASL Authentication to an Incoming Connection +==== Adding SASL Authentication to an Incoming Connection You can configure an incoming connection to authenticate the client using SASL. You can use SASL authentication with or without SSL/TLS encryption. @@ -237,7 +239,7 @@ For a full list of supported Cyrus SASL authentication mechanisms, see link:http -- [[adding_ssl_client_authentication_to_incoming_connection]] -=== Adding SSL/TLS Client Authentication to an Incoming Connection +==== Adding SSL/TLS Client Authentication to an Incoming Connection You can configure an incoming connection to authenticate the client using SSL/TLS. @@ -264,7 +266,7 @@ listener { -- [[adding_sasl_payload_encryption_to_incoming_connection]] -=== Adding SASL Payload Encryption to an Incoming Connection +==== Adding SASL Payload Encryption to an Incoming Connection If you do not use SSL/TLS, you can still encrypt the incoming connection by using SASL payload encryption. @@ -290,7 +292,7 @@ For a full list of supported Cyrus SASL authentication mechanisms, see link:http -- [[securing_outgoing_connections]] -== Securing Outgoing Connections +=== Securing Outgoing Connections You can secure outgoing connections by configuring each connection's `connector` entity for encryption, authentication, or both. @@ -304,7 +306,7 @@ Before securing outgoing connections, the security protocols you plan to use sho * xref:adding_sasl_authentication_to_outgoing_connection[Add SASL authentication] [[adding_ssl_authentication_to_outgoing_connection]] -=== Adding SSL/TLS Client Authentication to an Outgoing Connection +==== Adding SSL/TLS Client Authentication to an Outgoing Connection If an outgoing connection connects to an external client configured with mutual authentication, you should ensure that the outgoing connection is configured to provide the external client with a valid security certificate during the SSL/TLS handshake. @@ -327,7 +329,7 @@ connector { -- [[adding_sasl_authentication_to_outgoing_connection]] -=== Adding SASL Authentication to an Outgoing Connection +==== Adding SASL Authentication to an Outgoing Connection You can configure an outgoing connection to provide authentication credentials to the external container. You can use SASL authentication with or without SSL/TLS encryption. @@ -354,7 +356,7 @@ For a full list of supported Cyrus SASL authentication mechanisms, see link:http -- [[integrating_with_kerberos]] -== Integrating with Kerberos +=== Integrating with Kerberos By using the `GSSAPI` SASL mechanism, you can configure {RouterName} to authenticate incoming connections using Kerberos. @@ -412,3 +414,360 @@ listener { For more information about these attributes, see xref:adding_sasl_authentication_to_incoming_connection[]. -- + +== Authorizing Access to Messaging Resources + +You can restrict the number of user connections, and control access to AMQP messaging resources by configuring _policies_. + +=== Types of Policies + +You can configure two different types of policies: _global policies_ and _vhost policies_. + +Global policies:: +Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all vhost policies), and defines how the router should use vhost policies. + +Vhost policies:: +Connection and AMQP resource limits for a messaging endpoint (called an AMQP virtual host, or _vhost_). A vhost policy defines what a client can 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`. +==== + +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. + +=== How {RouterName} Applies Policies + +{RouterName} uses both global and vhost 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. + +=== Configuring Global Policies + +You can set the incoming connection limit for the router and define how it should use vhost policies by configuring a global policy. + +.Procedure + +* In the router configuration file, add a `policy` section. ++ +-- +[options="nowrap",subs="+quotes"] +---- +policy = { + maxConnections: 10000 // <1> + enableVhostPolicy: true // <2> + policyDir: /etc/qpid-dispatch/policies/ // <3> + defaultVhost: $default // <4> +} +---- +<1> The maximum number of concurrent client connections allowed 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`. + +<2> 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. ++ +[NOTE] +==== +Setting `enableVhostPolicy` to `false` improves the router's performance. +==== + +<3> The absolute path to a directory that holds vhost policy definition files in JSON format (`*.json`). The router processes all of the vhost policies in each JSON file that is in this directory. For more information, see xref:configuring-vhost-policies-json[]. + +<4> 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. +-- + +=== Configuring Vhost Policies + +You configure vhost policies to define the connection limits and AMQP resource limits for a messaging endpoint. + +A vhost policy consists of the following: + +* Connection limits ++ +These limits control the number of users that can be connected to the vhost simultaneously. + +* User groups ++ +A user group defines the messaging resources that the group members are permitted to access. Each user group defines the following: + +** A set of users that can connect to the vhost (the group members) +** The remote hosts from which the group members may connect to the router network +** The AMQP resources that the group members are permitted to access on the vhost + +You can use the following methods to configure vhost policies: + +* 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='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. + +.Procedure + +. In the router configuration file, add a `vhost` section and define the connection limits for it. ++ +-- +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 // <1> + maxConnections: 10000 // <2> + maxConnectionsPerUser: 1000 // <3> + maxConnectionsPerHost: 1000 // <4> + allowUnknownUser: false // <5> + ... +} +---- + +<1> The host name of the vhost. This vhost policy will be applied to any client connection that is directed to the hostname that you specify. + +<2> The global maximum number of concurrent client connections allowed for this vhost. The default is `65535`. + +<3> The maximum number of concurrent client connections allowed for any user. The default is `65535`. + +<4> The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting). The default is `65535`. + +<5> 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 the necessary user groups. ++ +-- +A user group defines what messaging resources the members of the group are allowed to access. + +[options="nowrap",subs="+quotes"] +---- +vhost { + ... + groups: { + admin: { // <1> + users: admin1, admin2 // <2> + remoteHosts: 127.0.0.1, ::1 // <3> + sources: * // <4> + targets: * // <5> + }, + ... + } +} +---- + +<1> The name of the user group. + +<2> 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. + +<3> 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. + +<4> A list of AMQP source addresses from which users in this group may receive messages. To specify multiple AMQP addresses, separate the addresses with either a comma or a space. If you do not specify any addresses, users in this group are not allowed to receive messages from any addresses. ++ +You can use the substitution token `{user}` to specify an AMQP address that contains a user's authenticated user name. This enables you to allow access to resources specific to each user in the user group without having to name each user individually. You can only specify the `{user}` token once in an AMQP address name. If there are multiple tokens in an address, only the leftmost token will be substituted. ++ +You can use an asterisk (`*`) wildcard to match one or more characters in an AMQP address. However, this wildcard is only recognized if it is the last character in the address name. ++ +.Allowing Access to All Addresses +==== +[options="nowrap"] +---- +sources: * +---- +==== ++ +.Restricting Access to All Addresses +==== +[options="nowrap"] +---- +sources: +---- +==== ++ +.Allowing Access to Specific Addresses +==== +[options="nowrap"] +---- +sources: myaddress01, myaddress02, myaddress03 +---- +==== ++ +.Allowing Access to User-Specific Addresses +==== +This definition allows access to 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 + +[options="nowrap"] +---- +sources: tmp_{user}, temp*, {user}-home-* +---- +==== + +<5> 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 wildcards the same way as with source addresses. +-- + +. If necessary, add any advanced user group settings to the vhost user group. ++ +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 link:{qdrouterdConfManPageUrl}#_vhostUserGroupSettings[Vhost User Group Settings^]. + +[id='configuring-vhost-policies-json'] +==== Configuring 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. + +.Procedure + +. Determine where to store the vhost policy JSON files. ++ +The directory should be accessible by each router that needs to apply these vhost policies. + +. In the directory you determined, create a JSON file for each vhost policy. ++ +The vhost policy is configured the same way as a `vhost` entity in the router configuration file, only using JSON syntax. For more information about vhost policy attributes, see xref:configuring-vhost-policies-router[]. ++ +.Sample Vhost Policy JSON File +==== +[source,json,options="nowrap"] +---- +{ + "vhost": { + "name": "example.com", + "maxConnectionsPerUser": 100, + "allowUnknownUser": true, + "groups": { + "admin": { + "users": ["admin1", "admin2"], + "sources": "*", + "targets": "*" + }, + "developers": { + "users": ["dev1", "dev2", "dev3"], + "remoteHosts": "*", + "sources": ["myqueue1", "myqueue2"], + "targets": ["myqueue1", "myqueue2"] + } + } + } +} +---- +==== + +. In the router configuration file, locate the `policy` entity and set the `policyDir` attribute to point to the directory where the vhost policy JSON files are stored. ++ +.A `policy` Entity +==== +[options="nowrap"] +---- +policy = { + maxConnections: 1000 + enableVhostPolicy: true + policyDir: /etc/vhost-policies/ // <1> + defaultVhost: $default +} +---- +<1> The absolute path to a directory that holds vhost policy definition files in JSON format (*.json). The router processes all of the vhost policies in each JSON file that is in this directory. +==== + +. Repeat the previous step for each additional router that should use the vhost policies located in the vhost policy directory. + +=== Example: Configuring a Vhost Policy + +In this example, a vhost policy defines resource limits for clients connecting to the `example.com` host. + +.A Vhost Policy in the Router Configuration File +==== +[options="nowrap"] +---- +vhost { + name: example.com // <1> + maxConnectionsPerUser: 10 // <2> + allowUnknownUser: true // <3> + groups: { + admin: { + users: admin-01, admin-02 // <4> + remoteHosts: 127.0.0.1, ::1 // <5> + sources: * // <6> + targets: * // <6> + }, + $default: { + remoteHosts: * // <7> + sources: news*, sports*, chat* // <8> + targets: chat* // <9> + } + } +} +---- + +<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 `admin-01` or `admin-02` 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 send and receive from any address offered by the vhost. + +<7> Any non-admin user is permitted to connect from any host. + +<8> Non-admin users are permitted to receive messages from any addresses that start with the `news`, `sports`, or `chat` prefixes. + +<9> Non-admin users are permitted to send messages to any address that start with the `chat` prefix. +==== + +=== Example: Using a Vhost Policy to Limit Memory Consumption (Advanced) + +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 examples 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. + +.A Vhost Policy to Limit Memory Consumption +==== +[options="nowrap"] +---- +vhost { + name: traders.com // <1> + groups: { + traders: { + users: trader-1, trader-2, ... // <2> + maxFrameSize: 10000 // <3> + maxSessionWindow: 5000000 // <3> + maxSessions: 1 // <4> + ... + }, + feeds: { + users: nyse-feed, nasdaq-feed // <5> + maxFrameSize: 60000 // <6> + 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 `trader-01`, `trader-02`, 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. +==== http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/7e16c4e8/doc/new-book/policy.adoc ---------------------------------------------------------------------- diff --git a/doc/new-book/policy.adoc b/doc/new-book/policy.adoc deleted file mode 100644 index 075e3f8..0000000 --- a/doc/new-book/policy.adoc +++ /dev/null @@ -1,366 +0,0 @@ -//// -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 -//// - -[[policy]] -= Policy - -The Policy module is an optional authorization mechanism enforcing -user connection restrictions and AMQP resource access control. - -Policy is assigned when a connection is created. The connection -properties *AMQP virtual host*, *authenticated user name*, and *connection -remote host* are passed to the policy engine for a connection -allow/deny decision. If the connection is allowed then the user is -assigned to a group that names a set of AMQP resource limits that are -enforced for the lifetime of the connection. - -[NOTE] -==== -Policy limits are applied only to incoming user network connections. -Policy limits are not applied to interrouter connections nor are they -applied to router connections outbound to waypoints. -==== - -== Definitions - -=== vhost - -A _vhost_ is typically the name of the host to which the client AMQP -connection is directed. For example, suppose a client application opens -connection URL: - -[options="nowrap"] ----- -amqp://bigbroker.example.com:5672/favorite_subject ----- - -The client will signal virtual host name _bigbroker.example.com_ to -the router during AMQP connection startup. Router Policy intercepts -the virtual host _bigbroker.example.com_ and applies a vhost policy -with that name to the connection. - -== Policy Features - -=== Total Connection Limit - -A router may be configured with a total connection limit. This limit -controls the maximum number of simultaneous incoming user connections -that are allowed at any time. It protects the router from file -descriptor resource exhaustion in the face of many incoming client -connections. This limit is specified and enforced independently of -any other Policy settings. - -=== Vhost Policy - -Vhost policy defines users and assigns them to user groups. Each -user group defines the remote hosts from which the members may connect -to the router network, and what resources in the router network the -group members are allowed to access. - -Vhost policy also defines connection count limits to control the -number of users that may be simultaneously connected to the vhost. - -[NOTE] -==== -A vhost user may be assigned to one user group only. -==== - -=== Default Vhost - -A default vhost may be defined. The default vhost policy is used for -connections whose vhost is otherwise not defined in the policy database. - -xref:example2[Example 2] illustrates how the default vhost feature can -be used to apply a single vhost policy set of restrictions to any -number of vhost connections. - -== Policy Schema - -Policy configuration is specified in two schema objects. - -[options="nowrap"] ----- -policy = { - <global settings> -} - -vhost = { - id: vhost-name - <connection limits> - groups: { - group-name: { - <user group settings> - } - } -} ----- - -The _policy_ object is a singleton. Multiple _vhost_ objects may be -created as needed. - -=== Global Policy - -[options="header", cols="35,15,50"] -|==== -| attribute | default | description -| maxConnections | 65535 | Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined. This limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. -| enableVhostPolicy | false | Enable vhost policy connection denial, and resource limit enforcement. -| policyDir | "" | Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed. -| defaultVhost | "$default" | Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of _defaultVhost_ or by not defining a _vhost_ object named _$default_. -|==== - -=== Vhost Policy - -[options="header", cols="35,15,50"] -|==== -| attribute | default | description -| id | | Vhost name must be unique. -| maxConnections | 65535 | Maximum number of concurrent client connections allowed. -| maxConnectionsPerUser | 65535 | Maximum number of concurrent client connections allowed for any user. -| maxConnectionsPerRemoteHost | 65535 | Maximum number of concurrent client connections allowed for any remote host. -| allowUnknownUser | false | Allow unknown users who are not members of a defined user group. Unknown users are assigned to the '$default' user group and receive '$default' settings. -| groups | | A map where each key is a user group name and the value is a Vhost User Group Settings map. -|==== - -=== Vhost User Group Settings Map - -This object is the data value contained in entries in the policy/groups map. - -[options="header", cols="35,15,50"] -|==== -| Section/Attribute | default | description -| *Group Membership* | | -| users | "" | Comma separated list of authenticated users in this group. -| *Connection Restrictions* | | -| remoteHosts | "" | List of remote hosts from which the users may connect. List values may be host names, numeric IP addresses, numeric IP address ranges, or the wildcard '*'. An empty list denies all access. -| *AMQP Connection Open Limits* | | -| maxFrameSize | 2^31-1 | Largest frame that may be sent on this connection. (AMQP Open, max-frame-size) -| maxSessions | 65535 | Maximum number of sessions that may be created on this connection. (AMQP Open, channel-max) -| *AMQP Session Begin Limits* | | -| maxSessionWindow | 2^31-1 |Incoming capacity for new sessions. (AMQP Begin, incoming-window) -| *AMQP Link Attach* | | -| maxMessageSize | 0 | Largest message size supported by links created on this connection. If this field is zero there is no maximum size imposed by the link endpoint. (AMQP Attach, max-message-size) -| maxSenders | 2^31-1 | Maximum number of sending links that may be created on this connection. -| maxReceivers | 2^31-1 | Maximum number of receiving links that may be created on this connection. -| allowDynamicSource | false | This connection is allowed to create receiving links using the Dynamic Link Source feature. -| allowAnonymousSender | false | This connection is allowed to create sending links using the Anonymous Sender feature. -| allowUserIdProxy | false | This connection is allowed to send messages with a user_id property that differs from the connection's authenticated user id. -| sources | "" | List of Source addresses allowed when creating receiving links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access. -| targets | "" | List of Target addresses allowed when creating sending links. This list may be expressed as a CSV string or as a list of strings. An empty list denies all access. -|==== - -== Policy Wildcard and User Name Substitution - -Policy provides several conventions to make writing rules easier. - -=== Remote Host Wildcard - -Remote host rules may consist of a single asterisk character to -specify all hosts. - -[options="nowrap"] ----- - remoteHosts: * ----- - -The asterisk must stand alone and cannot be appended to a host name -or to an IP address fragment. - -=== AMQP Source and Target Wildcard and Name Substitution - -The rule definitions for `sources` and `targets` may include the username -substitution token - -[options="nowrap"] ----- - {user} ----- - -or a trailing asterisk. - -The username substitution token is replaced with the authenticated user name for -the connection. Using this token, an administrator may allow access to -some resources specific to each user without having to name each user -individually. This token is substituted once for the leftmost -occurrence in the link name. - -The asterisk is recognized only if it is the last character in the -link name. - -[options="nowrap"] ----- - sources: tmp_{user}, temp*, {user}-home-* ----- - -== Composing Policies - -This section shows policy examples designed to illustrate some common use cases. - -=== Example 1. User Policy Disabled - -Policy is disabled when no policy configuation objects are defined. -Any number of connections are allowed and all users have -access to all AMQP resources in the network. - -[[example2]] -=== Example 2. All Users Have Simple Connection Limits - -This example shows how to keep users from overwhelming the router with -connections. Any user can create up to ten connections and the router -will limit the aggregated user connection count to 100 connections -total. No other restrictions apply. - -This example also shows how to use a default vhost policy effectively. -Only one vhost policy is defined and all user connections regardless -of the requested vhost use that policy. - -[options="nowrap"] ----- -policy { - maxConnections: 100 <1> -} - -vhost { - name: $default <2> - maxConnectionsPerUser: 10 <3> - allowUnknownUser: true <4> - groups: { - $default: { - remoteHosts: * <5> - sources: * <6> - targets: * <6> - } - } -} ----- - -<1> The global maxConnections limit of 100 is enforced. -<2> No normal vhost names are defined; user is assigned to default vhost '$default'. -<3> The vhost maxConnectionsPerUser limit of 10 is enforced. -<4> No groups are defined to have any users but allowUnknownUser is true so all users are assigned to group $default. -<5> The user is allowed to connect from any remote host. -<6> The user is allowed to connect to any source or target in the AMQP network. Router system-wide values are used for the other AMQP settings that are unspecified in the vhost rules. - -=== Example 3. Admins Must Connect From Localhost - -This example shows how an admin group may be created and restricted -to accessing a vhost only from localhost. The admin users are allowed -to connect to any AMQP resources while normal users are restricted. - -In this example a user connects to vhost 'example.com'. - -[options="nowrap"] ----- -vhost { - name: example.com <1> - allowUnknownUser: true <3> - groups: { - admin: { - users: alice, bob <2> - remoteHosts: 127.0.0.1, ::1 <4> - sources: * <5> - targets: * <5> - }, - $default: { - remoteHosts: * <6> - sources: news*, sports*, chat* <7> - targets: chat* <7> - } - } -} ----- - -<1> A connection to vhost 'example.com' locates this vhost rule set. -<2> If one of users _alice_ or _bob_ is connecting then she or he is assigned to the 'admin' user group. -<3> Any other user is not defined by a user group. However, since the _allowUnknownUser_ setting is true then this user is assigned to the '$default' user group. -<4> Users in the 'admin' user group must connect from localhost. Connections for an 'admin' user from other hosts on the network are denied. -<5> Users in the 'admin' user group are allowed to access any resource offered by the vhost service. -<6> Other users are allowed to connect from any host. -<7> Other users have source and target name lists that restrict the resources they are allowed to access. - -=== Example 4. Limiting Possible Memory Consumption - -Policy provides a mechanism to control how much system buffer memory a -user connection can potentially consume. The formula for computing -buffer memory consumption for each session is - -[optons="nowrap"] ----- - potential buffer usage = maxFrameSize * maxSessionWindow ----- - -By adjusting _maxFrameSize_, _maxSessions_, and _maxSessionWindow_ an -administrator can prevent a user from consuming too much memory by -buffering messages in flight. - -[NOTE] -==== -The settings passed into the AMQP protocol connection and session -negotiations. Normal AMQP session flow control limits buffer -consumption in due course with no processing cycles required by the -router. -==== - -In this example normal users, the traders, are given smaller buffer -allocations while high-capacity, automated data feeds are given a -higher buffer allocation. This example skips the details of settings -unrelated to buffer allocation. - -[options="nowrap"] ----- -vhost { - name: traders.com <1> - groups: { - traders: { - users: trader-1, trader-2, ... <2> - maxFrameSize: 10000 <3> - maxSessionWindow: 500 <3> - maxSessions: 1 <4> - ... - }, - feeds: { - users: nyse-feed, nasdaq-feed <5> - maxFrameSize: 60000 <6> - maxSessionWindow: 20000 <6> - maxSessions: 3 <7> - ... - } - } -} ----- - -<1> These rules are for vhost traders.com. -<2> The 'traders' group includes trader-1, trader-2, and any other user defined in the list. -<3> _maxFrameSize_ and _maxSessionWindow_ allow for at most 5,000,000 bytes of data to be in flight on each session. -<4> Only one session per connection is allowed. -<5> In the 'feeds' group two users are defined. -<6> _maxFrameSize_ and _maxSessionWindow_ allow for at most 1,200,000,000 bytes of data to be in flight on each session. -<7> Up to three sessions per connection are allowed. - -//// - -- Should we used signed ints for limits to allow for magic values? - -- In example 3, alice and bob cannot connect from an outside server and - get the $default settings. - -- Limits are enforced per router, so a vhost policy of maxConnections - 10 across 10 routers will allow 100 connections to that vhost. - -//// http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/7e16c4e8/python/qpid_dispatch/management/qdrouter.json ---------------------------------------------------------------------- diff --git a/python/qpid_dispatch/management/qdrouter.json b/python/qpid_dispatch/management/qdrouter.json index a661795..fbae3f0 100644 --- a/python/qpid_dispatch/management/qdrouter.json +++ b/python/qpid_dispatch/management/qdrouter.json @@ -1525,28 +1525,28 @@ "maxConnections": { "type": "integer", "default": 65535, - "description": "Global maximum number of concurrent client connections allowed. This limit is always enforced even if no other policy settings have been defined.", + "description": "The maximum number of concurrent client connections allowed 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.", "required": false, "create": true }, "enableVhostPolicy": { "type": "boolean", "default": false, - "description": "Enable vhost policy user groups, connection denial, and resource limit enforcement", + "description": "Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies.", "required": false, "create": true }, "policyDir": { "type": "path", "default": "", - "description": "Absolute path to a directory that holds vhost definition .json files. All vhost definitions in all .json files in this directory are processed.", + "description": "The absolute path to a directory that holds vhost policy definition files in JSON format (*.json). The router processes all of the vhost policies in each JSON file that is in this directory.", "required": false, "create": true }, "defaultVhost": { "type": "string", "default": "$default", - "description": "Vhost rule set name to use for connections with a vhost that is otherwise not defined. Default vhost processing may be disabled either by erasing the definition of defaultVhost or by not defining a vhost object named '$default'.", + "description": "The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. If 'defaultVhost' is not defined, then default vhost processing is disabled.", "required": false, "create": true }, @@ -1571,7 +1571,7 @@ "maxConnections": { "type": "integer", "default": 65535, - "description": "Maximum number of concurrent client connections allowed.", + "description": "The global maximum number of concurrent client connections allowed for this vhost.", "required": false, "create": true, "update": true @@ -1579,7 +1579,7 @@ "maxConnectionsPerUser": { "type": "integer", "default": 65535, - "description": "Maximum number of concurrent client connections allowed for any single user.", + "description": "The maximum number of concurrent client connections allowed for any user.", "required": false, "create": true, "update": true @@ -1587,14 +1587,14 @@ "maxConnectionsPerHost": { "type": "integer", "default": 65535, - "description": "Maximum number of concurrent client connections allowed for any remote host.", + "description": "The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting).", "required": false, "create": true, "update": true }, "allowUnknownUser": { "type": "boolean", - "description": "Unrestricted users, those who are not members of a defined user group, are allowed to connect to this application. Unrestricted users are assigned to the 'default' user group and receive 'default' settings.", + "description": "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.", "default": false, "required": false, "create": true, @@ -1616,79 +1616,79 @@ "attributes": { "users": { "type": "string", - "description": "CSV string or list of authenticated user names. A user may belong to one vhost user group only.", + "description": "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.", "required": true }, "remoteHosts": { "type": "string", - "description": "CSV string of numeric host IP addresses or address ranges from which the users may connect.", + "description": "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.", "required": true }, "maxFrameSize": { "type": "integer", - "description": "Largest frame that may be sent on this connection. Non-zero policy values overwrite values specified for a listener object. (AMQP Open, max-frame-size)", + "description": "The largest frame, in bytes, that may be sent on this connection. Non-zero policy values overwrite values specified for a listener object (AMQP Open, max-frame-size).", "default": 16384, "required": false, "create": true }, "maxSessionWindow": { "type": "integer", - "description": "Largest incoming window in octets for sessions created on this connection. Non-zero policy values overwrite values specified for a listener object. (AMQP Begin, incoming-window)", + "description": "The incoming capacity for new AMQP sessions, measured in octets. Non-zero policy values overwrite values specified for a listener object (AMQP Begin, incoming-window).", "default": 1638400, "required": false, "create": true }, "maxSessions": { "type": "integer", - "description": "Maximum number of sessions that may be created on this connection. Non-zero policy values overwrite values specified for a listener object. (AMQP Open, channel-max)", + "description": "The maximum number of sessions that may be created on this connection. Non-zero policy values overwrite values specified for a listener object (AMQP Open, channel-max).", "default": 32768, "required": false, "create": true }, "maxSenders": { "type": "integer", - "description": "Maximum number of sending links that may be created on this connection. Zero disables all sender links.", + "description": "The maximum number of sending links that may be created on this connection. A value of '0' disables all sender links.", "default": 2147483647, "required": false, "create": true }, "maxReceivers": { "type": "integer", - "description": "Maximum number of receiving links that may be created on this connection. Zero disables all receiver links.", + "description": "The maximum number of receiving links that may be created on this connection. A value of '0' disables all receiver links.", "default": 2147483647, "required": false, "create": true }, "allowDynamicSource": { "type": "boolean", - "description": "This connection is allowed to use the Dynamic Link Source feature.", + "description": "Whether this connection is allowed to create dynamic receiving links (links to resources that do not exist on the peer). A value of 'true' means that users are able to automatically create resources on the peer system.", "default": false, "required": false, "create": true }, "allowAnonymousSender": { "type": "boolean", - "description": "This connection is allowed to use the Anonymous Sender feature.", + "description": "Whether this connection is allowed to create sending links if the sender does not provide a target address. By prohibiting anonymous senders, the router only needs to verify once, when the link is created, that the sender is permitted to send messages to the target address. The router does not need to verify each message that is sent on the link. A value of 'true' means that users may send messages to any address. Allowing anonymous senders can also decrease performance: if the sender does not specify a target address, then the router must parse each message to determine how to route it.", "default": false, "required": false, "create": true }, "allowUserIdProxy": { "type": "boolean", - "description": "This connection is allowed to send messages with a user_id property that differs from the connection authenticated user name.", + "description": "Whether this connection is allowed to send messages with a user ID that is different than the connection's authenticated user name.", "default": false, "required": false, "create": true }, "sources": { "type": "string", - "description": "CSV list of Source addresses allowed when creating receiving links.", + "description": "A list of source addresses from which users in this group may receive messages. To specify multiple addresses, separate the addresses with either a comma or a space. If you do not specify any addresses, users in this group are not allowed to receive messages from any addresses. You can use the substitution token '{user}' to specify an address that contains a user's authenticated user name. You can use an asterisk ('*') wildcard to match one or more characters in an address. However, this wildcard is only recognized if it is the last character in the address name.", "required": false, "create": true }, "targets": { "type": "string", - "description": "CSV list of Target addresses allowed when creating sending links.", + "description": "A list of target addresses from which users in this group may send messages. To specify multiple addresses, separate the addresses with either a comma or a space. If you do not specify any addresses, users in this group are not allowed to send messages from any addresses. You can use the substitution token '{user}' to specify an address that contains a user's authenticated user name. You can use an asterisk ('*') wildcard to match one or more characters in an address. However, this wildcard is only recognized if it is the last character in the address name.", "required": false, "create": true } --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@qpid.apache.org For additional commands, e-mail: commits-h...@qpid.apache.org
