Role-Based Access Control (RBAC)

Overview

Role-Based Access Control (RBAC) provides fine-grained access management for Login Enterprise, enabling administrators to define and manage custom roles with specific permissions. This functionality allows users to have isolated access to Test configurations, ensuring they can interact only with their designated Tests.

Before RBAC, Login Enterprise supported essentially a single permission level, limiting its usability in environments with multiple users or teams with diverse responsibilities. All users who logged into the system shared the same permissions, creating security and operational challenges. RBAC addresses this limitation by allowing custom roles with specific permissions, enabling segregated access to Test configurations, and enhancing security and usability for larger organizations.

In this initial version, RBAC applies permissions at the Test configuration level, with permissions inherited by associated Test Runs.

The RBAC functionality is currently limited to LDAP (Active Directory) for authentication and requires LDAP users and groups for access management. Without LDAP integration, RBAC cannot function.

Migration of Existing LDAP Groups

With RBAC, a migration process automatically creates roles and user groups corresponding to two LDAP groups (Admin and Read-only), provided you have previously set them up.

Migrated Roles:

• Admin: All permissions are enabled.

• Read-only: Only read permissions are enabled, allowing access to view Test Results, Applications, Session Metrics, and Test Configurations.

LDAP Group Mapping:

• Admin: Display name = Admin, Group name = [configured group name]

• Read-only: Display name = Read-only, Group name = [configured group name]

This migration ensures that users assigned to the Admin or Read-Only LDAP groups can still log in after the upgrade. However, note that these migrated roles are not automatically assigned to Tests. As a result, users may not be able to see any Test data unless the appropriate roles are assigned to the Tests.

To resolve this, Login Enterprise provides API endpoints that allow administrators to bulk update Tests and Test Runs to assign or replace the roles. For details, see Endpoints for Access Management.

You can also assign roles to a Test individually through the Login Enterprise UI in the Test Configuration.

Why Use RBAC?

Role-Based Access Control (RBAC) offers several key benefits that help organizations manage access more securely and efficiently. With RBAC, you can:

• Enable granular access control over Test configurations by defining custom roles and permissions. For details, see Managing Roles and Permissions.

• Increase customer satisfaction by offering a flexible and secure access management solution.

• Enhance security by allowing administrators to assign read, execute, and read-write permissions to roles.

• Support organizational needs with LDAP-based authentication.

• Ensure system stability and scalability while implementing the new role-based access model.

Key Functionalities

• Custom Roles: Users with Access Control Read+Write permission can create custom roles with specific permissions.

• Permissions Management: Assign permissions to roles at the Test configuration level.

• Permission Types: Support for read, execute, and read-write permissions with an additive model (e.g., execute on a Test).

• LDAP Integration: Add LDAP users and groups to roles for authentication purposes.

• Access Control UI: A new 'Access Control' UI allows you to manage roles and permissions.

• Fallback: A superuser retains full control over the system.

General Rules

• LDAP Requirement: RBAC can only be used in combination with LDAP.

  • LDAP Group: When using the LDAP group type, login credentials are verified against LDAP. The system checks if the user exists in the specified LDAP group as configured in Login Enterprise.

  • LDAP User: When using the LDAP user type, login credentials are verified against LDAP. If the user exists, access is granted. Note: Only the User Principal Name (UPN) format is supported for this user type; other variants, such as SAM account names, are not supported.

• Appliance Admin user: The original superuser account created during Appliance setup. It exists outside of LDAP and the Access Control UI. It has unrestricted access to all Tests and system areas by default.

• Built-In Admin role: A system-defined role introduced in v6.1. It always has full access to all Tests and Test Runs, even though it does not appear in the Access Control tab. The role cannot be deleted, renamed, or modified, and only user or group membership can be changed. See Built-In Admin for more details.

• Role Assignments to Tests: Roles can be assigned to Tests, and the permissions of the assigned role define what the user can do with the Test. For example, if role 1 has access to Test 1 with "read-only" results permission, the user can view Test results but cannot modify the Test configuration.

• If a user has access to the Test results, they can see all Applications referenced in those results, including those they don’t have access to.

• Role Assignments to Applications: Roles can also be assigned to individual Applications and Application Groups. Users can only access and configure Applications and Application Groups that are explicitly assigned to their role.

• Test Results Access: Test results are tied to the roles assigned to the Test. Users can view all results for a Test they have access to, but permissions cannot be set on specific Test Runs.

• Combined Role Permissions: When multiple roles are assigned to a user, the user will inherit the combined permissions of all assigned roles.

• UI Permissions: The UI will only display menu items and options for which the user has permission.

• Permissions for Creating/Updating Tests: To create or update Tests, a user must have read permissions for both Launchers and Accounts. Also, to add Workloads or Session Metrics, the user must have read permissions for Applications and user Session Metrics.

