Andrea Aime

This proposal is for GeoServer 2.11-beta, with intention to backport to 2.10.x after the cooldown period.

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

GeoServer own ResourceAccessManager interface already supports security layer groups, however no officially supported security implementation deals with them and the semantics of groups configured in tree mode is not well defined.

This proposal aims at adding support for layer groups in GeoServer default "layer security" subsystem, by extending the current security syntax, and properly define relationships between the security of a layer group and the one of its underlying layers.

The current data access security is defined in a property file based on the following syntax:

workspace.layer.permission=role[,role2,...]

Layer groups can occur both at the global and workspace level, so the syntax will be extended as follows:

globalGroupName.permission=role[,role2,...]
workspace.layerGroupName.permission=role[,role2,...]

The first definition uses a new structure, thus poses no backwards compatibility issue. The second one, used for workspace specific groups, has the same structure as the old one, causing potential issues with layers given the same name as layer groups. However, the situation is quickly solved as the same problem arises when issuing a GetMap, in which the layer is always preferred. The same approach will be used in security rules, in case of conflict the reference will point to the layer.

Layer groups come in two main types, single, which is a shortcut to a layer list with no visible structure to the users, and the various *tree modes, that visibly contain the layers in the capabilities document.

Security wise, the following rules will apply (if and only if the current service is WMS):

• Denying access to a single group will have no consequences on the contained layers, which will continue to be available, it will only make the group unavailable.
• Denying access to a tree group will cause all nested layers and groups to be denied as well
• The above rule does not apply to layers that are still available from a separate layer group in tree mode whose access is not denied (as multiple layer groups can contain the same layer or nested group)

The above rules will be implemented in DefaultResourceAccessManager.

To clarify, lets assume the following starting situation, in which all layers and groups are visible:

root
+- namedTreeGroupA
|   |   layerA
|   └   layerB
+- namedTreeGroupB
|   |   layerB
|   └   layerC
+- layerD
+- singleGroupC (contains layerA and layerD when requested)

Here are a few examples of how the structure changes based on different security rules.

• Denying access to namedTreeGroupA

root
+- namedTreeGroupB
|   |   layerB
|   └   layerC
+- layerD
+- singleGroupC (contains only layerD when requested)

• Denying access to namedTreeGroupB

root
+- namedTreeGroupA
|   |   layerA
|   └   layerB
+- layerD
+- singleGroupC (contains layerA and layerD when requested)

• Denying access to singleGroupC

root
+- namedTreeGroupA
|   |   layerA
|   └   layerB
+- namedTreeGroupB
|   |   layerB
|   └   layerC
+- layerD

Layer groups are a construct specific to WMS, as such, their security will not influence access to feature types and coverages from WFS and WCS. In case denying access to the layers is desired also on other protocols, rules specific to the layers will also have to be setup.

The proposal is fully backwards compatible.

Kevin: the difference in behavior between WMS and other services should be clearly documented and pointed out in the user interface

Project Steering Committee:

• Alessio Fabiani: +1
• Andrea Aime: +1
• Ben Caradoc-Davies: +1
• Brad Hards: +1
• Christian Mueller: +1
• Ian Turton: +1
• Jody Garnett: +1
• Jukka Rahkonen:
• Kevin Smith: +1
• Simone Giannecchini: +1

• Email Discussion
• GeoTools / GeoServer Meeting 2016-11-15
• Jira ticket