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
