GNIP-74: Geospatial security restrictions to layers

[afabiani]

GNIP 74 - Geospatial security restrictions to layers

Overview

Our proposal is to extend the GeoNode permission management window, in the "layer details" section, to ensure that a user can be associated with a geographical restriction in order to limit access to the layer to only the portions contained within a geographic restriction, excluding data outside of it from generating the response.

To do this we intend to add a new element at the bottom of the permissions management modal window as shown in the figure so that it will be possible:

• Select one of the users or groups are explicitly given access (except the resource owner)
  • Create or replace a geographical restriction by uploading a shapefile. Then save it.
  • Create or edit a geographical restriction on the map. Then save it.
  • Export an existing geographical restriction to GeoJSON or WKT.
  • Remove an existing geographical restriction.
• Repeat the above actions for another user or group.

Proposed By

@afabiani

Assigned to Release

This proposal is for GeoNode 3.0.

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

By using GeoServer along with GeoFence, GeoNode can benefit from a very powerful and granular security subsystem.
In particular, we would like to exploit all the potentialities of the security framework by allowing GeoNode administrators to be able to decide to restrict the access to some datasets by drawing/uploading an area of interest around it.

Proposal

This feature is compatible, and it will be enabled, only by using GeoServer with GeoFence extension backend.

GeoFence already allows defining rules with geospatial restrictions[1].

By adding an Access type LIMIT Rule to a Layer, it is possible to define a WKT area which will be used by GeoServer to filter out all the data not allowed to the selected User or Role.

From the GeoNode perspective, we don't need a deep change. We will need just a way to handle/draw such restriction areas and synchronize them with GeoFence somehow.

This will be mostly frontend stuff with a small change to the Layer model and APIs in order to store such pieces of information on the GeoNode database.

Backwards Compatibility

This feature won't be backported to releases older than 3.0

Future evolution

We can envisage in the future to add more restrictions types, like, as an instance, restrictions by Attributes.

Feedback

• No feedback yet.

Voting

Project Steering Committee:

• Alessio Fabiani: +1
• Francesco Bartoli: +1
• Paolo Corti:
• Simone Dalmasso:
• Toni Schoenbuchner: +1

Links

Remove unused links below.

• Email Discussion

[t-book]

@afabiani Absolutely +1, thanks

For my taste, the modal layout looks a bit "squeezed". How about having tabs for each section?

[gannebamm]

For me this is a feature for a relatively small subset of the community. I think the more advanced GeoFence security options can also be managed by GeoServer and its administrator. Since GeoNodes GUI is already full of things you can define putting more on it could clutter it and downgrade its usability.
Therefore a -0 from me

[jondoig]

+1 as I can see this being useful for collaborations between local groups (e.g. local councils).

Q: How do the geo limits relate to permitted actions? E.g. how do I say "Liverpool group can view and download the whole dataset, but only edit features in Liverpool"?

@t-book I was thinking tabs also, but at the top of the permissions dialog:

[gannebamm]

@jondoig I like your mockup and see the possible use-case

[francbartoli]

+1 for me. Good proposal!

[afabiani]

Ok for the new mockups, I like them.

For the time being the rule will be applied to all services. So, in the case a User or a Group will be limited to a certain area, it won't be able to view nor edit outside the limits.

[francbartoli]

@afabiani I wouldn't expect the votes from Paolo and Simone so we might agree to consider the GNIP approved yet with the majority of PSC members

[t-book]

I agree with @francbartoli