qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gmur...@apache.org
Subject qpid-dispatch git commit: DISPATCH-1067 - Doc improvements for router policies. This closes #343.
Date Mon, 06 Aug 2018 15:28:33 GMT
Repository: qpid-dispatch
Updated Branches:
  refs/heads/master 6cc87192a -> a53179572


DISPATCH-1067 - Doc improvements for router policies. This closes #343.


Project: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/commit/a5317957
Tree: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/tree/a5317957
Diff: http://git-wip-us.apache.org/repos/asf/qpid-dispatch/diff/a5317957

Branch: refs/heads/master
Commit: a531795723fcf70feb63e8137cec0c1f5c6cf8c2
Parents: 6cc8719
Author: Ben Hardesty <bhardest@redhat.com>
Authored: Tue Jul 10 16:18:14 2018 -0400
Committer: Ganesh Murthy <gmurthy@redhat.com>
Committed: Mon Aug 6 11:27:35 2018 -0400

----------------------------------------------------------------------
 .../user-guide/configuration-security.adoc      | 465 +++++++++++--------
 docs/books/user-guide/routing.adoc              |  10 +-
 .../understand-router-configuration.adoc        | 127 +++++
 3 files changed, 399 insertions(+), 203 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/a5317957/docs/books/user-guide/configuration-security.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/configuration-security.adoc b/docs/books/user-guide/configuration-security.adoc
index e2d1798..8c632a6 100644
--- a/docs/books/user-guide/configuration-security.adoc
+++ b/docs/books/user-guide/configuration-security.adoc
@@ -442,290 +442,367 @@ For more information about these attributes, see xref:adding-sasl-authentication
 
 == Authorizing Access to Messaging Resources
 
-You can restrict the number of user connections, and control access to AMQP messaging resources
by configuring _policies_.
+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.
 
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and _vhost policies_.
+{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 vhost policies), and defines how the router should use vhost 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 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`.
-====
+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.
 
 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
+=== How {RouterName} Enforces Connection and Resource Limits
 
-{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.
+{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)
+* Whether the connection will exceed the router’s global connection limit (defined in the
global policy)
 
-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.
+* 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)
 
-=== Configuring Global Policies
+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.
 
-You can set the incoming connection limit for the router and define how it should use vhost
policies by configuring a global policy.
+=== 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.
+* In the router configuration file, add a `policy` section and set the `maxConnections`.
 +
 --
 [options="nowrap",subs="+quotes"]
 ----
-policy = {
-    maxConnections: 10000  // <1>
-    enableVhostPolicy: true  // <2>
-    policyDir: /etc/qpid-dispatch/policies/  // <3>
-    defaultVhost: $default  // <4>
+policy {
+    maxConnections: 10000
 }
 ----
-<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`.
+`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. 
 
-<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.
+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`.
 ====
 
-<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. This policy rule set is applied to a connection
for which a vhost policy has not otherwise been configured. Processing for the default vhost
is enabled by default and set to select vhost '$default'. To disable default vhost processing
set defaultVhost to blank or do not define a vhost named '$default'.
---
+You can create vhost policies using either of the following methods:
 
-=== Configuring 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]
 
-You configure vhost policies to define the connection limits and AMQP resource limits for
a messaging endpoint.
+[id='enabling-vhost-policies']
+==== Enabling Vhost Policies
 
-A vhost policy consists of the following:
+You must enable the router to use vhost policies before you can create the policies.
 
-* Connection limits
-+
-These limits control the number of users that can be connected to the vhost simultaneously.
+.Procedure
 
-* User groups
+* In the router configuration file, add a `policy` section if one does not exist, and enable
vhost policies for the router.
 +
