Hi,
recently I've been looking into how to make it possible to have more powerful
data level security subsystem, in particular for when it comes to data access
control.
What we need the most at the moment is:
- being able to select specific features to be returned/to be made writable
(area filtering is one specific case)
- being able to hide attributes depending on the user
- being able to control the data access depending on the current OGC request
What I suggest is to have an overhaul of the DataAccessManager interface
in a way that provides the SecureCatalogImpl more information to perform
the native object wrappings.
What I come up with is the following:
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<Name> readAttributes;
// only used for vector data
List<Name> writeAttributes;
Filter writeFilter;
}
public static class RasterLimits extends AccessLimits {
MultiPolygon rasterFilter; // roi filter for raster and WMS data?
ReadParam params;
}
public static class WMSLimits extends AccessLimits {
MultiPolygon rasterFilter; // roi filter for raster and WMS data?
}
}
Highlights:
- when accessing a resource the access manager returns a hierarchy of
AccessLimit objects designed to express contraints on resources
- for vector layers that involves something that looks like two query
objects, but that is not in fact one. Query has much more than we
need, so I preferred to roll something new
- for raster layers we have a filter that can be passed into the
read parameters (for example, mosaic has this ability and can attach
attributes to the tiles to allow for complex filtering),
a geometry to be used for cropping, so that we return only data
in a certain area, and a list of read parameters that can override the
default ones (this will allow us to control ND coverage access in the
future)
- for cascaded WMS layers... uh, that's tricky. But we can still control,
at the very least, the area that we allow access to (and maybe roll
out some filtering) and cascade the read filter if we're playing
against a remote GeoServer (for other servers no luck, oh well..)
If an implementation also needs to know the current request it can
directly access Dispatcher.REQUEST.
I did not add it direclty as a parameter because:
- not all requests are OWS ones, REST ones do not have a similar
thread local and if they had it would look a lot different
- not all implementations would need to look into the current service
- there might be code that automates certain tasks for which the
current request is not available at all (think of scheduled tasks
such as automatically publishing all the layers found in a certain
store)
There is also the question of timing. Implementing the above would
requiere quite a bit of changes in the SecureCatalogImpl.
I also don't have the funding to extend the current default security
implementaiton, so I would just bridge the old with the new.
The project I'm envisioning this for would have to use an external,
centralized authorization system that the customer already has in
place. However, having the interface and the machinery to enforce
it will make it possible for others to improve the built-in implementation
later, or to add new ones (GEOXACML anyone?)
Feedback welcomed
Cheers
Andrea
--
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584962313
fax: +39 0584962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-----------------------------------------------------