...
The permission system is based on permission objects in the db which are checked before executing a request. Which permission is needed for what action is hardcoded and can be found in the api documentation where it is described for every request. A permission has the following properties:
| field | desc |
|---|---|
| scope | Where that permission is applied. Can be global (whole system) or local. Local means it is only applied inside the body the user got it from plus all bound circles in that body plus all members of that body. |
| action | Which action, e.g. update, view, etc |
| object | Which object, e.g. circle, body, etc |
| filters | Field filters in the form of nested objects with a field parameter {field: "something"}. See separate section for filters |
| always_assigned | Boolean whether the permission is auto-assigned to everyone in the system |
| description | Description |
For easier communication we write a permission as scope:action:object or if scope doesn't matter as action:object
...
To see a list of permissions, visit https://oms.aegee.org/permissions, It is thinkable that new microservices can add a new set of permissions to the system to handle specific functions.
Permission contexts
There are different objects in the system that get permission differently, in total there are 4. They can be checked through the /my_permissions request on each of the objects.
- Global for general requests only the global permissions are regarded. For this the user gets assigned all auto-assigned permissions and all global permissions that he received through any circle membership. All other permission contexts take this as a basis
- Body for body-related requests additionally all local permissions that are aquired through membership in a bound circle of that very body are added to the permission list.
- Circle in case it is a bound circle, all body permissions the body that the circle is bound to are added. For free circles, nothing is added. Circle-admin status however brings some additional permissions.
- Member member-based request additionally get all body permissions of all bodies the member is part of. So only in case the requesting member and the requested member have bodies in common, permissions will be added. If you are requesting yourself, you get full permissions.
Future permission system improvements
- Extending scoping options. Instead of just local and global we could also use a body type of a local as scope.
- Explicit triggers for contexts. Currently it is hardcoded which additional permissions e.g. a circle_admin gets, it would be nice to have a trigger object with a many to many on permissions that dynamically adds permissions on requesting the associated context