librelist archives

Re: [geonode] Feature specification draft for user profiles and permissions

From:

David Winslow

Date:

2010-05-04 @ 21:06

On 05/04/2010 04:34 PM, Sebastian Benthall wrote:
> Attached is a draft of the feature specification for the "1.5 - 2.0" GeoNode
> milestones.  I'm sending it along because it has what we have so far for a
> description of what we want for user profiles and access control.
>
> It's a bit dusty; we haven't really looked at it for some time.  My question
> is: is it (especially the final section on "Permissions") complete enough to
> inform the discussion of how we should implement the Django-side of the
> access control API?  Or are there open questions that I should work on
> specifying?
>
> I'm directing this mostly at David, but Ariel you might want to take a look
> as well.
>
> Thanks
Okay so quick overview:
We want GeoNode ownership and group membership to affect not just what 
users can do through the Django site, but also what is exposed through 
GeoServer (and eventually GeoNetwork as well).  In order to do this, we 
want to have the Django site's user model be authoritative (so that we 
don't have to reproduce the work that's been done in Django for user 
self-registration etc.)  Therefore, we need a way for GeoServer to check 
credentials for a Django user.  The idea is to simply have Django 
provide an authenticated web service that tells the logged-in user what 
layers he can see. When GeoServer receives a request for restricted 
data, it will forward whatever credentials it can extract from the 
request along to Django and use that list to determine whether the 
requested operation is allowed.

For this (ignoring the front-end work to make it accessible to 
end-users) we need:
a) users in Django
b) some way of determining all of the layers that a particular user is 
allowed to see/edit/whatever.
c) A django view that turns that list into a JSON or other serialized form.

We get (a) and (c) from Django! Woo! but (b) is a little fuzzy as 
Django's built-in authorization system works only at the granularity of 
model types.  So we need to figure out how we want to determine access 
for a user, that's the part of the spec that's missing.

 From this document, here's what I'm getting:
* Users can upload stuff. If a given user x uploaded some dataset, he is 
the Owner of that dataset and use the GeoNode to do anything that 
GeoNode supports with that dataset.
* Users who aren't the owners of a given layer can have some permission 
granted to it anyway (presumably by the owner).  These permissions can be:
   * Not permitted: Users with no permission to a resource may not view 
or edit the resource.
   * Read: Users with Read permission may view and, where appropriate, 
download the resource.
   * Write: Users with Write permission have the privileges of Read 
permission and the ability to edit the content of that resource.
   * Administrative: Users with Administrative permission have the 
privileges of Write permission and also:
     + when not precluded by other constraints on permission assignment 
(see items below) the ability to alter the permissions of other users 
and groups to that resource, and
     + the ability to delete the resource

I think the 'precluded by other constraints' bit doesn't apply to 
datasets, which is all we really care about in GeoServer for the moment.

What surprises me about this spec is that Groups apparently have no 
bearing on access control.  But if we don't need to have groups do that 
for this round, I guess we can implement the ACL stuff in terms of this 
security model.

--
David Winslow
OpenGeo - http://opengeo.org/

Ok, so it sounds like this is what we got for the requirements on this:


First:

> the front-end work to make it accessible to
> end-users
>

Rollie, we'll need your help with this, if you could make time for it in the
next week or two, the sooner the better.

And then these:

> a) users in Django
> b) some way of determining all of the layers that a particular user is
> allowed to see/edit/whatever.
> c) A django view that turns that list into a JSON or other serialized form.
>

The docs for the API are over here:

http://atlas.openplans.org/~dwinslow/geonode-spec/spec/technical/geonode-core/geoserver/permissions.html

I'll make tickets based on this shortly.

-- 
Sebastian Benthall
OpenGeo - http://opengeo.org

>
> What surprises me about this spec is that Groups apparently have no
> bearing on access control.  But if we don't need to have groups do that
> for this round, I guess we can implement the ACL stuff in terms of this
> security model.


If I recall correctly, in the discussions several months ago we concluded
that Groups and ACLs were too complicated for the first round of security
requirements.

Since *some* ability to control data access is very important for clients
using GeoNode as an SDI, we're going to go with just users on ACL's for now
and extend it when we get more time/funding.

-- 
Sebastian Benthall
OpenGeo - http://opengeo.org

>
>
> We get (a) and (c) from Django! Woo! but (b) is a little fuzzy as
> Django's built-in authorization system works only at the granularity of
> model types.  So we need to figure out how we want to determine access
> for a user, that's the part of the spec that's missing.
>
>
We could use this app [1] (or similar) as a helper to implement the list of
constraints David mentioned.
In any case, that is something that should land in Django proper anytime
soon [2]

[1]

http://opensource.washingtontimes.com/blog/post/coordt/2009/12/django-object-permissions-proof-concept/

[2]
http://docs.djangoproject.com/en/dev/releases/1.2/#object-level-permissions

On 05/04/2010 05:27 PM, Ariel Nunez wrote:
>>
>> We get (a) and (c) from Django! Woo! but (b) is a little fuzzy as
>> Django's built-in authorization system works only at the granularity of
>> model types.  So we need to figure out how we want to determine access
>> for a user, that's the part of the spec that's missing.
>>
>>
>>      
> We could use this app [1] (or similar) as a helper to implement the list of
> constraints David mentioned.
> In any case, that is something that should land in Django proper anytime
> soon [2]
>
> [1]
> 
http://opensource.washingtontimes.com/blog/post/coordt/2009/12/django-object-permissions-proof-concept/
>
> [2]
> http://docs.djangoproject.com/en/dev/releases/1.2/#object-level-permissions
>
>    

Awesome, I had no idea this was in the pipeline.  Guess I ought to hop 
on the Django mailing list.

-d