You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Tomas Vavricka (Jira)" <ji...@apache.org> on 2022/11/11 12:20:00 UTC

[jira] [Closed] (QPID-8487) [Broker-J] Enhance ACL rule evaluation

     [ https://issues.apache.org/jira/browse/QPID-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Vavricka closed QPID-8487.
--------------------------------

> [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
>             Fix For: qpid-java-broker-9.0.0
>
>
> 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.10#820010)

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