Role-Based Access Control (RBAC)

Overview

Migration of Existing LDAP Groups

Why Use RBAC?

Key Functionalities

General Rules

Built-In Admin

Configuring RBAC

Assigning Test Access from a Role

Managing Roles and Permissions

Understanding Permission Dependencies

API Endpoints for Managing Roles to Tests and Test Runs

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 API Endpoints for Managing Roles to Tests and Test Runs.

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.
• 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.

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.1, the Built-In Admin role is automatically created and granted implicit access to all existing Tests and Test Runs.

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, 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 to start managing roles and permissions for users and Tests.

2. Add 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.

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.

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

To update Tests with roles in bulk, use the Public API. For more information, see Endpoints for Managing Roles to Tests and Test Runs.

For more details on using and accessing the Public API, see Using the Public API.

Assigning 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.

You can only add Tests to a role from this view. To remove a role from a Test, go to the specific Test and modify its access settings there.

⚠️ 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.

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:

1. Go to Configuration > Manage Tests.
2. Select your preferred Test, e.g., Load Test, and select Access from the tab bar menu.

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 Config.
• 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 Config.

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.

API Endpoints for Managing Roles to Tests and Test Runs

API Endpoints for Tests

The following endpoints manage role-based access for Tests. If a Test exists, updating the Test will automatically display the associated Test Runs for the assigned roles.

In the Login Enterprise UI, roles can only be assigned to individual Tests one at a time. When you assign roles to a Test, the results will be visible to users with those roles. You cannot perform bulk role assignments in the Login Enterprise UI. However, you can use these API endpoints to assign roles to multiple Tests at once.

API Endpoints for Test Runs

The following endpoints manage role-based access for Test Runs. You can use them if the Test has been deleted, but the Test Runs are still present.

⚠️ You cannot assign roles to Test Runs through the Login Enterprise web interface. This limitation can be necessary when a Test is deleted, but the Test Runs are still present. However, you can use these API endpoints to make the results of a deleted Test Run visible to specific roles.