• Security Model

last modified May 9, 2010 by ejucovy

­In which we attempt to describe how project security interacts with project tools.


Project containers impose a set of security constraints on the tools housed within them.  These constraints are partly dependent on the security policy (openness) of the project.

  • All project admins are always full admins of every tool within the project.
  • Any project member may be made an admin of a given tool.
  • Any X (see below) may be made a content creator within a given tool.
  • Any Y (see below) may be able to view content within a given tool.

­X (writing content) ­

Closed: project member

Medium: project member

Open: logged-in site member

Y (reading content)

Closed: project member

Medium: anyone (no login required)

Open: anyone (no login required)

­­

To reiterate: these describe the security constraints.  The actual security settings for an individual tool may vary and are a matter of configuration -- for example a given mailing list may be locked to project members in an open project, because this satisfies the constraints outlined above.

The TaskTracker grid-of-radio-buttons is probably the best expression of this we have.  Also TaskTracker is the only tool that actually allows the full set of configurations within the constraint-space.  Mailing lists and blogs don't.  They should.   (In particular many people want to be able to have closed mailing lists in non-closed projects.)


(Also should do a grid about configuration.)  -- what do you mean? -egj


Also there are additional roles which may map between "admin, creator, viewer" within a tool -- e.g. editor, contributor, commenter, task-assignee.  Should talk about these.

 

 

Notes on TaskTracker

TaskTracker stores a fixed set of Roles and Actions in its database.  They are defined in https://svn.openplans.org/svn/TaskTracker/trunk/tasktracker/websetup.py

Roles: Anonymous, Authenticated, ProjectMember, TaskOwner, ListOwner, ProjectAdmin

Actions and their associated permissions are set up when the task list is created: https://projects.openplans.org/opencore/browser/TaskTracker/trunk/tasktracker/controllers/tasklist.py#L100

Note that TaskTracker does not allow non-members to be list managers -- that is, only project members may be made list managers.  https://projects.openplans.org/opencore/browser/TaskTracker/trunk/tasktracker/controllers/tasklist.py#L159

TaskTracker does not store any user-level permissions persistently in its database.  Instead, it dynamically maps a user's role (from the OpenCore project) to its notion of Roles which then determines the user's permission level.

TaskTracker also tries to avoid storing user roles, instead preferring to get these from OpenCore.  The only things related to user roles that are stored in its database are the special roles ListOwner and TaskOwner.

 

Things not covered:

When a tasklist is created, its assigned ListOwners are stored in the database, but only if they are not already project admins.

* So when a project admin is demoted or removed from the project, he always loses his permissions in all existing task lists.  In the case of removal this is correct (since non-members may not be list managers).  In the case of demotion this may or may not be the intended outcome.

* This loss of permissions happens "immediately" since the permission was never stored in TaskTracker's database -- so the next time permissions are looked up, the former-admin's privileges are gone.

 

If a project member is made a list owner, and is then removed from the project, he remains a list owner!  This is an inconsistency in the security model. (To do: test that this is actually true, and then fix it.)

 

Sketch for Zine

Zine allows configurable Groups which can be mapped to Permissions.  These can be analogous to TaskTracker's Roles and Actions.

Each blog will have four fixed Groups: ProjectAdmin, BlogAdmin, ProjectMember, Authenticated

The permissions associated with these groups will be settable by administrators (analogous to TaskTracker's grid-of-checkboxes) with the following constraints:

  • ProjectAdmin: "can administer the blog" always (not configurable)
  • BlogAdmin "can create new entries", "can edit his entries", "can edit other people's entries", "can manage categories", "can log into admin panel", "can moderate comments", "can view drafts" always (not configurable)
  • ProjectMember "can create new entries", "can edit other people's entries", "can edit his entries", "can manage categories", "can view drafts" at maximum -- but the specifics are configurable per blog
  • Authenticated "can create new entries", "can edit his entries" at maximum -- but the specifics are configurable per blog (but only in open projects -- medium and closed projects do not allow content creation by nonmembers)

 

Following TaskTracker, we will only store mappings of users to groups in the case of BlogAdmins.  All other groups will be virtual groups.  We will have a middleware that, on ingress, sets the current user's Group in the database before Zine does anything, and, on egress, deletes that UserGroup record from the database.

 

For closed projects, we will have a "Gateway" middleware that rejects all requests from non-members.


How can we implement (project members // other users) can "not even see this blog"?

 

It sounds like the security configuration should actually live outside the tool.  The particular mapping of of permissions to roles would live within the tool, but choosing a setting would be external.  Note that there need not be any persistent storage of that setting -- the permissions should suffice .. except for the "not even see this blog" piece.  Hmm, need to keep thinking about this.  (Seems related to questions of "what is the default blog?" and "does this blog map project members/admins directly a la default-discussion-list")

 

Other stuff

We should store as little information as possible about users in the Zine databases (also like TaskTracker).

One question is how Zine handles notifications by email, and what Zine does with users' email addresses.  The approach we should take is to have notifications sent to a mailing list within the project.  Maybe the way to do this will be to hardcode all users' email addresses to that mailing list address.