• Deleting Users: When a user is removed, they are only removed from Login Enterprise, not from the LDAP.

• Deleting Roles: Deleting a role will also remove the role from all the Tests it's assigned to.

Built-In Admin

The Built-In Admin role is a special, non-editable role introduced in version 6.1 to ensure consistent administrative access across Login Enterprise. This role is distinct from both custom roles and the original built-in admin user account (now referred to as the Appliance Admin User).

This section describes the Built-In Admin role, not the Appliance Admin user. The Appliance Admin user is the internal superuser account created during appliance setup and is not managed via the Access Control UI.

Role Characteristics

• Automatically granted full permissions to all Tests and Test Runs.

• Cannot be deleted, renamed, or have its permissions modified.

• The only allowed action is adding or removing users or LDAP groups assigned to the role.

• Does not appear in the Access Control tab of individual Tests, as it is not technically assigned to them.

• Cannot be manually removed from any Test or Test Run.

Role Behavior

• On Test creation, the Built-In Admin role is automatically granted access, even though it is not visible in the UI.

• On upgrade to version 6.2, the Built-In Admin role is automatically created and granted implicit access to all existing Tests and Test Runs.

  • The Built-in Admin role will also automatically get access to all Applications and Application Groups.

  • Existing roles will automatically get all Applications and Application Groups assigned to them.

This behavior is enforced by the system and does not rely on Test-level role assignments. The access logic recognizes the Built-In Admin role at runtime.

Migration and Compatibility

• In version 6.0, LDAP-enabled appliances automatically generated an admin role. This role was editable, deletable, and not automatically assigned to Tests.

• When upgrading from 6.0 to 6.1 or higher, the system:

  • Preserves the existing admin role.

  • Adds the new Built-In Admin role, which may result in both roles appearing in your environment.

• When upgrading from 5.14 or earlier to 6.1:

  • Only the Built-In Admin role is created.

  • The previously configured admin LDAP group is assigned to the Built-In Admin role.

Configuring RBAC

1. Access Control Page
   Navigate to the Access Control page to start managing roles and permissions for users and Tests.

2. Add New User
   To add a new user, click the green + icon (Add User/Group) and select LDAP User.

The list of permissions for both the user and user group cannot be adjusted during the user creation or editing steps. The permissions displayed are based on the roles linked to the to-be-created user. To change permissions, you need to modify the role, not the user.

3. Add New User (Group)
   This allows you to define group-based roles and assign permissions accordingly.

To create a new group of users, click the green + icon (Add User/Group) and select LDAP Group.

4. Create New Role (Including Permissions)
   To create a new role, select Roles from the tab bar menu and click the green + icon (Add Role).

5. Assign permissions based on the access level you want the role to have.

6. View User Profile
   To view the profile of any user, click the User Profile icon on the top right. Here, you can see the assigned roles and permissions for each user.

7. User with Limited Permissions
   Here’s an example of a user with limited permissions, demonstrating how restricted access looks when configured.

You can update Tests with roles in bulk using the Public API.

Assigning or Removing Test Access from a Role

You can assign or remove access to multiple Tests directly from a Role configuration. This allows you to manage Test access at scale without relying on the API or editing each Test individually.

The Tests tab in the role details view includes:

• A searchable, sortable table of Tests assigned to the role.

• Options to add or remove one or more Tests.

• Optional filters to narrow the list by Test type.

Only Tests that the current user has permission to access are displayed. Tests that are assigned to the role but not visible to the current user will not appear in the list.

Assigning Test Access

To assign Tests to a role:

1. Open the Test Access tab in the role’s details view.

2. Click Add Tests.

3. Use the search or filters to find the Tests you want to assign.

4. Select one or more Tests and confirm.

5. The newly added Tests will appear at the top of the list, highlighted with a green line.

6. Click Save to apply the changes. The green lines will disappear once the changes are saved.

You can also assign Role(s) to Test (Access) from the Test Configuration. This allows you to assign roles to determine which users can access and modify Tests. To do this:

a. Go to Configuration > Manage Tests.

b. Select your preferred Test, e.g., Load Test, and select Access from the tab bar menu.

Assigning Tests to a Role in Bulk Using the Script

After upgrading to Login Enterprise 6.0, none of your Tests will have a role automatically assigned. This means that only the built-in "admin" account can manage them. You can individually add a role to your existing Tests, but if you have a large number of Tests, this can be inconvenient and time-consuming.

Use the PowerShell script to find all unassigned Tests and assign them to a role of your choosing.

For instance, Login Enterprise will automatically create a role called "Admin" and assign it to your LDAP Administrators group during the upgrade. You can simply assign that role to your Tests.

When you run the script, it will put up a dialog window asking for:

• The Appliance FQDN (the host/domain name, not the web URL).

• A Configuration-level API key.

• The Role you want to assign to your unassigned Tests.

