Multilayer rules

[etj]

Currently, GeoFence rules are designed to target a single layer. This is a deliberate design choice: allowing a rule to reference multiple layers would significantly complicate the rule priority model and negatively impact rule selection performance.

However, there are valid use cases where the same logical rule (same filters and constraints) should apply to multiple layers, differing only by layer name.

---

Proposed approach: RuleGroup concept

Rather than extending a single rule to support multiple layers, an alternative is to introduce a RuleGroup concept.

A RuleGroup represents a logical grouping of rules that:

• Share the same filtering fields (e.g. user, role, service, request type, spatial filter, etc.)
• Share the same data access constraints
• Differ only by the target layer

Key principle

The RuleGroup is primarily a presentation and management abstraction, not a change to the core rule execution model.

At runtime and in the database, GeoFence continues to operate on standard single-layer rules, preserving:

• Existing rule priority semantics
• Existing rule evaluation logic
• Existing performance characteristics

---

Backend / data model implications

• A RuleGroup is expanded (“exploded”) into multiple standard rules at persistence time.
• Each generated rule is identical except for the layer name.
• To preserve the logical relationship between these rules, introduce a new optional field in the Rule entity, for example:
  • ruleGroupId

This field:

• Indicates that the rule belongs to a RuleGroup
• Allows grouping, collapsing, and integrity checks at API and UI level

No changes to the rule evaluation engine are required.

Priority

The priority may or may not be the same for all the rules in a RuleGroup.

• Same priority:
  Rules with the same priority would not be a problem in evaluating access, since the various rules in the RuleGroup refer to different layers, so they are never returned in the same evaluation query.
  • Pros:
    • More user friendly for the user which looks at a "condensed" rules list
    • Maybe easier to handle shift/swap operations
  • Cons:
    • Internal logic should be completely reviewed to make sure this is possibile and not conflicting with any procedure.
• Different priority:
  The priorities of the various Rules in the same RuleGroup should be consecutive, with no other rule in between, since this would probably make diffcult to visualize the proper order to the user -- in the evaluation it is not a problem.
  • Pros:
    • Priority uniqueness remains unchanged
  • Cons:
    • The user may wonder why some priorities are not displayed in the "condensed" rules list
    • Shift/swap operations should consider also unbreakable blocks of priorities

Anyway, to make the RuleGroup to be as transparent as possibile, we should maintain the uniqueness concept of priority, so we'll have different priorities for the various "exploded" rules.

Grant types

A RuleGroup may have the 3 existing grant types without any problem:

• DENY: all the matching rules are applied
• LIMIT: the RuleLimits can be applied to each exploded rule without problem
• ALLOW: no problems in the pure allowing behaviour. There may be limitations in LayerDetails.

LayerDetails

LayerDetails may be limited, since some fields are strictly related to the Layer content:
- private LayerType type;: now useless, can be ignored
- private String defaultStyle;: not allowed: refers to layer, possibily to internal fields,
- private String cqlFilterRead; allowed, may be general or parametrized
- private String cqlFilterWrite; allowed, as above
- private MultiPolygon area; allowed,
- private SpatialFilterType spatialFilterType; allowed
- private CatalogMode catalogMode; allowed
- private Set<String> allowedStyles = new HashSet<>(); not allowed, see also defaultStyle
- private Set<LayerAttribute> attributes = new HashSet<>(); now allowed

---

Editor and GUI implications

Rule editor

• The rule editor:
  • Displays the usual filter and data fields once
  • Provides a widget allowing selection of multiple layers
• From the user’s perspective, they are editing a single RuleGroup rather than multiple individual rules.

Rule list

• The rule list should be able to:
  • Collapse all rules belonging to the same RuleGroup into a single entry
  • Indicate that the entry represents multiple underlying rules
• When expanded, individual generated rules can still be inspected.

Transparency and diagnostics

Since collapsing rules may be misleading in some scenarios (e.g. priority analysis or debugging), it may be useful to provide:

• A “physical rules” view showing the fully exploded list of rules
• Clear visual cues distinguishing grouped rules from standalone rules

---

API implications

• Introduce a new set of RuleGroup-aware APIs for:
  • Creating, updating, and deleting RuleGroups
  • Managing layer membership within a group
• Existing rule APIs remain available but should enforce additional constraints:
  • Prevent partial or inconsistent updates to individual rules belonging to a RuleGroup
  • Clearly define which operations are allowed at rule level vs. group level

GeoServer

GeoServer will need some implementations as well.

A new rulegroup/ endpoint is needed for the new service calls.

The exisitng RuleController needs a review to enforce the constraints for Rule belonging to RuleGroups

Most of the work is needed on the frontend.

Rule editor

The GeoFence Data Rules page should contain 2 tabs

• The "exploded view", which is the current view
• The "collapsed view", where rules belonging to a RuleGroup are represented as a single line.

Exploded view

The exploded view needs some changes:

• Rules belonging to a RG can't be edited from that page.
• Moving normal rules up/down over a RG rule, should move the rule just past the RG.
• Rules belonging to a RG should not be moved up/down

Collapsed view

TODO

Rule editing page

TODO

---

Tasks @ GeoNode

Model

• Introduce group id field in `Rule' class

Persistence

• Introduce checks to avoid group fragmentation (i.e. Rules belonging to the same RuleGroup should be adjacent.
  TBD if it's up to the DAO, the service or the user to adjust the rule position.
• Add a new method for a group-wise collapsing query (probably implemented via raw SQL)

Services

• Create org.geoserver.geofence.services.RuleGroupAdminService
  • Identify a minimal set of operations and related constraints
    • Insert:
      • priority identifies first inserted rule, other ones are consecutive values (existing rules may be shifted down)
    • Limitations: Allow= allowedArea, spatialFilterType, catalogMode (see considerations above)
    • LayerDetails should be allowed with a subset of allowed field: cqlread, cqlwrite, catalogmode, allowed area, spatialFilterType (see considerations above)
    • Delete: delete the whole set of rules
    • ...
  • Review RuleAdminService, applying restrictions where needed:
    • insert: groupid should be null
    • insert: new rule should not be created withing the RuleGroup
    • update: can't update rules where groupid is set
    • update: can't update groupid field
    • move, swap: can't move a normal rule within a set of RuleGroup rules
    • delete: single rules belonging to a RuleGroup can be deleted via this service
    • ...
• Add method getMatchingRulesGrouped in org.geoserver.geofence.services.RuleReaderService
  • grouped rules will be returned via a new RuleGroup DTO.

REST API

• New DTOs for RuleGroup
• New rulegroup/ endpoints for the new service calls
• Revise the rule/ calls to enforce the constraints for Rule belonging to RuleGroups

Doc

• Update wiki documentation

Tasks @ GeoServer

Controller

• New rulegroup/ endpoints for the new service calls
• Revise the rule/ calls to enforce the constraints for Rule belonging to RuleGroups

Doc

• Update sphinx documentation

GeoFence Rule pages

• Changes to the Rule Editor, as described above. A proper issue will be opened for that.