Uploaded image for project: 'Qpid'
  1. Qpid
  2. QPID-8487

[Broker-J] Enhance ACL rule evaluation

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Broker-J

      Description

      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:

      1. 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.
      2. 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:

      1. The RuleSet itself is the top generic inspector.
      2. 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.
      3. 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.

      Single rule evaluation

      The rule can have many matching criteria: firewall or dynamic criterion, updates attributes, required properties. It is very generic but typical rule has only a few criteria or none.

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              lacam Marek Laca
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: