[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).
Regards,
Rufus
Requirements:
=============
1. We must support different roles per project and at least:
Administrator
Member
Guest
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
administrator
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
guest
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?)
Implementation
==============
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
Kforge
------
In our case there are two kinds of ProtectionObject. They will be
indexed by name as well as id.
ProtectionObject
[A protection object for each domain object]
[A protection object for each plugin instance]
PermissionType
accessType
Role
name:
permissions
hasPermission
A person has two roles:
1. System Role (unique per person)
2. Project Role (per project)
Person.getRoleSystem(): Role
return getRoleProject(administrationProject)
Person.getRoleProject(project):
if isMember(person, project):
return person.members[project].getRole()
elif isMember(registry.persons['guest'], project):
return registry.persons['guest'].members[project].getRole()
else:
return defaultRoleProject
Member.getRole(): Role
Person.hasPermission(permission):
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:
RoleProject
RoleSystem
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