[kforge-dev] permissions/access control system

Rufus Pollock rufus.pollock at okfn.org
Mon Sep 26 11:13:50 UTC 2005

This email presents an analysis of the needs of the Kforge 
permissions/access control system and proposes a solution (which is now 
implemented :) -- i meant to send this mail last week).




   1. We must support different roles per project and at least:
   2. We must allow for different type of projects including:
     1. private projects in which all services are only accesible to 
members (including the member list?)
     2. public projects in which all service are world-readable but only 
writable by members
   3. We must allow for system wide roles such as a system wide 

Kforge currently implements a project-role-based access control system. 
That is roles are interpreted per project and not system wide. So all 
projects have the same set of roles with the same set of permissions. 
This is problematic as it means we cannot support requirement 2. We also 
have difficulty supporting 3.

Different Types of Project

We can support different types of project by:

1. define a reserved person guest which is automatically made a part of 
every project and cannot be removed.
2. Create at least the following roles: Administrator, Developer, 
Guest-Private (no access), Guest-Public (read access)
3. Allow project administrator to assign project members to roles
4. Automatically assign all non-members of project to the role of member 

System Wide Permissions

Propose to address this by having a reserved project called 
administration (or admin) and assigning system wide roles based on roles 
in this project (with all non-members having role guest). However since 
the kinds of activities associated with system are different this does 
not fit neatly into layout above (for example what permissions does a 
member of the admin project have on a) project X b) project admin?)


Basic RBAC

+-----------+     +----------------+            +----------------+
|   Role    |     |   Permission   |            |ProtectionObject|
|-----------|     |----------------|            |----------------|
|    id     |     |       id       |      __.---|       id       |
|   name    |1   *|protectionObject|<>.-''      +----------------+
|permissions|<>---|     right      |<>..___     +--------------+
+-----------+     +----------------+       ``---|PermissionType|
                                                 |      id      |
                                                 |  accessType  |
                                                 | [predicate]  |

NB: it is often more common for PermissionType to be named Right


In our case there are two kinds of ProtectionObject. They will be 
indexed by name as well as id.

   [A protection object for each domain object]
   [A protection object for each plugin instance]



A person has two roles:
   1. System Role (unique per person)
   2. Project Role (per project)

Person.getRoleSystem(): Role
   return getRoleProject(administrationProject)

   if isMember(person, project):
     return person.members[project].getRole()
   elif isMember(registry.persons['guest'], project):
     return registry.persons['guest'].members[project].getRole()
     return defaultRoleProject

Member.getRole(): Role

   if person.getSystemRole().hasPermission(....):
     return True
   elif project != None:
     return person.getRoleProject(project).hasPermission(....)

Remaining Work

To think futher about system roles vs. project roles. For example how do 
we ensure system roles can only be assigned to members of the 
Administrator project? Perhaps we should create two different types of role:

To integrate this permissions system into:

   1. Django
   2. Service and project access
     * propose creating a access controller and moving away from crude 
apache + mod_auth_postgresql setup

More information about the kforge-dev mailing list