[kforge-dev] How does the (new) access control system work?

Thu Feb 2 15:12:38 UTC 2006

This is a work-in-progress intended to:
   * help one understand how the access control system works
   * check that my understanding (as presented here) is a correct 
reflection of what we have
   * to raise some questions about the current system and highlight 
areas we might want to improve in future

Protection objects:
===================

We represent things to which we wish to control access via 
ProtectionObjects (POs). There are several kinds.

   1. Those representing entire sets of domain objects such as Person, 
Project, Member, Service, Plugin POs

   2. Those representing application subsystems such as a subversion 
repository or a wiki. These are correlated to an **instance** of the 
plugin domain object to which they correspond. At present these POs have 
the name 'Plugin.<instance-name>' and, for example, to get hold of the 
subversion repository protection object we use the svn instance of the 
plugin domain object.

   3. 'Personal' POs corresponding to persons on the system. These are 
accessed via the specific person instance e.g. using the admin Person 
domain object you can get the 'Person.admin' PO. [ed: I am not clear 
what these protection objects are used for at present. See question below]

Permissions
===========

Permissions are then made up of a protection object and an action. 
Presently possession of a permission is a grant (and its absence 
implicitly a bar).

Roles
=====

Roles and persons then aggregate permissions.

A person has:
   1. A System Role: person.role
   2. Individual grants and bars: person.grants, person.bars
   3. Memberships in various projects. Associated to each membership is 
a role specific to that project. person.memberships[<project>].role

Context
=======

Actions are performed by the user in a particular context. At present 
the only thing to count as context is the project in relation to which 
an action is performed. For example if I am trying to look at the list 
of members on project X the context is project X.

How we do access control
========================

Thus each activity which needs to be controlled is broken down into a 
tuple consisting of:

   1. the person doing the action
   2. the object on which they are acting
   3. the action they are performing
   4. the context

Thus suppose that user joe attempts to look at the list of members of 
project foobar. This becomes:
   (person=joe, ProtectionObject=member, Action=Read, 
context=(project=foobar))

The access control system then a) creates a permission from the 
ProtectionObject and Action b)checks whether the person has the 
permission by doing the following in the order described:
   1. is there personal bar? If yes: DENY
   2. is there a personal grant? If yes: ALLOW
   3. is there a system role grant? If yes: ALLOW
   4. is there a context? If yes get the associated role. Does this role 
have a grant? If yes: ALLOW
   5. DENY

Remarks
=======

1. System-wide and project roles are the same. However project role 
permissions will only be applied in the context of a particular project. 
Thus suppose the Friend role has read permission on the ProtectionObject 
corresponding to a subversion repository. Then a person who has the 
Friend role as a system role can read **all** subversion repositories. 
If they have the role as a membership role, say on project foobar, then 
they can only read foobar's subversion repository.

2. There is no support for differentiating access across the same 
application subsystem on a project. For example you either have access 
to all subversion repositories or to none. This may be something we wish 
to look at in future.

Questions
=========

   * When are personal protection objects used? (Is it in relation to 
updating your own profile? If so could we not use context? By this I 
mean that when checking whether an update is permitted on a person we 
include the context of who this person doing the action is, and, if they 
are the same person, we give them admin rights)

   * Why do we need personal grants and bars? It would seem to make the 
system simpler if they did not exist. (this may relate to previous item)

   * looking at the ProtectionObject class it appears that the way it is 
currently written a ProtectionObject protects both the corresponding 
class object and its instances. Thus for example if we have the 
ProtectionObject 'Plugin' this will protect both 'Plugin' (Plugin 
objects in general) and 'Plugin.svn' (a subsystem application 
corresponding to subversion repositories). Similarly the 'Person' PO 
will cover both the set of persons and a particular person. Is this the 
behaviour we really want. For example I might want to be able to allow 
people to read the list of plugins on the system but that doesn't mean I 
want them to be able to read all subversion repositories.