[jira] [Comment Edited] (QPID-8484) [Broker-J] Reimplementation of the limit number of connections per user

["Marek Laca (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220619#comment-17220619 ] 

Marek Laca edited comment on QPID-8484 at 10/26/20, 11:43 AM:
--------------------------------------------------------------

Hi [~orudyy],

I am inspired by the 'registerConnection' and 'deregisterConnection' in NamedAddressSpace interface. I would introduce new methods in NamedAddressSpace:
 canAcceptNewConnection
 decrementUserConnectionCount

The 'canAcceptNewConnection' method will be called just before 'registerConnection' and 'decrementUserConnectionCount' will be called after the 'deregisterConnection'. The virtual host delegates decision to the 'resourceLimiter', it calls resourceLimiter.registerConnection. The resourceLimiter is provided by the new plugin. There will be allowed at most one plugin at the virtual host.

The resourceLimiter looks for the limits in this order:
 # User limits.
 # The most restrictive group limits.
 # Default limits.

The resourceLimiter checks limits and rejects the connection, or it accepts the connection and increments counters.

From my point of view the proper implementation of the limits as ACL rule is complicated.
The broker should check the limits at once and rejects a new connection or accepts and increments counters. But there could be multiple ACL rules, which depend on the order.


was (Author: lacam):
Hi [~orudyy],

I am inspired by the 'registerConnection' and 'deregisterConnection' in NamedAddressSpace interface. I would introduce new methods in NamedAddressSpace:
canAcceptNewConnection
decrementUserConnectionCount

The 'canAcceptNewConnection' method will be called just before 'registerConnection' and 'decrementUserConnectionCount' will be called after the 'deregisterConnection'. The virtual host delegates decision to the 'resourceLimiter', it calls resourceLimiter.registerConnection. The resourceLimiter is provided by the new plugin. There will be allowed at most one plugin at the virtual host.

The resourceLimiter looks for the limits in this order:
 # User limits.
 # The most restrictive group limits.
 # Default limits.

The resourceLimiter checks limits and rejects the connection, or it accepts the connection and increments counters.

> [Broker-J] Reimplementation of the limit number of connections per user
> -----------------------------------------------------------------------
>
>                 Key: QPID-8484
>                 URL: https://issues.apache.org/jira/browse/QPID-8484
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Broker-J
>    Affects Versions: qpid-java-broker-8.0.1, qpid-java-broker-8.0.2
>            Reporter: Marek Laca
>            Priority: Major
>              Labels: connection, limit, user
>
> If some user creates too much connections, he can prevent other users from connecting to amqp ports. [QPID-8369|https://issues.apache.org/jira/projects/QPID/issues/QPID-8369] added an ability to limit maximum open connections per user.
>  The user connection limit was implemented as ACL dynamic rule and it is part of the access control logic.
> But I have queries about the implementation:
>  * The connection count of the user is not checked properly.
>  For example 2 connections should be rejected when an user has limit 5 and tries to open 7 parallel connections. But what happens:
>  ## Every connection increments the counter then the counter will be 7.
>  ## ACL logic compares the actual counter value with the limit for every connection (the counter value at the moment of the acl rule check) and 2,3 … or all 7 connections can be denied. The ACL logic does not know which connection broke the limit.
>  ## The counter is decremented when connection is closed.
>  * ACL rules were static and so the result of the check did not vary in time and the Broker could cache the result ALLOWED or DENIED. From my point of view a dynamic check should not be part of the ACL logic because it makes ACL logic time dependent.
>  * The user connection limit should be checked as soon as possible.
> I suggest to introduce a new plugin (similar to the access control provider plugin) that will hold the user's counters of open connections.
>  It will provide following functionality:
>  * It registers new connections for given user and the connection will be rejected if the user breaks the limit. The registration and update of user's counters will be an atomic operation.
>  * It de-registers the connections for given user.
> If user breaks the limit then the connection will be closed with proper response "amqp:resource-limit-exceeded" instead of "amqp:not-allowed".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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