Authorization
This document covers information about authorization and how permissions handled
TL;DR
Authorization VS. Authentication - While Authentication is the process of ascertaining that a user really is who he claims to be, Authorization refers to rules that determine who is allowed to do what (e.g. Jane may be authorized to create and delete databases, while John is only authorised to read).
wunderbon uses a simple Role
and Scope
based access control system (RBAC/ABAC). A Role
is a composition of Scope
based access rights. A Scope
is either the representation of an entity (e.g. User
, Identifier
, Location
, ...), the representation of a collection of entities or a group of different kind of entities. Access rights are subdivided into Create
, Read
, Update
and Delete
permissions.
Access Rights
The access rights for each entity will be split by the well known CRUD
principle into the following 4 basic operations and its respective permission to execute it:
Permissions
Create
(c)Read
(r)Update
(u)Delete
(d)
An example of scope definitions for the entity User
:
Entity User (as Example)
Permissions regarding single entity:
user:create
user:read
user:update
user:delete
Permissions regarding collection(s) of entity:
users:read
This example shows the CRUD operations which are reflected by their HTTP-Methods or -Verbs (POST, GET, PATCH, DELETE).
Possession
The ownership or possession is important when applying RBAC/ABAC rules on endpoints (resources/entities).
Owner (special scope)
Owner will inherit automatically ${entity}:delete or other (e.g. ${entity}:update if available) when calling an owned entity through a provided endpoint.
This special scope takes place where ever a user is the owner of an entity. For example - if a user creates a new Identifier (Loyalty-Card or something like that) then he will of course take the ownership of this new Identifier in his account. So if he now sends a Delete
request, then the ACL
will only need to check if the owner of the resource being requested for deletion is in ownership of the calling user.
Any (special scope)
As opposite and for the Ying and Yang equality, there is another special scope. This one is the opposite to owner
. Every resource that is not covered by the primary scope owner
is covered by any
. As an example: While a User
entity is protected and can only be accessed by the user itself or a wunderbon Administrator, a Location
entity of a Merchant
is treated as public good and so it is scoped as any
. Every user of wunderbon is allowed to read
all Locations
through the Location
endpoint.
Updated over 2 years ago
Continue with our guided tour. Now, we would like to tell you more about our preferred Content-Type
...