GSIP 57

GSIP 57 - Improving GeoServer authorization framework

Overview

Adding support for data filtering in GeoServer security framework

Proposed By

Andrea Aime

Assigned to Release

TBD, tentatively 2.1.0 or 2.1.1

State

Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred

Motivation

The current GeoServer authorization subsystem works, at the catalog level, by delegating to the DataAccessManager interface, which decides if the use can access a certain layer in read or write mode. The interface has a default implementation relying on the built-in security configuration, but can be implemented by others to integrate with custom or external security subsystems.

The current yes/no access granularity is too coarse for the common enterprise needs, more often than not people do need to grant access to parts of a layer, or to certain attributes of it. The proposal introduces a new interface, ResourceAccessManager, that the GeoServer security subsystem can query to get more granular information about data access rules.

Proposal

The ResourecAccessManager

The DataAccessManager interface is going to be deprecated in favor or the ResourceAccessManager one, which would look as follows:

public interface ResourceAccessManager {
 public enum CatalogMode {
 HIDE,
 CHALLENGE,
 MIXED
 }

/**\*
** Returns the security mode in which the secure catalog must operate
* @return
*/
 public CatalogMode getMode ();

/**\*
** Returns true if user can access the layer in the specified mode
*/
 public AccessLimits canAccess (Authentication user, LayerInfo
layer, AccessMode mode);

/**\*
** Returns true if user can access the resource in the specified mode
*/
 public AccessLimits canAccess (Authentication user, ResourceInfo
resource, AccessMode mode);

public static class AccessLimits {
 // used for vector reading, for raster if there is a read param
 Filter readFilter;
 }

public static class VectorAccessLimits extends AccessLimits {
 // used for both vector and raster
 List<PropertyName> readAttributes;

// only used for vector data
 List<PropertyName> writeAttributes;
 Filter writeFilter;
 }

public static class RasterLimits extends AccessLimits {
 MultiPolygon rasterFilter; // roi filter for raster and WMS data?
 GeneralParameterValue[] params;
 }

public static class WMSLimits extends AccessLimits {
 MultiPolygon rasterFilter; // roi filter for raster and WMS data?
 }

}

Comparisons with the old DataAccessManager:

• there is no workspace specific call, that is unecessary as the workspace is always available as part of the layer/resource definition
• still has both layer and resource methods as code can directly access the resources bypassing the layers (even though the user facing code just sees layers) because in theory the same resource could be published twice as two different layer (the GUI does not allow that, but working directly against the code may)
• the code returns an AccessLimits class, the root of a hierarchy of access limit related classes, one per resource type. The AccessLimits object would contain information to secure an object in both read and write modes (as the catalog does not know what kind of use the resources will be put through)

The vector layers would be secured by VectorAccessLimits, which contains the basics elements of two query objects, one for read, and one for write. This allows to secure the vector layers by shaving off unrequired attributes and by limiting the features to be presented or edited.

The raster layers have a generic read filter, which some plugins, like mosaic, do accept, as well as a generic geometric filter, to limit the areas to be seen, as well as a set of override read parameters which can be used to further constrain what the readers will return (thinking in particular about time/elevation).

The WMSLimits would be similar to the raster filters, the generic read filter could be passed down to an eventual cascaded GeoServer (which would be just ignored by other servers) as well as a geometry filter to shave off area where the user is not supposed to see the imagery.

In both raster and WMS case the geometry filter would be used to drive a crop operation that would phisically remove from the output anything out of the configured areas (acting as a cookie cutter).

The SecureCatalogImpl changes

SecureCatalogImpl nowadays builds read only wrappers around most of the catalog resources. The upgrade will require to build more complex writers able to add filtering and attribute selection on both read and write operations, as well as adding new wrappers for raster and wms layers. This will actually be the biggest part of the upgrade

Briding the existing implementation

The funding available is geared towards the integration with external security systems, so there won’t be a corresponding upgrade in the default GeoServer security configuration. The new code will instead look for implementations of the old DataAccessManager interface, which will be deprecated, and adapt it to the new interface via a wrapper.

Future development potential

The proposal does not add new end user functionality but lays the basis for adding the often requested per layer and per attribute security, allowing to perform such upgrade at a reduced effort, and to plug in separate security implementations such as GeoXACML.

Feedback

This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

The new code will look for implementations of the old DataAccessManager interface, which won’t be removed, but deprecated, and adapt it to the new interface via a wrapper. So the existing authorization code, as well as any other implementation of DataAccessManager, will keep on working unaltered.

Voting

Andrea Aime: +1 Alessio Fabiani: +0 Simone Giannecchini: +0 Ben Caradoc Davies: Jody Garnett: +1 Mark Leslie: +1 Rob Atkinson: Justin Deoliveira: Gabriel Roldan: Chris Holmes: +1

Links

JIRA Task Email Discussion Wiki Page