Access control in ArangoDB Oasis
This guide explains which access control concepts are available in ArangoDB Oasis (short Oasis) and how to use them.
Also see the video Access Control with ArangoDB Oasis.
Access control subjects
Oasis has a level structured set of resources that are the subject of access control.
Those resources are:
- Organizations: They represent (commercial) entities such as companies.
- Projects: They represent organizational units such as teams or applications.
- Deployments: The actual instances of the ArangoDB database.
Each of these resources have a set of operations that can be invoked upon them. For example, you can create a project in an organization.
Each operation (invoked on a resource) requires zero or more permissions.
A permission is a constant string such as
Permissions are defined in the Oasis API and are constant.
Users, groups & members
When you use Oasis, you are logged in as a user. A user has properties such as name & email address. Most important of the user is that it serves as an identity of a person.
A user is member of one or more organizations in Oasis. You can become a member of an organization in the following ways:
- Create a new organization. You will become the first member and owner of that organization.
- Be invited to join an organization. Once accepted (by the invited user), this user becomes a member of the organization.
If the number of members of an organization becomes large, it helps to group users. In Oasis a group is part of an organization and a group contains a list of users. All users of the group must be member of the owning organization.
As we’ve seen before, operations on resources in Oasis require zero or more permissions. Since the number of permissions is large and very detailed, it is not practical to assign permissions directly to users. Instead Oasis has roles. A role is a list of permissions.
Roles can be predefined or created custom.
Predefined roles are created by Oasis and group permissions together in a
logical role. An example of a predefine role is
deployment-viewer. That role
contains all permissions needed to view deployments in a project.
To give a user (or a group of user) access to resources of Oasis, you assign a role to that user (or group). This is done in a policy.
A policy contains a list of a bindings from role to user(s) for a specific resource. This means that there is a unique policy per resource.
For example the policy for the
Example.com organization contains bindings
from roles to user(s) (who must be member of the
These bindings are used to give these users permissions to invoke operations
As we have seen before, Oasis has a level structured set of resources:
Each resource in this structure has its own policy, but this does not mean that you have to repeat access control bindings on all these policies.
Once you assign a role to a user (or group of users) in a policy at one level, all the permissions of that role are inherited in lower levels.
For example if you bind the role
deployment-viewer to user
John in the
policy of an organization,
John will have all the permissions contained in
that role in all projects of that organization and all deployments in those
projects as well.
An other example. If you bind the role
deployment-viewer to user
in a project,
John will have all the permissions contained in that role in
that project as well as in all deployments contained in that project, but not
in other projects of the containing organization.