[
https://issues.apache.org/jira/browse/QPID-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17496510#comment-17496510
]
ASF subversion and git services commented on QPID-8487:
-------------------------------------------------------
Commit 75b1fc6e053ef0061ab6514d90b503d87bc7aa63 in qpid-broker-j's branch
refs/heads/main from Marek Laca
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=75b1fc6 ]
QPID-8487: [Broker-J] Enhance ACL rule evaluation
This closes #115
> [Broker-J] Enhance ACL rule evaluation
> --------------------------------------
>
> Key: QPID-8487
> URL: https://issues.apache.org/jira/browse/QPID-8487
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Marek Laca
> Priority: Major
> Labels: ACL, Broker, Java, Performance
>
> We are using the Java broker with more than 1000 accounts and 40000
> individual ACL rules. This amount of ACL rules has a significant impact on
> the throughput of the broker, therefore an optimization is needed.
> *Current implementation*
> There is the class called RuleSet that wraps the list of the rules and it is
> responsible for finding a matching rule. The RuleSet contains internal
> map/cache that could contain the relevant rules for given subject, operation,
> object type.
> Every access control of the user action goes throw two steps in the RuleSet:
> # Broker looks for the relevant list of rules in the cache. If the cache
> does not contain the rules then the broker will iterate over entire rule list
> and filter the relevant rules for given operation, object type and subject.
> # Broker scans the relevant rules and applies the first matching rule.
> The cache is 3 tiers map with subject, operation and object type as key (in
> this order). The top map is a synchronized weak hash. Hence the cache is used
> only if the same subject (pointer equality) checks rules for the same
> operation and object type multiple times.
> I have tried to send 1000 messages to the same exchange by the same user and
> the cache was never used. It looks like that every send action created a new
> subject. The broker iterated over the whole rule list again and again.
> *Proposed implementation*
> I propose to introduce RuleInspector object that can check the internal rule
> list and looks for the first rule that matches. The RuleInspector will be
> based on the composite patter, the generic inspector will delegate work to a
> more specialized inspector and so on.
> _Tier structure:_
> # The RuleSet itself is the top generic inspector.
> # The rule inspectors for given operation and object type. These inspectors
> will contain the relevant rules for given operation and object type and can
> be prepared after the loading of the ACL file or rule list. The rules can be
> group by the operation and object type immediately.
> # The rule inspectors for given operation, object type and
> subject/principals. The inspector for given principals/subject identities can
> be cached in a map. Every subject has a set of principals and the rule list
> provides a set of identities. The intersection of these two set produces a
> set of relevant principals that have an impact on rule matching. Hence this
> set of relevant principals is a suitable key of the cache.
> The cache can be populated with the inspectors for none or a single relevant
> principal directly after the loading.
> The rule object can be transformed to a simple rule that matches only the
> specified criteria. There will be different simple rules derived from
> firewall criterion, updates attributes, properties and the simple rule will
> check only the criterion that is needed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