-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
+--
+[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.
 
-You can use the following methods to configure 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`.
 
-* 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]
+`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.
+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
 
-. In the router configuration file, add a `vhost` section and define the connection limits
for it.
+. 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  // <1>
-    maxConnections: 10000  // <2>
-    maxConnectionsPerUser: 1000  // <3>
-    maxConnectionsPerHost: 1000  // <4>
-    allowUnknownUser: false  // <5>
+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[].
 
-<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`.
+`maxConnections`::
+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`.
+`maxConnectionsPerUser`::
+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`. 
+`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.
 
-<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.
+`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 the necessary
user groups.
+. In the `vhost` section, beneath the connection settings that you added, add a `groups`
entity to define the resource limits.
 +
 --
-A user group defines what messaging resources the members of the group are allowed to access.
+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: {  // <1>
-            users: admin1, admin2  // <2>
-            remoteHosts: 127.0.0.1, ::1  // <3>
-            sources: *  // <4>
-            targets: *  // <5>
-        },
-        ...
+        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
+        }
     }
 }
 ----
+`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.
 
-<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.
+`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.
 
-<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: *
-----
-====
+`sources` | `sourcePattern`::
+A list of AMQP source addresses from which users in this group may receive messages.
 +
-.Restricting Access to All Addresses
-====
-[options="nowrap"]
-----
-sources:
-----
-====
+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 xref:methods-for-specifying-vhost-policy-source-target-addresses[].
 +
-.Allowing Access to Specific Addresses
-====
-[options="nowrap"]
-----
-sources: myaddress01, myaddress02, myaddress03
-----
-====
+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.
 +
-.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
+To specify multiple address ranges, use a comma-separated list of address patterns. For more
information, see xref:router-address-pattern-matching[Router Address Pattern Matching]. To
allow access to address ranges that are specific to a particular user, specify the `${user}`
token. For more information, see xref:methods-for-specifying-vhost-policy-source-target-addresses[].
 
-[options="nowrap"]
-----
-sources: tmp_${user}, temp*, ${user}-home-*
-----
+`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.
 ====
-
-<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.
+. 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 link:{qdrouterdConfManPageUrl}#_vhostUserGroupSettings[Vhost
User Group Settings^].
+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}#_vhost[vhost^]
in the `qdrouterd.conf` man page.
 
 [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.
 
+.Prerequisites
+
+* Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies[].
+
 .Procedure
 
-. Determine where to store the vhost policy JSON files.
+. In the router configuration file, specify the directory where you want to store the vhost
policy definition JSON files.
 +
-The directory should be accessible by each router that needs to apply these vhost policies.
+--
+[options="nowrap",subs="+quotes"]
+----
+policy {
+    ...
+    policyDir: __DIRECTORY_PATH__
+}
+----
+`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.
+--
 
-. 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[].
+. In the vhost policy definition directory, create a JSON file for each vhost policy.
 +
-.Sample Vhost Policy JSON File
+--
+.Vhost Policy Definition JSON File
 ====
 [source,json,options="nowrap"]
 ----
-{
-    "vhost": {    
-        "name": "example.com",        
-        "maxConnectionsPerUser": 100,        
-        "allowUnknownUser": true,        
+[
+    ["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": {    
+            "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 xref:configuring-vhost-policies-router[].
 ====
+--
 
-. 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
+[id='methods-for-specifying-vhost-policy-source-target-addresses']
+==== 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 you can use to specify multiple source and target
addresses for a vhost:
+
+[cols="33,67",options="header"]
+|===
+| To... | Do this...
+
+| Allow all users in the user group to access all source or target addresses on the vhost
+a| Use a `*` wildcard character.
+
+.Receive from Any Address
 ====
-[options="nowrap"]
+[source,options="nowrap"]
 ----
-policy = {
-    maxConnections: 1000
-    enableVhostPolicy: true
-    policyDir: /etc/vhost-policies/ // <1>
-    defaultVhost: $default
-}
+sources: *
 ----
-<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.
+| Prevent all users in the user group from accessing all source or target addresses on the
vhost
+a| Do not specify a value.
 
-=== Example: Configuring a Vhost Policy
+.Prohibit Message Transfers to All Addresses
+====
+[source,options="nowrap"]
+----
+targets:
+----
+====
 
-In this example, a vhost policy defines resource limits for clients connecting to the `example.com`
host.
+| Allow access to some resources specific to each user
+a| Use the `${user}` username substitution token. You can use this token with `source`, `target`,
`sourcePattern`, and `targetPattern`.
 
-.A Vhost Policy in the Router Configuration File
+[NOTE]
 ====
-[options="nowrap"]
+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.
+====
+ 
+.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
+[source,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>
+sources: tmp_${user}, temp*, ${user}-home-*
+----
+====
+
+.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
+[source,options="nowrap"]
+----
+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.
+====
+
+|===
+
+==== Vhost Policy Examples
+
+These examples demonstrate how to use vhost policies to authorize access to messaging resources.
+
+.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.
+
+[source,json,options="nowrap"]
+----
+[
+    ["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`.
@@ -734,57 +811,57 @@ 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.
+<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 send and receive from any address offered by
the vhost.
+<6> Users in the admin user group can receive from any address offered by the vhost.
 
-<7> Any non-admin user is permitted to connect from any host.
+<7> Users in the admin user group can send to any address offered by the vhost.
 
-<8> Non-admin users are permitted to receive messages from any addresses that start
with the `news`, `sports`, or `chat` prefixes.
+<8> Any non-admin user is permitted to connect from any host.
 
-<9> Non-admin users are permitted to send messages to any address that start with the
`chat` prefix.
-====
+<9> Non-admin users are permitted to receive messages from any addresses that start
with the `news`, `sports`, or `chat` prefixes.
 
-=== Example: Using a Vhost Policy to Limit Memory Consumption (Advanced)
+<10> Non-admin users are permitted to send messages to any addresses that start with
the `chat` prefix.
+====
 
+.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 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 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"]
+[source,json,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>
-            ...
+[
+    ["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 `trader-01`, `trader-02`, and any other user defined
in the list.
+<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.
 

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/a5317957/docs/books/user-guide/routing.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/routing.adoc b/docs/books/user-guide/routing.adoc
index b9225ff..417012e 100644
--- a/docs/books/user-guide/routing.adoc
+++ b/docs/books/user-guide/routing.adoc
@@ -224,15 +224,7 @@ A _pattern_ matches an address that corresponds to a pattern. A pattern
is a seq
 +
 The `*` and `#` characters are reserved as wildcards. Therefore, you should not use them
in the message address.
 +
-The following table shows some examples of address patterns:
-+
-[cols="25,75"]
-|===
-| This pattern... | Matches...
-| `news`          | `news`
-| `news/*/sports` | `news/europe/sports` and `news/usa/sports`, but not `news`  or `news/europe/fr/sports`
-| `news/#`        | `news`, `news/europe`, `news/usa`, `news/usa/sports`
-|===
+For more information about creating address patterns, see xref:router-address-pattern-matching[].
 +
 [NOTE]
 ====

http://git-wip-us.apache.org/repos/asf/qpid-dispatch/blob/a5317957/docs/books/user-guide/understand-router-configuration.adoc
----------------------------------------------------------------------
diff --git a/docs/books/user-guide/understand-router-configuration.adoc b/docs/books/user-guide/understand-router-configuration.adoc
index a576f65..4e3111b 100644
--- a/docs/books/user-guide/understand-router-configuration.adoc
+++ b/docs/books/user-guide/understand-router-configuration.adoc
@@ -51,6 +51,133 @@ sectionName {
 }
 ----
 
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to enable you to match
multiple values for certain attributes. However, the syntax varies based on the type of entity
that you are configuring. 
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you might need to use pattern matching to match a
range of addresses rather than a single, literal address. Address patterns match any address
that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are delimited by either
`.` or `/` characters. They also can contain special wildcard characters that represent words:
+
+* `*` represents exactly one word
+* `#` represents zero or more words
+
+.Address Pattern
+====
+This address contains two tokens, separated by the `/` delimiter:
+
+`my/address`
+====
+
+.Address Pattern with Wildcard
+====
+This address contains three tokens. The `*` is a wildcard, representing any single word that
might be between `my` and `address`:
+
+`my/*/address`
+====
+
+The following table shows some address patterns and examples of the addresses that would
match them:
+
+[options="header"]
+|===
+| This pattern... | Matches... | But not...
+
+a| `news/*`
+a| `news/europe`
+
+`news/usa`
+a| `news`
+
+`news/usa/sports`
+
+a| `news/#`
+a| `news`
+
+`news/europe`
+
+`news/usa/sports`
+a| `europe`
+
+`usa`
+
+a| `news/europe/#`
+a| `news/europe`
+
+`news/europe/sports`
+
+`news/europe/politics/fr`
+a| `news/usa`
+
+`europe`
+
+a| `news/*/sports`
+a| `news/europe/sports` 
+
+`news/usa/sports`
+a| `news`
+
+`news/europe/fr/sports`
+
+|===
+
+[id='pattern-matching-vhost-policy-hostnames']
+=== Pattern Matching for Vhost Policy Hostnames
+
+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:
+
+[options="header"]
+|===
+| This pattern... | Matches... | But not...
+
+a| `*.example.com` 
+a| `www.example.com` 
+a| `example.com`
+`srv2.www.example.com`
+
+a| `#.example.com` 
+a| `example.com`
+`www.example.com`
+`a.b.c.d.example.com`
+a| `myhost.com`
+
+a| `www.*.test.example.com`
+a| `www.a.test.example.com`
+a| `www.test.example.com`
+`www.a.b.c.test.example.com`
+
+a| `www.#.test.example.com` 
+a| `www.test.example.com`
+`www.a.test.example.com`
+`www.a.b.c.test.example.com`
+a| `test.example.com`
+|===
+
+Vhost hostname pattern matching applies the following precedence rules:
+
+[options="header"]
+|===
+| Policy pattern | Precedence
+| Exact match | High
+| *           | Medium
+| #           | Low
+|===
+
+[NOTE]
+====
+{RouterName} 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.
+====
+
 [id='methods-for-changing-router-configuration']
 == Changing a Router's Configuration
 


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org


Mime
View raw message