GeoServer : GSIP 57 - Improving GeoServer authorization framework
This page last changed on May 30, 2011 by aaime.
Adding support for data filtering in GeoServer security framework
TBD, tentatively 2.1.0 or 2.1.1
Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred
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 DataAccessManager interface is going to be deprecated in favor or the ResourceAccessManager one, which would look as follows:
Comparisons with the old DataAccessManager:
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).
SecureCatalogImpl nowadays builds read only wrappers around most of the catalog resources.
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 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.
This section should contain feedback provided by PSC members who may have a problem with the proposal.
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.
|Document generated by Confluence on May 14, 2014 23:00|