Configuring Runtime Permissions
Runtime offers its administrators the ability to manage access to the interface on a granular level to a wide variety of self-configured user groups and roles. Using this system, it’s possible to grant specific users or groups (such as Testers, managers, data officers, etc.) access to certain functionality.
In Runtime, we make the distinction between global permissions and local permissions. The former is a system which is wide-spread in terms of access control. You can specify certain rights to a user or user group, and these rights are applied to the entire platform. For example, if you grant user “Joseph” the right to view existing groups, that user will be able to view every single group. If usergroup “Testers” is granted the permission to edit environments, this usergroup can edit every single environment.
The latter, however, allows admins to limit the access and rights of a user or user group on a more specific basis. You could, for instance, grant user “Joseph” the right to view a specific existing group, but not other groups. This can be distilled down further, making it possible to only allow specific actions on certain groups, environments, and workflows.
This chapter of the documentation is split in two parts, trying to look at global permissions first, and then local permissions. However, the configuration of user(group)s and roles is all done in the User Management screen, so the information displayed here is applicable to both local and global permissions.
Global Permissions
If an administrator presses the User management button on the left-hand side legend in the Runtime user interface, the following screen is opened.
![](../../__attachments/391217339/image-20221208-144419.png?inst-v=9faf47d4-7060-40c4-b0f6-6c85db0afb12)
This is an oversight of all existing users and their data. Let’s go through the various tabs and look at what we can configure here.
Users
The users tab shows a list of all currently registered Runtime users with their personal information. This is information that is all either entered manually by an administrator during user creation, or information imported through LDAP. If a user is created manually it will be designated with directory: local. Conversely, if a user was imported through an LDAP connection it will be designated as directory: LDAP. On the right-hand side of any one row in this table an option menu can unfolded by pressing the “…“ button. Here, you have three options, detailed in the following three sub-chapters. After this, we’ll be taking a look at how to create a new user, using the top-right Add user button.
Change Password
Selecting this option allows you to change the user’s password. In order to do this, a new password must be entered, and verified by entering it again. If the user is imported through LDAP, this option is disabled.
Edit
This allows you to change the account details (excluding the password) of an existing user. All changes are effected immediately upon saving.
Delete User
Removes a user from your user base. Disabled if the user has been imported through LDAP. In order to remove LDAP users, remove them from your LDAP connection, or adjust your filters to exclude this user. After synchronization this user will be removed automatically.
User lock-out
When a user attempts to log into Runtime, and enters the wrong password 5 times, the user is locked out of logging in for 30 minutes. After this timer, the user can retry logging in. If an administrator has accidentally locked him/herself out, it is possible to reset the lock-out timer by restarting Runtime.
Add User
Upon clicking this button, the user is taken to the User Details screen. Here, you can supply the following values to create a new user:
A username (this is used to log in, paired with the configured password).
A full name to identify the user.
An e-mail address associated with the user.
A password.
Password complexity requirements
When configuring a password for a user, it must at minimum:
Be at least 8 characters in length
Contain at least one lowercase character
Contain at least one uppercase character
Contain at least one number (0-9)
Contain at least one special character ('-!"#$%&()*,./:;?@[]^_`{|}~+<=>)
User Groups
A user group is a logical unit that allows administrators to assign a role (a collection of permissions) to a group instead of to a single user. The benefit of having such a system is that it eliminates the need for re-entry work if permissions need to be changed, and allows administrators to have a clear oversight of who should have which rights. A common use for this would be to split users into groups based on teams, or on the basis of function.
Example:
Runtime is used in an organisation which executes masking and subsetting workloads for three distinct departments (Finance, Analytics, Logistics). Because we’d like our testers to only be able to start runs or upload applications to their assigned departments, we’ve made three user groups:
Project Finance
Project Analytics
Project Logistics
This allows us to split local permissions across our users without having to adjust every single one, and makes it easy to modify the permissions if, for example, a tester is transferred from the Finance project to the Analytics project.
A role based implementation of this same organisation would be to split all involved roles in their own groups, which for the example given above would be:
Testers
Managers
Controle
These groups will need to be combined with roles to create concrete permissions, as detailed in the following chapters. This example is illustrated below.
![](../../__attachments/391217339/image-20221212-142528.png?inst-v=9faf47d4-7060-40c4-b0f6-6c85db0afb12)
In the user groups screen you’ll see that all existing groups are listed by name, with their total user count displayed under the Members column. On the right-hand side of any one row in this table an option menu can unfolded by pressing the “…“ button. Here, you have two options, detailed in the following two sub-chapters. After this, we’ll be taking a look at how to create a new user group, using the top-right Add group button.
Edit
This option allows you to change which members are a part of a specific group, as well as modify the group name. The view generated here is functionally identical to the Add group option generated below.
Delete
This will permanently remove the group. Doing this has no impact on any existing users which are in the group, aside from removing any rights given to the group that they previously had.
Add Group
In the top-right hand corner of the user groups tab, you should see the Add Group button. Upon pressing this button you should see the following screen:
![](../../__attachments/391217339/image-20221212-090019.png?inst-v=9faf47d4-7060-40c4-b0f6-6c85db0afb12)
In this menu, you can define a name for the group in the Group Name text box, as well as add a starting selection of existing users to this group. To do this, click on the Add members box and select the user you’d like to add. Repeat this until you have the desired amount of users. After this, press the Add button on the right side, and a short oversight of the users will be displayed under the Members section. The information displayed here is identical to the information shown in the Users tab as detailed earlier.
Roles
In the roles tab, you can create new or edit existing roles. Roles are containers for individual rights, which describe a set of actions and rights. Without a role, a user or user group does not have any rights or permissions in the Runtime interface. Upon opening this tab, you should see an oversight of all existing roles in table format. On the right-hand side of any one row in this table an option menu can unfolded by pressing the “…“ button. Here, you have two options, detailed in the following two sub-chapters. After this, we’ll be taking a look at how to create a new role, using the top-right Add role button.
Edit
This options allows you to change the existing rights of a role. Functionally, this is the same as the Add Role button. For reference on how to configure a role, this is detailed in that chapter.
Delete Role
This option deletes the role permanently, removing it from any users or user groups it was attached to.
Add Role
In this section, you’ll be able to create a new role. You can specify a name for this new role in the Role name text box. Following this is a large collection of individual permissions divided among several logical groups. Permissions can be toggled on and off by clicking on the corresponding row’s tick-box. Following below is an oversight of every permission, and a short description of what it does.
Permission | Description |
---|---|
Global Permissions | |
Manage users/LDAP | Grants access to the Users and LDAP tab of the User management menu. Through this, rights are also given to create, modify, and delete users. Additionally, the right to (re)configure an LDAP configuration and import LDAP users is given. In versions of Runtime that include 2FA, this permission also grants access to the Disable 2FA option while looking at the user overview. |
Manage License | Grants full access to the License menu. Enables users to enter a new license code as well as view the license details. |
Manage agents | Grants full access to the Agents menu, allowing users to manage Runtime agents. |
Manage API tokens | Grants full access to the API tokens menu. This allows attached users to create new API tokens. |
Manage global permissions | Grants access to the Roles and Permissions tab of the User management menu. Implicitly, this allows any user with this role to edit all Runtime-wide permissions. This includes assigning additional rights to one’s own role. |
Create group | Grants access to the New group button under the Groups menu, allowing any attached users to create groups. This does however not grant any other rights on any groups created through this permission. |
Create workflow | Grants access to the New workflow button under the Workflows menu, allowing any attached users to create workflows. This does however not grant any other rights on any workflows created through this permission. |
Upload application | Grants access to the Upload application button under the Applications menu, allowing any attached users to upload new applications to Runtime. |
Delete Application | Grants access to any attached users to delete existing applications in the Applications menu. |
Group permissions | |
View group | Grants the right to view all existing groups in the Groups menu. |
Rename group | Grants the right to rename existing groups in the Groups menu. |
Delete group | Grants the right to delete existing groups in the Groups menu. |
Manage group permissions | Grants the right to add permissions to an existing group. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning certain users or user groups a role on a group. |
Add environment | Grants the ability to add a new environment to any specific group through the Add environment button. |
Environment permissions | |
View environment | Grants the ability to view all environments in the groups which this role can view. |
Rename environment | Grants the ability to rename all existing environments in the groups which this role can view. |
Delete environment | Grants the ability to delete all existing environments in the groups which this role can view. |
Manage target connection | Grants the ability to reconfigure the connection data used for all existing environments in the groups which this role can view. |
Manage environment permissions | Grants the right to add permissions to an existing environment, provided the role has access to the group it’s contained in. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning certain users or user groups a role on an environment. |
Clean run history | Grants access to the Cleanup history… button in the Run history tab of any environment the role can view. |
Manage environment parameters | Grants access to the Settings tab of any environment the role can view. |
Manage installations | Grants the ability to install/upgrade or uninstall uploaded applications on any environment the role can view. |
Manage triggers | Grants full access to the Triggers tab on any environment the role can view. |
View run history | Grants the ability to view the Run History tab on any environment the role can view. This also allows the role to view and download any artifacts created through the execution of runs on an environment. |
Manage active run | Grants the ability to view active runs of any environment this role can view. This includes being able to see the logging and artifacts of a run. |
Start a new run | Grants the ability to start a new run through the Start… button on the Installed applications tab of any environment this role can view. |
Workflow permissions | |
View workflow | Grants the ability to view all existing workflows in the Workflows menu. This does not convey the right to view the edit view of a workflow, and thus the information within workflow components cannot be viewed with just this permission. |
Delete workflow | Grants the ability to delete existing workflows. |
Execute workflow | Grants the ability to start the execution of an existing workflow through the Execute button. |
Edit workflow | Grants the ability to edit existing workflows, changing their configuration. |
Manage workflow permissions | Grants the right to add permissions to an existing workflow, provided the role has access to the workflow menu. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning certain users or user groups a role on a workflow. |
View history | Grants the ability to view the history of all existing workflows through the History letterbox. |
Clean history | Grants the ability to clear workflow history. Functionally, this grants access to the Clear history button under the History button. If the View history permission is not granted, this role does not function. |
Permissions
In the Users/User groups tabs it’s possible to create users and groups to identify people who need to use Runtime, and their individual access to the user interface. In the Roles menu, it’s possible to define a set of global permissions. In the Permissions menu we can match these two together in order to create an administration of global permissions. The interface should look something like this:
![](../../__attachments/391217339/image-20221212-102858.png?inst-v=9faf47d4-7060-40c4-b0f6-6c85db0afb12)
Here, you can see all of your existing roles formed into separate tables. These role tables can then contain either users or user groups. In this example we’ve got a role named “System Administrator”, to which the user “Administrator” has been added.
Add a new permission
In order to add a new permission, one or multiple user(group)s should be selected in the select users or user groups box. After this, the role (a selection of rights) must be selected in the select role box. After this, press Add to include the new permission in the overview. Functionally, this now means that every user you’ve selected in this step inherits all the rights on the selected role. Because we’ve configured these permissions in the User Management screen, the permission here are global, and not context specific. The later will be elaborated on in the local permissions chapter further on in this document.
Revoking existing permissions
In order to remove an existing permission, navigate to your chosen permission in the interface, and press the Revoke button. This will remove the permission, but not the underlying user(group)s or roles.
LDAP
LDAP configuration is handled in a separate chapter of the documentation to offer an extensive amount of information without distracting from the focus on permissions. LDAP users can be imported and used the same way as regular users.
Local permissions
The permissions we’ve configured in the global permissions chapter apply themselves to all existing instances of a certain context of functionality. For instance, if in the user management menu a role has been configured to be able to view groups and environments, and a permission has been created that includes user A, user A is able to view every single group and environment in the Runtime installation. This can have undesirable results. Earlier, we’ve taken a look at two different ways of configuring user groups. One example given was a role based approach where groups are created based on corporate roles and their absolute requirements. This approach divides users into “managers”, “testers”, etc. For this, it’s relatively simple to use only global permissions. After all, a data officer permission should probably be able to view the artifacts and run history, regardless of which group or environment this belong to.
For some permissions it can be desirable to split these permissions down into segments. If user A is a tester and is only involved with project A, it’s possible to only give rights to this user(group) to Group/Environment/Workflow A. This approach can also be desirable for configurations where it’s desirable for all involved users to have rights on a given context, but to prevent those users from accessing components belong to other teams/projects. We’ll go through every level upon which you can configure local permissions in the following chapter.
Group Permissions
In order to navigate to the group permissions, open the Groups menu and select Options → Edit in the top-right hand side of the page. Here, you can click on Permissions to unfold an identical menu as the one handled in the Permissions chapter. When creating a role to combine to a user(group) in this menu, it’s important to realize that many of the permissions are not used if we’re creating a local permission. After all, it makes little sense to give rights to a user to manage agents on a specific existing group, as these two menus are separated from one another. Below is a short collection of the permissions that impact groups and environments contained therein.
Local permissions can affect permissions downstream! This means that if you configure group permissions, you can also specify underlying environment permissions. This prevents you from having to specify permissions for every environment in a group if you want users who can access a specific group to be able to access every single environment therein.
Group permissions | |
View group | Grants the right to view all existing groups in the Groups menu. |
Rename group | Grants the right to rename this group. |
Delete group | Grants the right to delete this group. |
Manage group permissions | Grants the right to add permissions to this group. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning certain users or user groups a role on a group. |
Add environment | Grants the ability to add a new environment to this group through the Add environment button. |
Environment permissions | |
View environment | Grants the ability to view all environments in this group. |
Rename environment | Grants the ability to rename all existing environments in this group. |
Delete environment | Grants the ability to delete all existing environments in this group. |
Manage target connection | Grants the ability to reconfigure the connection data used of any environment in this group. |
Manage environment permissions | Grants the right to add or remove permissions to any existing environment in this group. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning existing users or user groups a role on an environment. |
Clean run history | Grants access to the Cleanup history… button in the Run history tab of any environment in this group. |
Manage environment parameters | Grants access to the Settings tab of any environment in this group. |
Manage installations | Grants the ability to install/upgrade or uninstall uploaded applications of any environment in this group. |
Manage triggers | Grants full access to the Triggers tab of any environment in this group. |
View run history | Grants the ability to view the Run History tab of any environment in this group. This also allows the role to view and download any artifacts created through the execution of runs on the environment. |
Manage active run | Grants the ability to view active runs of any environment in this group. This includes being able to see the logging and artifacts of a run. |
Start a new run | Grants the ability to start a new run through the Start… button on the Installed applications tab of any environment in this group |
Environment permissions
In order to navigate to the environment permissions, open the Groups menu, select the environment you’d like to modify and select Options → Edit in the top-right hand side of the page. Here, you can click on Permissions to unfold an identical menu as the one handled in the Permissions chapter. Below is a short collection of the permissions that impact environments when configured locally.
Environment permissions | |
View environment | Grants the ability to view this environment. |
Rename environment | Grants the ability to rename this environment. |
Delete environment | Grants the ability to delete this environment. |
Manage target connection | Grants the ability to reconfigure the connection data used for this environment. |
Manage environment permissions | Grants the right to add or remove permissions in this environment. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning certain users or user groups a role on an environment. |
Clean run history | Grants access to the Cleanup history… button in the Run history tab of any environment the role can view. |
Manage environment parameters | Grants access to the Settings tab of this environment. |
Manage installations | Grants the ability to install/upgrade or uninstall uploaded applications on this environment. |
Manage triggers | Grants full access to the Triggers tab on this environment. |
View run history | Grants the ability to view the Run History tab on this environment. This also allows the role to view and download any artifacts created through the execution of runs on the environment. |
Manage active run | Grants the ability to view active runs of this environment. This includes being able to see the logging and artifacts of a run. |
Start a new run | Grants the ability to start a new run through the Start… button on the Installed applications tab on this environment. |
Workflow permissions
In order to navigate to the workflow permissions, open the Workflows menu, select the workflow you’d like to modify and select Options → Edit on the right-hand side of the line. Here, you can click on Permissions to unfold an identical menu as the one handled in the Permissions chapter. Below is a short collection of the permissions that impact workflows in a local context.
Workflow permissions | |
View workflow | Grants the ability to view this workflow. This does not convey the right to view the edit view of a workflow, and thus the information within workflow components cannot be viewed with just this permission. |
Delete workflow | Grants the ability to delete this workflow. |
Execute workflow | Grants the ability to start the execution of this workflow through the Execute button. |
Edit workflow | Grants the ability to edit this workflow, changing its configuration. |
Manage workflow permissions | Grants the right to add permissions to this workflow, provided the role has access to the workflow menu. This does not convey the right to create new roles or users, and in isolation would limit the user to assigning certain users or user groups a role on a workflow. |
View history | Grants the ability to view the history of this workflow through the History letterbox. |
Clean history | Grants the ability to clear workflow history for this workflow. Functionally, this grants access to the Clear history button under the History button. If the View history permission is not granted, this role does not function. |
Combining local & global permissions
It’s possible to assign both local and global permissions to a specific user(group). In this case, it’s important to understand which permissions take precedent in the event of a clash. Let’s look at this through a short example. If you’ve configured a global permission that contains the right to view and rename existing groups and added it to user “Joseph“, that user is in general able to see every single group. It is possible to grant additional local permissions on a group to this user. However, you cannot write exceptions to global permissions using local permissions. In this example you would be able to grant Joseph the right to manage group permissions on specific groups by creating a new permission locally. It’s not possible to take away the right to rename a group through local permissions.
Local permissions can be used to grant extra rights to a user when combined with global permissions. It cannot be used to create exceptions on global permissions.
Another way of combining local and global permissions would be to grant local permissions on certain groups or environments, and then global permissions on everything below that tier. In this example you might give Joseph the global right to edit, rename, and create environments, as well as start runs etc. This does not convey the right to view groups. Because the user does not have a logical path to the environments (You must go through the groups menu to see environment), functionally he has no rights. Then, locally, you can give user Joseph the right to view a specific group. This would then also allow Joseph to manipulate the environments within that group, but Joseph is still unable to view the other groups, functionally limiting his rights.