Permission System Requirements

Target release	Beta 1 (MVP 0.1)
Epic	CORE-71 - Getting issue details... STATUS
Document status	DRAFT
Document owner	Derk Snijders
Designer	Derk Snijders
Developers
QA

Goals

Offer a flexible yet powerful access restriction system that suits the need of an organization such as AEGEE
Allow protection of data and actions from users that should not have access
Prevent developers from making accidental mistakes concerning data and action access
Provide an adaptable system for when (organizational) rules might change in the future

Background and strategic fit

As the OMS is very much a representation of the real world model, certain permissions, privileges, a real world person has need to be translated into the system. This means that for every action done by the system the permissions of the actor (user) should be checked.

Previous discussion on this topic.

Assumptions

Role: A role an object has, a collection of permissions.
- Examples: superadmin, moderator, journalist, guest
Permission: A single action that is given access to.
- Examples: viewing a members name, editing a body, changing a users role
Origin: The microservice that is the origin of an object, that stores the basic information of this object.
- Examples: Member's origin is core.
Internal/External object: When referring to an object from a microservice's viewpoint it is considered an internal object when the viewpoint (microservice) is the origin (microservice), if the viewpoint is not the origin it is considered an external object.
- Example: From the core microservice's viewpoint a Member object is internal, an Event object is external.
External roles: A role defined by an other microservice, likely unkown to the origin microservice
- Example: Adding a 'trainer' role to a member

Requirements

#	Title	User Story	Importance	Notes
1	Global roles	A user should have global roles (ie. 'superadmin') linked to it	Must have	Generally determined by retrieving stored information Linked global roles can be none (which gives it only the 'default' role)
2	Contextual roles	A user should have roles linked to it based on the context of the action (ie. 'board' of a local)	Must have	Generally determined on run-time based on the context Based on the context of the action means: Based on the member the user represents Based on the object involved with action: Based on the objects requested Based on the objects on which the action is performed
3	Permissions	A user should have certain permissions based on the roles linked to it	Must have	Linking permissions to roles
4	Flexible roles	A user should be able to easily edit, add and delete roles	High	Contextual roles are going to be hard to make flexible
5	Assignable roles	A user (with permission) should be able to assign roles to another user	Must have
6	Assignable permissions	A user (with permission) should be able to assign permissions to roles	Must have
7	Superadmin	A user should be able to have the role of 'superadmin', granting unlimited permissions regardless of other roles	Must have	This should be the only real system role
8	Performance	The system should determine and check the roles in a timely fashion	Must have	Every action in the system will be impacted by permission Aim should be < 100 ms. (TODO: Is this realistic?)
9	Disallow by default	The system should disallow access to data and actions by default	High	This reduces security leaks by programming mistakes
10	Define standards	The system should impose standards on how to communicate roles between microservices	High	Current proposal: Each object's origin microservice will attach global roles + contextual roles (from the requesting user) to a response object. (meaning the core microservice will do this for members and bodies) Each microservice is responsible for defining any extra roles themselves Be it by calculation, or by storing roles referenced to the 'external' object. The permissions system as a whole should be refactored and encapsulated in a separate microservice in the future, providing a centralized role access Should each microservice allow adding extra global roles when requested to do so by other microservices?

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question

Outcome

How would the implementation of such a system (possibly) look like?

See the earlier discussion

In what way should the permission system be distributed across the several microservice?

Each object's origin microservice will attach global roles to such an object. (meaning the core microservice will do this for members and bodies.)
- Additionally, these microservices should support adding extra global roles to these objects to be defined by other microservices that might require an extra global role.
Each microservice is responsible for defining the contextual roles themselves
- This can be implemented by querying the object's origin microservice
The permissions system as a whole might be refactored and encapsulated in a separate microservice in the future

Future releases

Separate role microservice

Not Doing

Only global roles (no contextual roles)
- It was deemed necessary to support contextual (scoped) roles