Introduction

This page focuses on the access control inside AEGEE, which (type of) members should have what rights and access.

Access control is one of the most crucial elements inside an Online Membership Management system, therefore we should take the time to think about this and make sure it is as we want it to be. In my opinion this is not currently the case for the current version of the Core. Therefore this document is intended as a way to explain and document my reasoning behind this.

Current access control

The current access control is exclusively on a global scope, or you could also say without accounting for scopes. There can be multiple roles, each with permissions assigned to them, but these are all exclusively on a global scope. If you want to give access to a subset of objects this is currently not possible. It is all of the objects or none.

Proposed access control

The access control system I want to propose would need to introduce scopes to the roles and permissions. It should be a model of the real world organisational structure. This to not only comply with the current requirements, but also to try and anticipate for future additional requirements and even changing real-world situations. The exact implementation of it should be carefully thought out, as there are a number of things that complicate it. Things such as scalability and performance should be considered and also development time and complexity, therefore going for an all-powerful (Turing-complete? ) access control system is not an option. I suggest we take a good look at the needs that AEGEE has for the access control system and design the software implementation based on that.

The requirements

I started looking at the best organisational diagram of AEGEE I could find (1). I tried to extract a logical hierarchy out of it with permissions, which I attempted to write down in a somewhat formal language to avoid misconception and ambiguity. I realized that a strict hierarchical tree was not going to work within AEGEE. A solution to this was to have multiple separate hierarchical trees of permissions, this seemed to somewhat suit the organization's needs.

After making the first version of the permission overview I sat down with Lia and Tekla to discuss my findings with them and in order to check if I was right in some assumptions I made. Amazingly, it turned out to be a lot less complex then I anticipated in the first place. A full overview of the permission structure can be found here.

The diagram

The diagram that was made out of this can be found on the left, number 2.

There would be 4 top level types of objects, Bodies, Members, Events and Open Calls. Each of these top level objects has a set of possible affiliations with this object, rights are spread among these affiliations. The affiliations are all in a hierarchical tree with a lot of common roles:

default for externals
aegee for aegee members
board for boards of the object

NetCom and Comité Directeur were already identified as exceptional bodies that needed an exception, since there are so far only 2 I believe these can be treated exception cases, both of them only override a single affiliation type, they do not alter the hierarchical structure of the Body object.

The top level objects can be related to each other, these relations should be kept to a minimum as I expect this is where complexity and performance will suffer the most. Key to limiting these relations is limiting the amount of objects themselves. The relations can be seen in diagram (3), a legend is included as diagram (4).

I fully believe there will be additional exceptions identified during the development of the system, however I feel that this setup with top level objects with a hierarchical affiliation tree inside them suits the current identification of requirements while allowing room for changes and growth of the system.

In the future a more dynamic system (with nesting of objects?) would be really nice, however I believe we should first implement this to have something to start with and test our experiences.

Motivation

Advantages:

Better representation of the real organisational structure
Adds semantic power by means of a 1 level deep scope
Still allows moving the permissions from one affiliation to the other
Allows reusing of permissions (extending either objects or affiliations)
Has room for growth
Relatively simple to grasp
Follows the principle of divide and conquer by splitting the permission tree per object

Disadvantages:

Permission system has to be redone
Still more complex than the current system
Still not all-powerful

Implementation

I have not gotten into too much detail of the actual implementation, however I suggest to have a separate 'permission entity' attached to every body (Could be considered as a decorator pattern?), basically having two structural trees. One for the actual organisational structure (much like diagram (1)) and one for the permission structure. Aside from that it could be a challenge to implement this while staying flexible with microservices, although allowing a microservice to add its own top level Object could be a good solution.