+1
I don't see any overkill in reusing (well, just using the first time)
the object-level permissions api in Django. When we get around to doing
per-layer permissions we'll be glad we did. This does lock us into
Django 1.2, but I don't think that's a problem.
-d
On 06/29/2010 11:59 AM, Luke Tucker wrote:
Hey,
I'm going to be working on putting some security around maps as
outlined in tickets 544-547[1]. I thought it would be prudent to ping
the list with what I'm thinking about these so far and make sure it
lines up with what's needed here and also with other security/user
related plans -- I know there was some discussion around permissions
as they related to layers earlier as well[2].
First, a quick review. These tickets call for adding a few particular
levels of permissions to individual maps that are assignable to a
couple of broad classes of users (anonymous, authenticated) and to
particular users. From the administrative perspective, permissions
are bundled into classes that are a series of proper supersets --
something like "unviewable", "read-only", "writable", or "admin".
Permissions cannot be taken away from specific users, so the
permissions a particular user has is the just the union of rights
assigned to all classes the user belongs to. Please see the tickets
for particular details.
From the developer perspective, I believe it is more sane and
djangorific to decompose these classes a bit rather than having any
entailment understood in the code that checks permissions. I propose
thinking of these classes of permissions as "roles" that are bags of
orthogonal permissions (in the django sense) that security checking
code understands. This will allow us to stick close to Django's
normal way of working with permissions from a developer perspective.
These role-permission relationships would probably just be expressed
in python since they are fixed from a user perspective. Something
like a very light version of RBAC[3] without any user definable roles
and role-permission assignments.
Django does not currently provide a backend for object-specific
permissions, so we'll need to implement some model backing that will
probably look like an ACL triple regardless whether we use this
indirection. Luckily, as Ariel mentioned, Django does provide a
standard api for querying such things that I believe we should follow.
It is fairly easy to provide a backend to the api in by subclassing
the normal django authentication backend that we're already using
(ModelBackend) and providing a few extra methods that look up the
rights for a user in the context of an object plus a little rigging in
settings.py[4]. We can dive deeper into how this might be expressed
later if any of this sounds sane so far :)
Overkill? It seems likely that there is heavy overlap with layer
related security and that the implementation of object level
permissions should be shared. Does any of this seem relevant or are
there strong feelings about how that needs to be implemented yet? I'm
also interested in whether any thought has been put into the
interaction between these contexts. Can I be warned about deleting a
layer that was used in a map that is unviewable to me? etc.
- Luke
[1]
http://projects.opengeo.org/CAPRA/ticket/544
http://projects.opengeo.org/CAPRA/ticket/545
http://projects.opengeo.org/CAPRA/ticket/546
http://projects.opengeo.org/CAPRA/ticket/547
[2]
http://librelist.com/browser//geonode/2010/5/4/feature-specification-draft-for-user-profiles-and-permissions/
[3] http://en.wikipedia.org/wiki/Role-based_access_control
[4]
http://docs.djangoproject.com/en/dev/topics/auth/#s-other-authentication-sources
