-
Notifications
You must be signed in to change notification settings - Fork 7
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.
Functionality from GSIP-152 should be replicated on Geofence plugin allowing to have restriction rules and spatial filters for workspace and Global layer groups.
NUNO: THE PARAGRAPH ABOVE NEEDS TO BE REWROTE, AND THE LIST OF LAYERGROUPS SECURITY FUNCTIONALITIES THAT WILL BE IMPLEMENTED IN GEOFENCE EXPLICITLY LISTED.
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.
Take 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 including functionality included on GSIP 152 and 153:
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.
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