GNIP - Groups and advanced permissions

[sbenthall]

Overview

Based on feedback from the community, it is necessary to be able to apply permissions to Groups of users.

This proposal includes use cases for advanced permissions and groups based on feedback from deployments in small and big organizations. The content could have been split in two different GNIPS but the use cases make the separation line blurry. In essence, without a refactor of the permissions, many of the use cases for Groups could not be achieved.

Proposed By

Jeffrey Johnson
Ariel Núñez

Assigned to Release

2.x

State

Approved

Motivation

Several Group and Group Security pull requests have been made but integrating the two was not easy. The main problem was the way Django's built-in groups model worked and the indirect relationships between Users and Models. Since Django 1.5, it is possible to override the User model and that opens the way to a harmonization.

Proposal

• Geoserver should respect the permissions by hitting directly the Geonode database without passing through http calls to GeoNode. This would also help the decoupling between GeoNode and Geoserver. The Geoserver plugin could use django as ORM through Jython or so. This is complete pending merging of the updated stored procedure: Geonode authorize layer fixes. geoserver-geonode-ext#22
• Use Django-guardian if possible otherwise use Django's permission system
• Use configurable user model instead of profile (refactoring current profile implementation): https://docs.djangoproject.com/en/dev/releases/1.5/#configurable-user-model (we are already using Django 1.5)
• Test whether the permissions on Layers, Maps and Documents can be centralized on the ResourceBase model (if this does not created and db query overload).
• Create the following permissions:
  • can_edit_style
  • can_edit_metadata
  • can_edit_data
  • can_edit_permissions
  • can_download
  • can_view
• Create a flag in the Layer model called 'published', this will allow admins to hide layers that have still not been cleared to be published, due to lacking metadata or styling.
• Here are some mockups for the layer list and detail pages with different levels of access:

Limited Access

Read only

Read and download

Full Editing

Edit Data

Use cases

1.  Administrator(Group): This is the highest level of access and will have full control over whole system. There will be limited users in this group and will be responsible to maintain the system.
   

   a. Admin(User)
   i. Create Group
   ii. Edit Group
   iii. Delete Group
   iv. Create User
   v. Edit User
   vi. Delete User
   vii. Change Permission

2.  Departments: Second level of access will have full control over subset of data. Each department will have separate group to ensure confidentiality of data. Hence there will be multiple group one each for every department. There will be two type of users in every department.
   

   a. Group_Admin:
   i. There will be multiple group admin accounts representing the head of the department or any other person in charge from the respective department (Many admins to one group).
   ii. This user can add and manage new account for their employees and assign limited privileges (subset of what he is assigned from top order) to them.
   iii. This group admin cannot view the detail of groups and users in other groups.
   b. Users:
   i. This is the limited access account created by their group admin.
   ii. By default he can only view data available in the group.
   I would like to assign limited rights to Department groups so that they can perform the user administration task at their end. But at the same time have limited rights to access the whole system users, groups and irrelevant data.

3. Public Viewing

WFP:

Actors:

• GIS Team at HQ
• GIS focal point in regions
• GIS officers in country

Layers:

• WFP facilities
  • Public viewing
  • HQ manages permissions. Multiple officers at the HQ have group admin permissions
  • Users should not be able to edit styles
    Optional:
  • Groups related to spatial extents
  • Permissions to edit a subset of the layer based on a group they belong to.

Administrative boundaries released by government

• Accessible by GIS focal point in regions and GIS officers by country
• Permissions managed by GIS officers in country

Issues

• For private layers: how to allow WMS access but automatically restrict WFS access when accessing outside of GeoNode through the service url
• Impact on the javascript widgets that allow users to change styles

Testing

Alternatives

• Adding a third party groups app with support for CRUD operations via UI

Feedback

(None yet)

[jj0hns0n]

This is present in the social-synth branch, and should get pulled to dev in time for 2.0. More work needed on the group permissions. @lukeman should be working on this at some point.

[ingenieroariel]

This seems to be finished, any bugs related to groups can have their own ticket.

[jj0hns0n]

Should not have been closed! The implementation sits in an incomplete
branch that has not been merged.

[ingenieroariel]

Thanks @jj0hns0n, oversight on my part.

[jj0hns0n]

moving to 2.1

[ingenieroariel]

We discussed this during the 2014 summit and will update the description above.

[simod]

we should also take into consideration #518

[simod]

we should take into consideration also #519

