Chapter 7. 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.
7.1. Authenticating Remote Peers
You can configure AMQ Interconnect to communicate with clients, routers, and brokers in a secure way by authenticating and encrypting the router’s connections. AMQ Interconnect supports the following security protocols:
- SSL/TLS for certificate-based encryption and mutual authentication
- SASL for authentication and payload encryption
7.1.1. 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.
Prerequisites
You must have the following files in PEM format:
- An X.509 CA certificate (used for signing the router certificate for the SSL/TLS server authentication feature).
- A private key (with or without password protection) for the router.
- An X.509 router certificate signed by the X.509 CA certificate.
Procedure
In the router’s configuration file, add an
sslProfile
section:sslProfile { name: NAME ciphers: CIPHERS protocols: PROTOCOL caCertFile: PATH.pem certFile: PATH.pem privateKeyFile: PATH.pem password: PASSWORD/PATH_TO_PASSWORD_FILE ... }
name
A name for the SSL/TLS profile. You can use this name to refer to the profile from the incoming and outgoing connections.
For example:
name: router-ssl-profile
ciphers
The SSL cipher suites that can be used by this SSL/TLS profile. If certain ciphers are unsuitable for your environment, you can use this attribute to restrict them from being used.
To enable a cipher list, enter one or more cipher strings separated by colons (
:
).Example 7.1. Enabling a Cipher List
ciphers: ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
To see the full list of available ciphers, use the
openssl ciphers
command. For more information about each cipher, see the ciphers man page.protocols
The SSL/TLS protocols that this router can use. You can specify a list of one or more of the following values: TLSv1, TLSv1.1, or TLSv1.2.
To specify multiple protocols, separate the protocols with a space.
Example 7.2. Specifying Multiple Protocols
This example permits the SSL/TLS profile to use TLS v1.1 and TLS v1.2 only:
protocols: TLSv1.1 TLSv1.2
If you do not specify a value, the router will use the TLS protocol specified by the system-wide configuration.
NoteWhen setting the TLS protocol versions for the router, you should also consider the TLS protocol version (or versions) used by your client applications. If a subset of TLS protocol versions does not exist between a client and the router, the client will not be able to connect to the router.
caCertFile
The absolute path to the file that contains the public certificates of trusted certificate authorities (CA).
For example:
caCertFile: /qdrouterd/ssl_certs/ca-cert.pem
certFile
The absolute path to the file containing the PEM-formatted public certificate to be used on the local end of any connections using this profile.
For example:
certFile: /qdrouterd/ssl_certs/router-cert-pwd.pem
privateKeyFile
The absolute path to the file containing the PEM-formatted private key for the above certificate.
For example:
privateKeyFile: /qdrouterd/ssl_certs/router-key-pwd.pem
passwordFile
orpassword
If the private key is password-protected, you must provide the password by either specifying the absolute path to a file containing the password that unlocks the certificate key, or entering the password directly in the configuration file.
For example:
password: routerKeyPassword
For information about additional
sslProfile
attributes, see sslProfile in theqdrouterd.conf
man page.
7.1.2. 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.
Prerequisites
Before you can set up SASL, you must have the following:
- The SASL database is generated.
- The SASL configuration file is configured.
The Cyrus SASL plugin is installed for each SASL mechanism you plan to use.
Cyrus SASL uses plugins to support specific SASL mechanisms. Before you can use a particular SASL mechanism, the relevant plugin must be installed. For example, you need the
cyrus-sasl-plain
plugin to use SASL PLAIN authentication.To see a list of Cyrus SASL plugins in Red Hat Enterprise Linux, use the
yum search cyrus-sasl
command. To install a Cyrus SASL plugin, use theyum install PLUGIN
command.
Procedure
In the router’s configuration file, add the following attributes to the
router
section:router { ... saslConfigDir: PATH saslConfigName: FILE_NAME }
saslConfigDir
The absolute path to the SASL configuration file.
For example:
saslConfigDir: /qdrouterd/security
saslConfigName
The name of the SASL configuration file. This name should not include the
.conf
file extension.For example:
saslConfigName: qdrouterd_sasl
7.1.3. Securing Incoming Connections
You can secure incoming connections by configuring each connection’s listener
entity for encryption, authentication, or both.
Prerequisites
Before securing incoming connections, the security protocols you plan to use should be set up.
Choices
7.1.3.1. 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.
Procedure
In the router’s configuration file, add the following attributes to the connection’s
listener
entity:listener { ... sslProfile: SSL_PROFILE_NAME requireSsl: yes }
sslProfile
- The name of the SSL/TLS profile you set up.
requireSsl
-
Enter
yes
to require all clients connecting to the router on this connection to use encryption.
7.1.3.2. 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.
Procedure
In the router’s configuration file, add the following attributes to the connection’s
listener
section:listener { ... authenticatePeer: yes saslMechanisms: MECHANISMS }
authenticatePeer
-
Set this attribute to
yes
to require the router to authenticate the identity of a remote peer before it can use this incoming connection. saslMechanisms
The SASL authentication mechanism (or mechanisms) to use for peer authentication. You can choose any of the Cyrus SASL authentication mechanisms except for
ANONYMOUS
. To specify multiple authentication mechanisms, separate each mechanism with a space.For a full list of supported Cyrus SASL authentication mechanisms, see Authentication Mechanisms.
7.1.3.3. Adding SSL/TLS Client Authentication to an Incoming Connection
You can configure an incoming connection to authenticate the client using SSL/TLS.
The base SSL/TLS configuration provides content encryption and server authentication, which means that remote peers can verify the router’s identity, but the router cannot verify a peer’s identity.
However, you can require an incoming connection to use SSL/TLS client authentication, which means that remote peers must provide an additional certificate to the router during the SSL/TLS handshake. By using this certificate, the router can verify the client’s identity without using a username and password.
You can use SSL/TLS client authentication with or without SASL authentication.
Procedure
In the router’s configuration, file, add the following attribute to the connection’s
listener
entity:listener { ... authenticatePeer: yes }
authenticatePeer
-
Set this attribute to
yes
to require the router to authenticate the identity of a remote peer before it can use this incoming connection.
7.1.3.4. 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.
Procedure
In the router’s configuration file, add the following attributes to the connection’s
listener
section:listener { ... requireEncryption: yes saslMechanisms: MECHANISMS }
requireEncryption
-
Set this attribute to
yes
to require the router to use SASL payload encryption for the connection. saslMechanisms
The SASL mechanism to use. You can choose any of the Cyrus SASL authentication mechanisms. To specify multiple authentication mechanisms, separate each mechanism with a space.
For a full list of supported Cyrus SASL authentication mechanisms, see Authentication Mechanisms.
7.1.4. Securing Outgoing Connections
You can secure outgoing connections by configuring each connection’s connector
entity for encryption, authentication, or both.
Prerequisites
Before securing outgoing connections, the security protocols you plan to use should be set up.
7.1.4.1. 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.
You can use SSL/TLS client authentication with or without SASL authentication.
Procedure
In the router’s configuration file, add the
sslProfile
attribute to the connection’sconnector
entity:connector { ... sslProfile: SSL_PROFILE_NAME }
sslProfile
- The name of the SSL/TLS profile you set up.
7.1.4.2. 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.
Procedure
In the router’s configuration file, add the
saslMechanisms
attribute to the connection’sconnector
entity:connector { ... saslMechanisms: MECHANISMS saslUsername: USERNAME saslPassword: PASSWORD }
saslMechanisms
One or more SASL mechanisms to use to authenticate the router to the external container. You can choose any of the Cyrus SASL authentication mechanisms. To specify multiple authentication mechanisms, separate each mechanism with a space.
For a full list of supported Cyrus SASL authentication mechanisms, see Authentication Mechanisms.
saslUsername
- If any of the SASL mechanisms uses username/password authentication, then provide the username to connect to the external container.
saslPassword
- If any of the SASL mechanisms uses username/password authentication, then provide the password to connect to the external container.
7.1.5. Integrating with Kerberos
By using the GSSAPI
SASL mechanism, you can configure AMQ Interconnect to authenticate incoming connections using Kerberos.
Prerequisites
- A Kerberos infrastructure must be deployed in your environment.
In the Kerberos environment, a service principal of
amqp/HOSTNAME@REALM
must be configured.This is the service principal that AMQ Interconnect uses.
-
The
cyrus-sasl-gssapi
package must be installed on each client and router host machine. - SASL must be set up for AMQ Interconnect.
Procedure
On the router’s host machine, open the
/etc/sasl2/qdrouterd.conf
configuration file.Example 7.3. An
/etc/sasl2/qdrouterd.conf
Configuration Filepwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: qdrouterd.sasldb keytab: /etc/krb5.keytab mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN GSSAPI
Verify the following:
-
The
mech_list
attribute contains theGSSAPI
mechanism. -
The
keytab
attribute points to the location of the keytab file.
-
The
- Open the router’s configuration file.
For each incoming connection that should use Kerberos for authentication, set the router’s
listener
to use theGSSAPI
mechanism.Example 7.4. A
listener
in the Router Configuration Filelistener { ... authenticatePeer: yes saslMechanisms: GSSAPI }
For more information about these attributes, see Section 7.1.3.2, “Adding SASL Authentication to an Incoming Connection”.
7.2. 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.
AMQ Interconnect 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 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.
7.2.1. How AMQ Interconnect Enforces Connection and Resource Limits
AMQ Interconnect uses policies to determine whether to permit a connection, and if it is permitted, to apply the appropriate resource limits.
When a client creates a connection to 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.
7.2.2. 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 themaxConnections
.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
.
7.2.3. 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.
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:
7.2.3.1. 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.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 tofalse
, vhost hostnames are treated as literal strings. This means that you must specify the exact hostname for each vhost. The default isfalse
. 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
. IfdefaultVhost
is not defined, then default vhost processing is disabled.
7.2.3.2. 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 Section 7.2.3.1, “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.
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 totrue
, you can use wildcards to specify a pattern that matches a range of hostnames. For more information, see Section 5.3.2, “Pattern Matching for 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 agroups
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.
Example 7.5. User Groups in a Vhost Policy
This example shows three user groups: admin, developers, and $default:
vhost { ... groups: { admin: { users: admin1, admin2 remoteHosts: 127.0.0.1, ::1 sources: * targets: * } developers: { users: dev1, dev2, dev3 remoteHosts: * sources: myqueue1, myqueue2 targets: myqueue1, myqueue2 } $default: { remoteHosts: * allowDynamicSource: true, allowAdminStatusUpdate: true, sources: myqueue1, myqueue2 targets: myqueue1, myqueue2 } } }
users
- A list of authenticated users for this user group. Use commas to separate multiple users. A user may belong to only one vhost user group.
remoteHosts
-
A list of remote hosts from which the users may connect. A host can be a hostname, IP address, or IP address range. Use commas to separate multiple hosts. To allow access from all remote hosts, specify a wildcard
*
. To deny access from all remote hosts, leave this attribute blank. 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.
sources
|sourcePattern
A list of AMQP source addresses from which users in this group may receive messages.
Use
sources
to specify one or more literal addresses. To specify multiple addresses, use a comma-separated list. To prevent users in this group from receiving messages from any addresses, leave this attribute blank. To allow access to an address specific to a particular user, specify the${user}
token. For more information, see Section 7.2.3.4, “Methods for Specifying Vhost Policy Source and Target Addresses”.Alternatively, you can use
sourcePattern
to match one or more addresses that correspond to a pattern. A pattern is a sequence of words delimited by either a.
or/
character. You can use wildcard characters to represent a word. The*
character matches exactly one word, and the#
character matches any sequence of zero or more words.To specify multiple address ranges, use a comma-separated list of address patterns. For more information, see 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 Section 7.2.3.4, “Methods for Specifying Vhost Policy Source and Target Addresses”.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.
If necessary, add any advanced user group settings to the vhost user groups.
The advanced user group settings enable you to define resource limits based on the AMQP connection open, session begin, and link attach phases of the connection. For more information, see vhost in the
qdrouterd.conf
man page.
7.2.3.3. 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 Section 7.2.3.1, “Enabling Vhost Policies”.
Procedure
In the router configuration file, specify the directory where you want to store the vhost policy definition JSON files.
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 vhost policy definition directory, create a JSON file for each vhost policy.
Example 7.6. Vhost Policy Definition JSON File
[ ["vhost", { "hostname": "example.com", "maxConnections": 10000, "maxConnectionsPerUser": 100, "maxConnectionsPerHost": 100, "allowUnknownUser": true, "groups": { "admin": { "users": ["admin1", "admin2"], "remoteHosts": ["127.0.0.1", "::1"], "sources": "*", "targets": "*" }, "developers": { "users": ["dev1", "dev2", "dev3"], "remoteHosts": "*", "sources": ["myqueue1", "myqueue2"], "targets": ["myqueue1", "myqueue2"] }, "$default": { "remoteHosts": "*", "allowDynamicSource": true, "sources": ["myqueue1", "myqueue2"], "targets": ["myqueue1", "myqueue2"] } } }] ]
For more information about these attributes, see Section 7.2.3.2, “Configuring Vhost Policies in the Router Configuration File”.
7.2.3.4. 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:
To… | Do this… |
---|---|
Allow all users in the user group to access all source or target addresses on the vhost |
Use a Example 7.7. Receive from Any Address sources: * |
Prevent all users in the user group from accessing all source or target addresses on the vhost | Do not specify a value. Example 7.8. Prohibit Message Transfers to All Addresses targets: |
Allow access to some resources specific to each user |
Use the Note
You can only specify the Example 7.9. 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:
sources: tmp_${user}, temp*, ${user}-home-* Example 7.10. 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:
sourcePattern: tmp.${user}, temp/#, ${user}.home/* Note
In an address pattern ( |
7.2.3.5. Vhost Policy Examples
These examples demonstrate how to use vhost policies to authorize access to messaging resources.
Example 7.11. Defining Basic Resource Limits for a Messaging Endpoint
In this example, a vhost policy defines resource limits for clients connecting to the example.com
host.
[ ["vhost", { "hostname": "example.com", 1 "maxConnectionsPerUser": 10, 2 "allowUnknownUser": true, 3 "groups": { "admin": { "users": ["admin1", "admin2"], 4 "remoteHosts": ["127.0.0.1", "::1"], 5 "sources": "*", 6 "targets": "*" 7 }, "$default": { "remoteHosts": "*", 8 "sources": ["news*", "sports*" "chat*"], 9 "targets": "chat*" 10 } } }] ]
- 1
- The rules defined in this vhost policy will be applied to any user connecting to
example.com
. - 2
- Each user can open up to 10 connections to the vhost.
- 3
- Any user can connect to this vhost. Users that are not part of the
admin
group are assigned to the$default
group. - 4
- If the
admin1
oradmin2
user connects to the vhost, they are assigned to theadmin
user group. - 5
- Users in the
admin
user group must connect from localhost. If the admin user attempts to connect from any other host, the connection will be denied. - 6
- Users in the admin user group can receive from any address offered by the vhost.
- 7
- Users in the admin user group can send to any address offered by the vhost.
- 8
- Any non-admin user is permitted to connect from any host.
- 9
- Non-admin users are permitted to receive messages from any addresses that start with the
news
,sports
, orchat
prefixes. - 10
- Non-admin users are permitted to send messages to any addresses that start with the
chat
prefix.
Example 7.12. Limiting Memory Consumption
By using the advanced vhost policy attributes, you can control how much system buffer memory a user connection can potentially consume.
In this example, a stock trading site provides services for stock traders. However, the site must also accept high-capacity, automated data feeds from stock exchanges. To prevent trading activity from consuming memory needed for the feeds, a larger amount of system buffer memory is allotted to the feeds than to the traders.
This example uses the maxSessions
and maxSessionWindow
attributes to set the buffer memory consumption limits for each AMQP session. These settings are passed directly to the AMQP connection and session negotiations, and do not require any processing cycles on the router.
This example does not show the vhost policy settings that are unrelated to buffer allocation.
[ ["vhost", { "hostname": "traders.com", 1 "groups": { "traders": { "users": ["trader1", "trader2"], 2 "maxFrameSize": 10000, "maxSessionWindow": 5000000, 3 "maxSessions": 1 4 }, "feeds": { "users": ["nyse-feed", "nasdaq-feed"], 5 "maxFrameSize": 60000, "maxSessionWindow": 1200000000, 6 "maxSessions": 3 7 } } }] ]
- 1
- The rules defined in this vhost policy will be applied to any user connecting to
traders.com
. - 2
- The
traders
group includestrader1
,trader2
, and any other user defined in the list. - 3
- At most, 5,000,000 bytes of data can be in flight on each session.
- 4
- Only one session per connection is allowed.
- 5
- The
feeds
group includes two users. - 6
- At most, 1,200,000,000 bytes of data can be in flight on each session.
- 7
- Up to three sessions per connection are allowed.