Data access control in WPS calls

[etj]

(Initial discussion in geosolutions-it/geonode#1198)

Some WPS processes may expose data that should not be visibile, while some other processes should be allowed.
For instance, we may want to allow stats computation on a layer (via gs:Aggregate), but disallow data downloading (gs:Download).

WPS processing in GeoServer provides a way to authorize processes on a per-user basis, but we need to filter access by using process, user and data (different users may have different access rights to different layers).

The idea to create a new domain for Rules only related to WPS does not fit in the while GeoFence scenario, because we may want to have a Rule that gives complete read access to a given layer (even for WPS processes), and such a Rule should belong to the Rule domain, so the new WPS-only-rules domain should also keep such base Rules in consideration. That would make a mess in the priorities computation.

This means that when we are selecting the Rules within GeoFence engine, we should also match the calling WPS process.
A new filtering field is needed within the Rule (the model will be changed) and within the filter (the related API DTO will change).
Adding a new WPS specific field in the generic Rule is really ugly, so we may call it something like "subfield", so that any future enhancement may use the same field for different purposes in different services; consider that the GeoFence engine should simply match and merge the rules, without entering in the complexities about what it is authorizing.

GeoServer tasks

There's a couple of points that should be addressed within GeoServer.
As reported in a comment in the initial issue, WPS processes may be chained.

We may have a chain (or, better, a tree) of processes.
For instance:

                  /--> Proc2 --> Layer A
 Call:   Proc1 --|
                  \              /--> Layer B
                   \--> Proc3 --|
                                 \--> Proc4 --> Layer C

In this scenario, GeoServer will call these AccessManagers:

• At the time of the WPS call, ProcessAccessManagers are called to find out whether the user can use the requested processes
• At the time of the retrieval of the data, ResourceAccessManagers to find out if the user can access the various resources.

Please keep in mind that when we are accessing, for instance, LayerA, we have a caller chain made of Proc1+Proc2. Proc1 is not accessing the Layer directly, but we may want to be aware that it's having (indirect) access to the layer's data.

As said, we want to leverage the ResourceAccessManager filtering, since at the ProcessAccessManager level we don't have all the info we need.

We need to implement:

• a way to tell the ResourceAccessManager the stack of WPS processes that want to access the given resource (work to be done in the WPS logic) A GEOS ticket is needed for this
• proper getting the access limits for the current access (work to be done in the GeofenceResourceManager). See next section. A GEOS ticket is needed for this

Computing access limits for WPS calls

About the "proper getting the access limits", this needs to be defined here.

The GeofenceResourceAccessManager will:

• request an AccessLimit for the requested Layer for each one of the calling processes
• merge all the AccessLimits in the more restrictive way (i.e., intersecting limits)

The alternative to merge the limits on GeoServer side is to merge them on GeoFence; this alternative implementation would anyway:

• require a list of subfield to be set in the RuleFilter -- we won't know how to deal with multi values: are they in AND or in OR in the DB query?
• require GeoFence to know how to merge the multiple rules retrieved using the different values: should the rules be used to restrict the access (intersection) or enlarge the access (unioning)?

Since the required behaviour in the WPS case is quite specific, while the subfield needs to be generic, it's better to put the merging logic on the geofence client side (that is, in the AccessManager).

[aaime]

The current proposal, as written, won't implement a ProcessAccessManager, meaning it won't do anything for Execute calls that either provide data along Execute (within the request) or refer to remote services (e.g., a GeoJSON file available in S3).

So if one wants to protect processes by user (e.g., allow DownloadProcess only to a given set of users, regardless of which dataset is requested), then the built-in WPS security will have to be used, which is already covering that need btw:

[etj]

As per the description, these are the modules involved in the issue:

Repo GeoServer: WPS processes info

Module	Task
wps	Add the process stack info (in a ThreadLocal (?))

Repo GeoFence: add new field

Module	Task
model	Add new field in class Rule
scripts	Provide sql script for update; update sql script for initial creation
*	Review classes addressing Rule fields
GUI	I would skip it entirely. WPS filtering is a new feature completely decoupled from existing ones.

Repo GeoServer: WPS data filtering

Module	Task
geofence-client	Implements WPS filtering in GeoFenceResourceAccessManager
geofence-server	Review model and controllers
geofence-server	Handle subfield in the GUI