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

[Rufus Pollock]

Dear John,

Thanks for these clarifications which are really useful. For brevity in 
my response I have only kept in bits where there is more to discuss.

Regards,

Rufus

John Bywater wrote:
> Anyway, there are two kinds of protected names:
> 
> 1. Those describing a class of domain objects.
> 
> - the class is described with the name of the class
> 
> e.g. 'Project'
> 
> 
> 2. Those describing a instance of a class of domain objects.
> 
> - the instance of the class is described by appending the class names 
> with a full-stop followed by the result of calling the method 
> 'getRegisterKey' on the domain object
> 
> e.g. 'Project.administration',
> e.g. 'Service.14'

Ok, that is much clearer to me now :). It also seems a good idea. It 
also means I understand why having read access on ProtectionObject named 
  'Plugin' gives me read acces on ProtectionObject name 'Plugin.svn'.

However it does leave some abiguity regarding what we are currently 
terming subsystem applications. For example I am still not clear what 
ProtectionObject instance protects a subversion repository (and that 
repository only). At present this seems to be covered by 'Plugin.svn' 
but this ProtectionObject named 'Plugin.svn' protects /both/ the Plugin 
instance svn and the repository corresponding to the service of that 
type in a project. Not only are these different but I think we will want 
to have different permissions associated with them.

This brings us to:

[snip]
> At present we control access to Service instances by checking access to 
> the Plugin class used for the service. In other words, when a service is 
> accessed, the code checks whether or not the session person has access 
> to the plugin class. But there is no reason why this couldn't be 
> adjusted so that we control with instances of the Service (rather than 
> the class of the service plugin) by firstly creating protection objects 
> and granting a profile of permissions and then checking whether or not 
> the session person has access to the session object.

The thing is a service instance is different from a subsystem 
application corresponding to that instance. For example I might want to 
allow read access to the service instance as a domain object -- for 
example people can read the service details page:

http://local.kforge.net/project/annakarenina/service/svn/

But not be able to read the corresponding application subsystem (we 
**have** to think of a better name ;) !) -- i.e. the subversion repository

[snip]

>> Context
>> =======
>>
>> Actions are performed by the user in a particular context.
> 
> 
> 
> Actions are performed on protected objects....
> 
> Or we can say "permissions are exercised". Or something other than 
> 'exercise'.
> 
> Anyway, permissions are exercised by users....
> 
>> At present the only thing to count as context is the project in 
>> relation to which an action is performed. 
> 
> 
> 
> No. In general we control access to the system. That is the first 
> "context", although context isn't an implemented concept:
 >
> To control access to the system, we call on the SystemAccessController.
> 
> To control access to a project in the system, we call on the 
> ProjectAccessController.
> 
> The ProjectAccessController knows about a Project, and so it can (and 
> does) consider a possible Member of the Project by the Session Person. 
> The SystemAccessController can only consider the "personal" role and the 
> assigned system role.
> 
>> For example if I am trying to look at the list of members on project X 
>> the context is project X.
> 
> 
> 
> This gives the impression that there is an object somewhere called context.

Yes. Maybe I shouldn't have introduced the term (holdover from previous 
discussions) but it is perhaps useful to say that the 'context' 
determines what Controller to use. However as you say below it may not 
be useful to have this concept at all (in fact misleading).

[snip]

> To clarify, the ProjectAccessController extends the 
> SystemAccessController: The SystemAccessController takes steps 1-2-3-5, 
> and the ProjectAccessController takes steps 1-2-3-4-5.
> 
> That is the ProjectAccessController extends the behaviour of the 
> SystemAccessController by also checking for a role on the project.
> 
> But this isn't written as "context". There is no context object.
>
> NB It doesn't make sense to have a concept of context in the access 
> controller becaue there is no such general entity to assign permissions 
> to. There is a system-role, and the system is refined with 
> project-roles. The system presentation uses the SystemAccessController, 
> unless this is overridden. It is overridden by the part of the kforge 
> presentation which deals with objects of a project, which uses the 
> ProjectAccessController.

Nicely put. It makes me think that, as you suggest below, we could have 
a PersonAccessController to deal with special person stuff such as 
updating yourself.

>>
>> Remarks
>> =======
>>
>> 1. System-wide and project roles are the same.

I meant that roles that can be assigned at the system level and the 
project level are the same -- which is what you are saying:

> 
> No, they can be different. But there is one set of roles from which to 
> select. And a Person can only have one system role, and one role per 
> membership of a project. They also have their own "personal role".


[snip]

>> 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)
> 
> 
> 
> We could create a PersonAccessController, to echo the "personal role" in 
> the same way that membership roles are echoed in the 
> ProjectAccessController, but then we're starting to repeat the DOM class 
> system, which is a bad smell.

This is tough one. Adding personal grants and bars might also be seen as 
a 'bad smell'. There seems to be 3 options:

i) personal grants and bars
ii) PersonAccessController
iii) change SystemAccessController to have an exception when the person 
doing the action is protected by the ProtectionObject supplied (for 
example give them the admin role here ...)

Which do people think is best?

[snip]

>> 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.
> 
> 
> 
> Well, if we want to make more distinctions, then we'll need to make more 
> protection objects. To distinguish between Plugins and Services, we'll 
> need to create both Plugin and Service objects.

I think we may need more than that: its the distinction between 
application subsystems corresponding to a service and service itself -- 
see previous comments.

> If this basic foundation is clear enough, I think we should move on to 
> reviewing what the roles names mean to people, how permissions should be 
> assigned to the roles, and which objects should be used as the protected 
> objects for the access checks. That's the real discussion.

agree

> I think we need another role: Enemy. Enemy can read / but nothing more. 
> Then, Visitor also gets to read projects, create Person. Friend can read 
> most stuff. Developer can also update somethings. Administrators can 
> create/delete.

+1

> Then we should think of different levels of access. If the default 
> visitor role is low, then registering will make more of the system 
> visible. If system role is lower than default project role, then joining 
> a project will make more a that project visible. If a default project 
> role isn't the highest role, then some of project actions can still be 
> reserved.

Yes. Question is, for example, how do we support the fact that we want 
to allow project admins to either allow or not allow read access to 
their subversion repositories on a project by project basis. This was 
originally (and is now again the case after various changes to 
permissions) by making visitor a member of your project and giving them 
the Friend role (or higher).