Skip to main content
Version: 🚧 Next

Access control

The application uses Role-Based Access Control (RBAC). This page explains it's different components and how it works.

Application context​

The application has various contexts (major parts of the application).

  • Investor: The part of the application that the investor uses (or an FSP user with an investor's mandate), typically when going through a flow.
  • FSP: The part of the application to manage dossiers, parties, documents, ...
  • Admin: The part of the application that is used to configure the application (lists, questionnaires, providers, ...)
  • System: Parts of the application that are not directly accessible by users. For example the API gateway which is used by machine-to-machine communication for integration with third-party systems

Roles & permissions​

A role is a collection of permissions. Permissions will grant the user access to (parts of) application contexts.

A few examples of roles the build-in roles:

  • Investor:
  • Administrator
  • Gateway
  • Office manager
  • Advisor
  • ...

Roles are the entities that are linked to a user in a specific application context. For example, a user might be given and "office manager" role in the FSP application context, for a specific FSP.

Legacy vs standard roles​

The access system of the application is currently being migrated from strictly role based access, to more fine-graded role/permission based access. During this effort, some built-in roles are duplicated. For those roles, there will be a legacy and a standard variant.

When a part of the application moves to permissions, the upgrade adds the matching permissions to the standard roles, so users who hold both variants keep the same access. Custom roles are not changed; see Custom roles and migrations.

⚠️ Notes:

  • A user that should have a certain role assigned, should now be assigned both the legacy and standard roles.
  • Configuration that influences roles linked to users, for example SSO providers, needs to take both legacy and standard roles into account.

Working

When a user is logged in, the application loads all roles that are assigned to a user. It groups those roles by application context (and reference) into the corresponding context.

This means that a user will have one or more contexts. If multiple contexts are available, the user will be able to activate either one of them.

When the user accesses a part of the application, the application will load the active context and all its roles that were added in the first step. It will then load (and merge) the permissions for all those roles and validate whether the required permissions for that part of the application are available inside the active context's roles/permissions