Extend layer security to be service/operation specific.

Niels Charlier

Unknown

Under Discussion, In Progress, Completed, Rejected, Deferred

At the moment the GeoServer integrated security subsystem supports both service security and per layer security, but it does not support the combination of the two. For example, it is not possible to specify access to a specific OWS service only for one specific layer.

This feature does already exist in the new extension geofence (which offers a more advanced security subsystem that is database-driven and can be configured with a GUI and REST).

However, some users wish to continue to use the text-based configuration files of geoserver's default integrated security system whilst still have some basic support for integrated layer/service security.

The proposal is to extend the layer security system and leave the existing service security untouched.

Access permissions to layers is currently configurable by entries in the GEOSERVER_DATA_DIR/security/layers.properties property file, using the following syntax:

namespace.layer.accessmode=ROLE_1[,ROLE_2][, ...]] 

Where accessmode is 'r' (read), 'w' (write) or 'a' (admin).

We propose the possibility to extend these rules to also allow the following syntax:

namespace.layer.service.operation.accessmode=ROLE_1[,ROLE_2][, ...]] 

Service and operation may be replaced by a '*' character to specify the global level (all operations / all services).

Contrary to the current restrictions, it will become possible to allow a '*' to be followed by parts that are not '*', it would thus be able to match rules such as:

topp.*.wms.GetMap.r=ROLE_WHATHEVER
topp.*.wfs.*.r=ROLE_WHATHEVER

In the absence of a rule for a specific service and operation, the global service rule is applied for that service. In the absence of a global service rule, we fall back on to non-service rules. This is completely consistent with the existing access rules order of preference. The most specific rule is thus always selected, but specificity earlier in the path takes preference over specifity later in the path.

This means that

workspace.layer.*.*

takes preference over

workspace.*.service.operation.

even though the second rule looks more specific.

Note that in the new system, the old syntax

 namespace.layer.accessmode=ROLE_WHATHEVER

becomes a shorter way to write the equivalent rule

 namespace.layer.*.*.accessmode=ROLE_WHATHEVER

These two rules will internally be represented as equivalent and the existing restriction on duplicate rules disallows them from being used in the same configuration.

Global service security rules can still be specified in the GEOSERVER_DATA_DIR/security/services.properties. They are applied even before layer security; therefore it is the case that between services.properties and layers.properties it is the most restrictive rule that will determine access at any time.

DataAccessRule class is extended to hold a service and operation field. The parser is updated create the more advanced rules.

Currently the data structure of the securetreenode is as follows:

securetreenode { map<string, securetreenode> children; authorization_data; }

This would be changed into

securetreenode { map<string, securetreenode> children; securetreenode any; }

securetreeleaf extends securetreenode { authorization_data; }

Only leafs of the tree would contain authorization data and the rule '*.*.*.*' would be in the leaf of the tree path 'any->any->any->any'.

The method findDeepestNode would only need a minor change: in case of not finding a child: instead of stopping at that node (as it does now), it will now follow the "any" node.

The geoserver admininistration UI will need to be updated accordingly. This means that org.geoserver.security.web.data.NewDataAccessRulePage will need two additional drop down boxes.

The security check is done through the ResourceAccessManager. Before applying Layer Security to the SecuredCatalog, the requested service and operation are retrieved and specific action is taken based on this information.

The proposal was rejected because of the priority system.

There is full backwards compatibility. All existing rules still work with the old syntax. The internal hierarchical structure of the rule system is preserved. Service security still works.

Project Steering Committee:

Alessio Fabiani
Andrea Aime
Ben Caradoc-Davies
Christian Mueller
Gabriel Roldán
Jody Garnett
Jukka Rahkonen
Justin Deoliveira
Phil Scadden
Simone Giannecchini