Skip to main content

Authorization Systen

The authorization system in Vyndara handles Roles to rights mapping and virtual users. Authentication itself is done via the OpenID Connect Provider of a tenant. The roles are assigned to the user by the OpenID Connect Provider and are then used to map the rights to the user.

Roles​

Roles are quite easy, they are synced from the OpenID Connect Provider and are then used to map rights to the user. Its not possible to create roles in the Vyndara Platform, they are only synced from the OpenID Connect Provider.

Rights​

Rights are the actual permissions that a user has in the Vyndara Platform. They are mapped to roles and can be used to control access to resources and actions within the platform.

Right Structure​

Each right consists of the following parts:

ActionPermission:

  • Display: The display name of the permission, e.g. Read Entity, Write Role. Can be empty then a combination of the scope type, scope and action is used.
  • ScopeType: The type that the scope is applied to, e.g. entity, role, custom.
  • Scope (optional): The identifier of the scope that the permission is applied to, e.g. entity definition name, role_id, custom_id. Can be empty, then all scopes of the type are granted.
  • Action: The action that the user can perform, e.g. read, write, delete, trigger.
  • Conditions (optional): The conditions that must be met for the permission to be granted which can be a list of conditions that are checked against the context of a permission validation.

Type Registry​

To support a broad range of rights the system uses a type registry. This registry stores informations per tenant about available scope types and actions that can be used in the permission system. All other scope types and actions are not allowed to be used in the permission system and will be rejected by the system.

For scopes and conditions the is no registry and no validation, so the system allows any scope and condition to be used. The systems that register the rights are responsible for delivering the correct scopes and conditions via auto completion if wanted. To support this the registry knows from which system the rights are registered and sends this information to users so it can be used to show the correct scopes and conditions in the UI.

Default registered rights​

The system registers some default rights that are required to even grant rights to users or they are basic rights that not belong to a specific system and are platform required by default.

These rights are delivered with the auth system directly.

  • App: app.<scope>.read, app.<scope>.write, app.<scope>.delete
  • Role: role.<scope>.read, role.<scope>.write, role.<scope>.delete
  • Right: right.<scope>.read, right.<scope>.write, right.<scope>.delete
  • Custom: custom.<scope>.<action> where <scope> is the custom scope and <action> is the custom action. So fully flexible to use.

Virtual Users​

This is a feature the allows tenants to create custom users that can not be logged in into UIs and rather can be used for automation. Some examples are, API to API requests. End users to API requests or Vyndara Workflows.

Since Vyndara has a Zero Trust policy it is not possible to access endpoints without a access token. That can be a JWT from the registered auth provider with a user or a virtual user token.

When creating a virtual user it is possible to create one credential token for him, this token can after that no longer be read. It can be passed to api requests to retrieve access. Else permissions for the user are handled the same way as roles and rights for normal users, except the token can get rights directly assigned and roles are also mapped inside the Vyndara Platform.

Initial Tenant Right setup​

When a tenant is created, its is required to select a role from the configured OpenID Connect Provider that is used as the initial administrator role. The migration will then create the initial rights for this role while initializing the tenants database structure.

Technical Implementation​

For technical implementation details see the Technical documentation.