gsip 184
The purpose of this proposal is to add layers groups security support, as it is currently available in GeoServer, to Geofence integrated plugin. This implies that Geofence will need to be extended to support layer groups and Geofence integrated plugin UI extended to support the new options.
Fernando Miño
This proposal is for GeoServer 2.17-beta, and to backport to 2.16.2 after the one month cool-down.
- Under Discussion
- In Progress
- Completed
- Rejected
- Deferred
Allow Geofence advanced security capabilities to be used on layer groups, for example the spatial filtering.
Functionality from Geoserver Layer security should be reused on Geofence plugin allowing to have restriction rules and spatial filters for inside-workspace Layer Groups and global Layer Groups. To achieve this some refactoring will be done to make the layer-groups security code reusable by Geofence (and other resource managers).
Taking into account the behavior for access on Layer Groups already available on Geoserver, all these behavior should be respected on Geofence Layer Groups support work, this means Layer Groups security behavior should apply the following rules defining relationships between the security of a layer group and the one of its underlying layers:
General rules for layer security:
- Each entry must have a unique combination of workspace, layer, and permission values.
- If a permission at the global level is not specified, global permissions are assumed to allow read/write access.
- If a permission for a workspace is not specified, it inherits permissions from the global specification.
- If a permission for a layer is not specified, it inherits permissions from its workspace specification in all protocols except WMS (where layer groups rules play a role, see below).
- If a user belongs to multiple roles, the least restrictive permission they inherit will apply.
For WMS, layers will be also secured by considering their containing layer groups. In particular:
- Rules with Single layer groups only affect the group itself, but not its contents. Single mode is considered just an alias for a list of layers, with no containment.
- Rules with other types of groups (Named tree, Container tree, Earth Observation tree) also affect contained layers and nested layer groups. If the group is not accessible, the layers and groups contained in that group will not be accessible either.. The only exception is when another layer group which is accessible contains the same layer or nested group, in that case the layers they will show up under the allowed groups.
- Workspace rules gets precedence over global layer group ones when it comes to allow access to layers.
- Layer rules get precedence over all layer group rules when it comes to allow access to layers.
| Mode | Public behavior | Restricted behavior |
|---|---|---|
| Single | Looks like a stand-alone layer, can be requested directly and acts as an alias for a layer list. Layers are also visible at root level | Does not control layer access at all |
| Named tree | Contained layers are visible as children in the capabilities document, the name can be used as a shortcut to request all layers. | Restricting access to the group restricts also the contained layers, unless another "tree" group allows access to the same layer |
| Container tree | Same as "named tree", but does not have a name published in the capabilities document and thus cannot be requested directly | Same as "named tree" |
| Earth observation tree | Same as "named tree", but has a special layer configured that will be returned if the group is called by name, instead of the layers contained in it. | Same as "named tree" |
| Opaque container | The group is published as a stand alone layer in the capabilities tree, the layers in it are not showing up in the capabilities document unless also contained in a "tree" group type. The layers are also not accessible via GetMap/GetFeatureInfo calls. | Same as public, the layers in the layergroup are not available for access by themselves, but only as part of the group (unless also contained in another tree mode group allowing access to them). |
For this we should check Layer Group rules when a Layer is requested on WMS to compute the extra access logic described in base to its parent Layer Group. Also each layer of the layer groups must be evaluated separately and filtered accordingly on Layer Group request.
On user interface the only addition is the possibility of selecting a Layer Group in the Layer selector. The user will be able to enter the desired spatial filter directly from GeoServer integrated GeoFence web UI as usual:
We will need to adapt WorkspacesManagerServiceImpl for getting also LayerGroups from Geoserver and the UI for supporting global scope (no workspace) Layer groups.
On Geofence code, Layer Group access check should be implemented on method:
We should make sure requests rules like spatial filters are correctly applied to Layer groups.
- org.geoserver.geofence.GeofenceAccessManager.overrideGetMapRequest(Request, String, String, Authentication, GetMapRequest)
In Rule persistence class (org.geoserver.geofence.core.model.Rule) both fields layer and workspace are String typed so there is no restriction for declaring and persisting a global (no workspace attached) layer group. Also the LayerType enum (org.geoserver.geofence.core.model.enums.LayerType) already supports the LAYERGROUP type for using on LayerDetails entity.
Geofence UI wise we would need:
- To list and let the user to select available Layer Groups (in the same select component where Layers are listed), so geoserver-internal and standalone UI controllers will need to change for supporting this, with the unique difference that Layer Groups can be at global scope (no workspace).
- So adding an option for representing Global Workspace level should be added on Workspace selector too.
Layer Group security work done:
- https://github.com/geoserver/geoserver/wiki/GSIP-152
- https://github.com/geoserver/geoserver/commit/b80e02be0d2e402e6d37cf87ff70e24b2f1aa089
Opaque layer group mode work done:
- https://github.com/geoserver/geoserver/wiki/GSIP-153
- https://github.com/geoserver/geoserver/commit/8c857b51a28d69540538469e8c81ecbf0063efe5
Project Steering Committee:
- Alessio Fabiani:
- Andrea Aime:
- Ian Turton:
- Jody Garnett:
- Jukka Rahkonen:
- Kevin Smith:
- Simone Giannecchini:
- Torben Barsballe
- Nuno Oliveira