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.

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. Currently, there are no security rules in place that a new password must conform to. 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.

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.

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.

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:

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.

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:

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.

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.

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.

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.