Creating an API key

1. In the Login Enterprise sidebar menu, navigate to Access Control > Public API.

2. Create a new Public API key by clicking Add new system access token.

3. Give it a name, and in Access Level, select Configuration.

4. Click Save.

After you specify the Appliance FQDN and the API Key in the previous step, click Retrieve List. This populates the Specify Role pulldown. It likely only contains one entry, "Admin," which is the role we created during the upgrade. Then, click Assign Role. This will update all of your unassigned Tests to use the specified role.

If you select the "Built-in Admin" role, which is automatically created in Login Enterprise 6.1 and later, assigning it to your Tests will have no effect. Built-in Admin already has implicit access to all system objects. Please select another role.

Removing Test Access

To remove Test access from a role:

1. Open the Test Access tab in the role’s details view.

2. Use the filters or search to locate the Tests you want to remove.

3. Select one or more Tests.

4. Click Remove.

5. The removed Tests will remain in the list but appear greyed out, indicating they are marked for removal.

6. Click Save to apply the changes. The greyed-out rows will disappear once the changes are saved.

Managing Access to Applications and Application Groups

You can control which users can view or manage specific Applications and Application Groups by assigning access roles. This helps ensure that only authorized users, the “owners” of the Application, can manage its settings or include it in Tests.

Assigning Roles to Applications and Groups

You can assign one or more roles to an Application or Application Group to control who can view or manage them. You can only assign roles that you have permission to access.

When creating:

• Application: Use the Assign Roles option to define who can access the Application.

• Application Group: Use the Assign Roles option to grant access during Group creation.

When editing:

• Modify assigned roles directly in the Application or Application Group configuration.

• You can add or remove roles at any time.

Managing Application Access from the Roles UI

When viewing a role, you can manage associated Applications and Groups:

• See a list of Applications and Groups assigned to the role.

• Add one or more Applications or Groups to the role.

• Remove Applications or Groups from the role.

Deleting Roles

When a role is deleted, it is automatically removed from all Applications and Application Groups it was assigned to.

Test Visibility and Behavior with Restricted Apps

• Users can see all Test results, even if the Test includes Applications they don’t have access to.

• The Test configuration page displays all Applications assigned to a Test, including those without user access.

• Users cannot add Applications they don’t have access to into a Test.

• If a Test already contains Applications without user access, users can perform actions such as:

  • Removing those Applications from the Test

  • Changing their settings

  • Reordering them within the Test

• Once a no-access Application is removed from a Test, users cannot add it back because it will not appear in the Add Application list.

Application Group Behavior

• Application Groups will display all included Applications, even if the user doesn’t have access to some of them.

• Users cannot add Applications they don’t have access to into a Group.

• If a Group already contains no-access Applications, users can remove, reorder, or change settings for those Applications.

• Users can add new Applications to the Group only if they have access to those Applications.

Public API Support

You can perform bulk role assignments via the Public API, specifically:

• Retrieve Applications not assigned to any role.

• Assign one or more roles to one or more Applications in a single request.

For details, see Endpoints for Access Management.

Managing Roles and Permissions

Understanding Permission Dependencies

To manage and assign Launchers, Accounts, Applications, and Environments, users must have specific permissions. The following outlines the required permissions for each:

• To view and assign Launchers to Tests (Config), the user must have read permissions for Launchers.

• To view and assign Accounts to Tests (Config), the user must have read permissions for Accounts.

• To view and assign Applications to Tests (Config), the user must have read permissions for Applications.

• To view and assign Session Metrics to Tests (Config), the user must have read permissions for Session Metrics.

• To view and assign Environments to Tests (Config), the user must have read permissions for Default (to get permissions to Environments).

• To view and assign Tests to Environments, the user must have read permissions for Default (to get permissions to Environments) and read permissions for Test Configuration.

• To access the Downloads tab for Launchers, Accounts, and Applications, the user must have read permissions for System > Components > Downloads.

• To view Session Metrics in Continuous Test results, the user must have read permissions for Session Metrics.

• To view the threshold line in the charts of Continuous Test results, the user must have read permissions for Test Configuration.

Other Permission Details

• The About and Licensing pages are visible to all users, regardless of their permissions. However, to perform actions on these pages, users must have System Config permissions (read/write).

• To view the Operations Dashboard, the user must have permissions for Environments, which are included under the Default permission.

Endpoints for Access Management

You can manage access to Tests, Test Runs, Applications, and Application Groups directly through the Virtual Appliance web interface. This is the recommended method for most scenarios.

If needed, you can also perform access management tasks programmatically by using the Public API.

Managing Access to Test Runs for Deleted Tests

The API includes endpoints for managing access to Test Runs when the parent Test has been deleted. You cannot assign roles to Test Runs through the UI. Use the API if you need to make the results of deleted Test Runs visible to specific roles.