[kforge-dev] How does the (new) access control system work?
rufus.pollock at okfn.org
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
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 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 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
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,
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
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.
* 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.
More information about the kforge-dev