[riaanvddool]

Would this also allow groups within groups? Example department with sub-departments. This may be relevant: https://github.com/lukaszb/django-guardian

[simod]

hi @riaanvddool currently the groups permissions are implemented in master, I'm not sure whether is possible to make sub groups there. We are working towards a new permission system which is based on django-guardian. The idea is to include these improvements into the next release.

[jj0hns0n]

@simod can we go ahead and close this now?

[simod]

yes

[rajanski]

Hi guys, i cant figure how to get the view permissions on my layers as fine as in http://geonode.readthedocs.org/en/latest/_images/permissions.png,
can anyone provide guidance?

[jj0hns0n]

Which version are you using?

On Tue, Apr 28, 2015 at 5:46 PM, rajanski notifications@github.com wrote:

Hi guys, i cant figure how to get the view permissions on my layers as
fine as in
http://geonode.readthedocs.org/en/latest/_images/permissions.png,
can anyone provide guidance?

—
Reply to this email directly or view it on GitHub
#255 (comment).

[rajanski]

2.0.1 , i,.e. the one from the 12.04 ubuntu ppa

aptitude show geonode
Package: geonode
State: installed
Automatically installed: no
Version: 2.0.1+thefinal0

my installations only shows the permissions as so:

[simod]

@rajanski the new permissions system is implemented on 2.4 which is available as beta for ubuntu 14.04.

[rajanski]

ok thanks, could you post here as soon as 2.4 is released stable?
BTW geonode is a real fine piece of work , many thanks to all contributors for that!

[simod]

Thanks, will be for sure announced on the mailing lists and the website.
By the way, the 2,4 is totally usable and quite stable as well if you want to give a try.

[vdeparday]

By the way, I don't think we should close this one. The specs as described are not quite implemented yet. We are still missing:

• actual restriction on download on the GeoServer
• the level of permission that is called 'limited access' in the specs.

[simod]

Vivien if I understand correctly the limited access is about make people
aware of non permitted data right?

Il mercoledì 29 aprile 2015, Vivien Deparday notifications@github.com ha
scritto:

By the way, I don't think we should close this one. The specs as described
are not quite implemented yet. We are still missing:

• actual restriction on download on the GeoServer
• the level of permission that is called 'limited access' in the specs.

—
Reply to this email directly or view it on GitHub
#255 (comment).

Simone

[vdeparday]

Yes, exactly. I think it would be great because some GeoNode looks really
empty if you go to them because actually most layers are behind a password.
In the end, it would also likely foster more request to use the data and
more open data.

On Wed, Apr 29, 2015 at 9:33 AM, Simone Dalmasso notifications@github.com
wrote:

Vivien if I understand correctly the limited access is about make people
aware of non permitted data right?

Il mercoledì 29 aprile 2015, Vivien Deparday notifications@github.com ha
scritto:

By the way, I don't think we should close this one. The specs as
described
are not quite implemented yet. We are still missing:

• actual restriction on download on the GeoServer
• the level of permission that is called 'limited access' in the specs.

—
Reply to this email directly or view it on GitHub
#255 (comment).

Simone

—
Reply to this email directly or view it on GitHub
#255 (comment).

[simod]

Right. I think that this could be achieved by adding a tab in the search
engine for restricted data with a dedicated API. Do you think could make
sense? As mixing them into the normal data would be very tricky and lead to
slow performances.

Il mercoledì 29 aprile 2015, Vivien Deparday notifications@github.com ha
scritto:

Yes, exactly. I think it would be great because some GeoNode looks really
empty if you go to them because actually most layers are behind a password.
In the end, it would also likely foster more request to use the data and
more open data.

On Wed, Apr 29, 2015 at 9:33 AM, Simone Dalmasso <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

Vivien if I understand correctly the limited access is about make people
aware of non permitted data right?

Il mercoledì 29 aprile 2015, Vivien Deparday <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> ha
scritto:

By the way, I don't think we should close this one. The specs as
described
are not quite implemented yet. We are still missing:

• actual restriction on download on the GeoServer
• the level of permission that is called 'limited access' in the specs.

—
Reply to this email directly or view it on GitHub
#255 (comment).

Simone

—
Reply to this email directly or view it on GitHub
#255 (comment).

—
Reply to this email directly or view it on GitHub
#255 (comment).

Simone

[jj0hns0n]

@simod lets discuss during the sprint in light of djmp. Moving to 2.7 anyway.