Access Management
This page explains the controls that VIKTOR has to manage access to data and logic. These are divided in three categories: environment, workspace and app. The difference between workspaces and apps is explained here.
Environment access
Access to the environment can be setup in two ways:
- login with username and password
- Single Sign-On (for more info see this page)
Environment rights
Each user has two access attributes that determine the role they have. The possible combinations, together with their name are listed below. The matrix with their permissions is shown below.
| Access level | Developer access | Role |
|---|---|---|
| User | Internal user | |
| User | ✓ | Internal developer* |
| Admin | Admin user | |
| Admin | ✓ | Admin developer* |
| External user | External user | |
| External user | ✓ | External developer* |
* Developer access is an addition on top of normal user access
| external user | external developer | internal user | internal developer | admin user | admin developer | |
|---|---|---|---|---|---|---|
| invite users to organization | n | n | n | n | y | y |
| edit users on organization | n | n | n | n | y | y |
| remove users | n | n | n | n | y | y |
| create workspace | n | n | n | n | y | y |
| edit workspace | n | n | n | n | y | y |
| archive workspace | n | n | n | n | y | y |
| manage users in workspace | if workspace admin | if workspace admin | if workspace admin | if workspace admin | y | y |
| access private workspace | when invited | when invited | when invited | when invited | y | y |
| access internal workspace | n | n | y | y | y | y |
| access public workspace | y | y | y | y | y | y |
| list and modify workers | n | n | n | n | y | y |
| see apps | n | y | n | y | y | y |
| create app | n | y | n | y | y | y |
| publish app version | n | if maintainer | n | if maintainer | n | y |
Besides rights on the environment, there are more granular controls on workspaces and apps.
Workspace access
Access to the workspace is managed by setting the visibility of the workspace:
private: invited users see the workspace and have accessinternal: everyone inside the company (excluding external users) can see and access the workspacepublic: everyone can access the workspace using the URL (also people not logged in)
Workspace rights
By default users have "Read - All" rights if they can access the workspace, but more detailed rights can be configured by defining usergroups. The possibible permissions per object type are:
| category | detail | explanation |
|---|---|---|
| Read | Navigate | Minimum (navigation) access, excluding summary info and excluding editor access |
| Read | Basic | Makes an object and its summary information accessible to a user, not including the editor |
| Read | All | Gives access to all object information including the editor |
| Write | Create | Allows the user to create an object |
| Write | Update | Allows the user to update an object |
| Write | Rename | Allows the user to rename an object |
| Delete | Allows the user to delete an object |
Workspace admin
The administration of a workspace can be delegated to a specified "Workspace admin", which is assigned from the users on the workspace.
This workspace admin can:
- invite users (in the case of private workspace)
- set access levels for the users
- assign other workspace admins
App accesss
Apps are not accessed by users, users access workspaces (see this explanation). The apps only contain the logic, without data and no users.
Only developers (internal, external, admin) and admin users can see the apps and create them. Developers are automatically assigned as the first maintainer on the app.
App rights
Only app maintainers can publish new versions of an app. They are treated as being allowed to have access to the code. This means that error reports (with tracebacks containing code) are available to them.
App maintainers are not allowed to create workspaces. They can use their development workspace when developing, but need explicit access to relevant workspaces to get access to production data.