Warning, this page will be heavy on mathematics.
Define a User to be a (mostly human) member that can login on his User account. An Entity can be any object in the system, the most common will likely be Bodies, Circles and Users, but it is entirely possible for an Address, of even something such as a GlobalOption to be considered an Entity in this explanation.
First off, intepret the problem of dealing with permissions as a graph-based problem, a permission entity A has over entity B is then defined as a (uni-directional) edge from node A to B. The desired permissional model will then be the combined graph of these nodes and edges.
Every entity has 2 ways it can grant permissions:
- It can define permissions it has on itself
- It can define permissions it has over others
A permission can be granted by achieven either of those. Let's consider one of both cases:
- Entity A wants to do an action on Entity A, for example changing it's name. Entity A then checks if it can give itself this permission, which will likely be granted, and therefore this action will succeed.
- Note that while this might sound unecessary now, this will become useful later on.
- Entity A wants to do an action on Entity B, for example changing entity B's name. Let's say Entity A has this permission over others, and Entity B is considered to be in this 'others', therefore the action will succeed
- Defining this 'others': While the permission entity A has over others are defined in entity A, the definition of this 'others' is not, this is crucial to understand and probably feels counter-intuitive. Entity A does not define this others, but other entity define themself to be in Entity A's 'others'. This works as follows, using the example above: Entity A tries to do an action on Entity B (renaming), entity B says it requires permissions for this, and will thus start a search for this specific permission. Since it is Entity A trying to do the action, Entity B skips asking itself, but instead starts asking the Entity's it trusts (Entity B's delegates), Entity A happens to be one of these delegates, placing Entity B among entity A's others. Since entity A has defined the renaming permission over others and Entity B has been shown to be in this 'others', the permission is granted.
- It can help to say Entity B trusts entity A to make correct decisions on it's permissions.
- Defining this 'others': While the permission entity A has over others are defined in entity A, the definition of this 'others' is not, this is crucial to understand and probably feels counter-intuitive. Entity A does not define this others, but other entity define themself to be in Entity A's 'others'. This works as follows, using the example above: Entity A tries to do an action on Entity B (renaming), entity B says it requires permissions for this, and will thus start a search for this specific permission. Since it is Entity A trying to do the action, Entity B skips asking itself, but instead starts asking the Entity's it trusts (Entity B's delegates), Entity A happens to be one of these delegates, placing Entity B among entity A's others. Since entity A has defined the renaming permission over others and Entity B has been shown to be in this 'others', the permission is granted.
Optimizations:
- Remove the need for Users to be considered as an Entity (removes ~10.000 entities)
While some actions might be initiated by an Entity itself, we are mostly interested by the permissions User A has over entity X. Note that User A could be considered an
A proposal on implementing permissions.
...