Implement REST call for providing an EXPLAIN PLAN

[etj]

Sometimes it is really difficult to understand the outcome of a given authorization request. At the moment the solution is to check the geofence log, at debug level (see for instance this comment).

It would be really useful to have a REST operation which provides detailed operation on a given request, such as the comment linked above (rules retrieved grouped by role, access granted to every single role, ...)

At the moment there is only a REST call for retrieving the rules (reported here); this issue is about having an idea of how the rules are going to be processed.

[simboss]

@etj I have asked @nmco to go ahead and help implementing this.

[nmco]

This issue needs some clarification @etj, it mixes a couple of things: EXPLAIN PLAN (I guess a PostgreSQL DB one) and then there is this this issue is about having an idea of how the rules are going to be processed.

We would need your knowledge of GeoFence to understand the rules workflow and what info we should expect, I'm sending an invite so we can have a quick about this.

[nmco]

Meeting with @etj and @taba90 18-01-2022:

• It can be hard to understand the final rule built by GeoFence, which it does by merging all Geofence rules and limitations.
• The goal is to have a RESt end-point that will retrieve "the merging plan" performed by GeoFence.
• The tricky bit will be to gather all the GeoFence rules selected in different points.
• This will need to work for both the embedded and standalone GeoServer.
• One way to implement this would be to create a log collector that would collect all relevant rules selection and merging.
• In terms of functionality:
  • We should be able to get the rules to trace directly from the request on the environment that is falling, rules can be tricky and rely on IPs.
  • We should have on GeoFence admin UI and button to activate trace mode, likewise for GeoFence stand alone.
  • Once the trace mode is activated the logs for that trace session should be stored on a dedicated log.
  • For the moment I would recommend that the administrator be responsible to activate and reactive the TRACE mode.
  • The TRACE log should contain the request, timestamp and rules explain plan.

@taba90 will work on plan and estimate for this.

[taba90]

Implementation plan reviewed together with @etj 02/03/2022

• We are going to add a new method to the RuleReaderService named getAccessInfoWithDetails the method will have a default implementation that simply call the already existing getAccessInfo so we do not breack backwards compatibility.
• The new method will be responsible to collect the log message here and some newly added regarding the final AccessInfo object.
• The collected message will be set as a String[] or List to a new subclass of AccessInfo named AccessInfoWithDetails.
• In every point of the GeoFenceAccessManager where the getAccessInfo method is called like here we will check if the log collection is enabled. If yes the GeoFenceAccessManager will issue the getAccessInfoWithDetails method and will append the received logs to the GeoServer Logger with the highest priority LEVEL.
• The flag telling the GeoFenceAccessManager wether collect or not collect the logs will be set by the Admin from the UI on GeoServer side in both cases (either when we have a standalone GeoFence either we have the internal one).

Estimate for the task is 2,5-3 days.

@etj @nmco somehow I cannot change labels and status of this issue, probably because it is on the DevOps Pipeline can you change them?