Roles

Roles refer to a collection of users who are granted specific permissions. It is to be noted that permissions are assigned to Roles and not to individual users.

On the Roles listing page, users with appropriate permissions can create, edit, delete, and modify the permissions of Roles.

💡Note:

1. The users with view-only permissions for the User Management module can only see the Roles listing and view the permissions assigned to them.
2. For environments with LDAP integrations, customers should create LDAP roles specific to vuSmartMaps, ideally prefixed with “Vunet-“. This ensures that only relevant roles are pulled during LDAP synchronization, minimizing unnecessary role imports.

Role Creation

To create a new Role, click on the + button on the Roles listing page.

This will open a modal where you can enter a Role Name and select a list of users that you want to add to this group.

Also, the user role-specific homepage can be set here under Select HomePage. A specific dashboard can be set as the default landing page for this particular user role for the web app as well as for the mobile app.

Additionally, you can set the Data Access Policy to provide granular data access controls for user roles. The details on the Data Access Policy are discussed here in detail. Alternatively, you can link users to Roles from the Edit Role section. Once you have entered all the required information, click on the Save button to create the new Role.

Assign Permissions to a Role

To assign permissions to a Role, select the Role to which you want to grant permissions and click on the Edit Role Permissions icon, as shown below: When you click on the Edit Role Permissions icon for a Role, a modal will appear displaying a list of modules and the permissions that can be assigned to each module.

After selecting the appropriate permissions, click on the Save button located at the bottom of the modal to save the configuration for the Role.

💡Note:

1. Please note that when you grant ‘write’ permission to a module for a Role, the corresponding ‘read’ permission is also implicitly granted for the same module.
2. Additionally, giving permission to one module may result in implicit permission being granted to another module. For example, granting ‘write’ permission to the Alert Rules module will also implicitly grant ‘Data Model’ read permission to that Role. The below snapshot shows one example, where the selection of Alert Write permissions, grants read permissions for that module automatically. And similarly also grants read permission for Data Model. Logging in with such a user will give access to that user with a read-only view of the Data Modelling workspace.

Managing Password Change Permissions

In vuSmartMaps, administrators now have the ability to control password change permissions for end users, ensuring tighter security measures and compliance within the platform. This user guide section outlines how to utilize this feature effectively.

Enabling Password Change Permissions:

1. Within the role settings, locate the ‘Miscellaneous’ permission category.
2. Enable the ‘changePassword’ rule under this category to allow password changes for users assigned to this role. Deselect the option to disable password change. It is to be noted that this option is enabled by default.
3. After configuring the permissions, save the role settings to apply the changes.
4. Users assigned to roles with the Change Password Permission will be able to update their password with the Change Password option.
5. Users assigned to roles with the Disabled Change Password permission will find the Change Password field disabled in their profile section upon login. Hovering over the disabled field will display a message informing the user that they do not have permission to change their password.

Updating Role’s Default Homepage and Users

In user management, you can set a specific homepage for each user role. This means that when a user with a specific role, logs in, they will be directed to a personalized dashboard that suits their role. You can choose a different dashboard for the web app and the mobile app if desired.

1. To update the default landing page, you can edit the role by clicking on the Edit button.
2. On clicking the Edit button, a pop-up will open, where you can modify the preference for the homepage for the web app and mobile app under Select HomePage. Similarly, Users can also be updated for the role from this pop-up on the Edit screen. Clicking Save will update the details for the specific role.

Roles Deletion

To delete specific Role(s), follow these steps in the User Management module:

1. Locate the Roles(s) you wish to delete and select the checkbox next to their names.
2. Click on the Delete Roles icon.
3. A pop-up window will appear, asking you to confirm the deletion of the selected user(s).
4. In the pop-up, type “Yes” in the provided text box to confirm the deletion. Click on the Delete Roles button.
5. The selected Roles will be deleted.
6. Similarly, to delete some particular user, the Delete Role Icon can be used across that particular user.

💡Note: Please note that any user with write permissions to the User Management module has the ability to delete any Role.

User-Specific Views

User-Specific Views in vuSmartMaps ensure that users accessing the same dashboards can view data according to the policies configured for their respective roles. User-specific views are designed to provide a personalized and secure data experience tailored to individual roles within your organization. User-specific views will be applied based on the Role for Data store access control field set for the user.

User-specific views address the need for common dashboards to offer customized data displays based on user roles and their associated policies. By configuring data access policies for user roles, you can control and restrict the data visible to users, ensuring they only see information relevant to their roles and responsibilities.

Tenant-Specific Data Isolation

To enhance data security, users from different tenants are isolated from each other. They cannot see each other’s data, except for super tenants who have broader visibility. This ensures that data remains confidential and exclusive to the respective tenants.

Data Access Policies

To achieve this, User-Specific Views operate on two main data access policies:

Data Set Policy

There are four options under Data Set Policy, allowing administrators to finely control data access:

1. Deny Access to All Observability Data
2. Allow Access to All Observability Data
   • Users can access the entire observability data set.
3. Allow Access to Specific Data Sets
   • Users can select one or more data categories for access.
4. Deny Access to Specific Data Sets
   • Users can restrict access to specific data categories.

Data Set Categories User-Specific Views support seven distinct data set categories, enabling users to choose and configure their preferred data sets:

1. Traces
2. RUM
3. Logs
4. Metrics
5. Events
6. Transactions
7. Custom

💡Note: It is to be noted that the policies will apply to tables with specific prefixes as outlined below:

Category	Table Name Prefix
Traces	vtraces
RUM	vrum
Logs	vlogs
Metrics	vmetrics
Events	vevents
Transactions	vtrans

Record Level Policies

In addition to Data Set Policies, administrators can define access permissions at the record level through record-level policies. This feature allows for more granular control, permitting administrators to set specific access rules based on column values for tables within a data category.

Now, let’s delve into the detailed configuration and usage of User-Specific Views to optimize your dashboard experience based on roles and policies.

Selecting Data Set Policy

While creating a new role, you need to select Data Set Policy from the following 4 options:

1. Deny access to all Observability data
2. Allow access to all Observability data
3. Allow access to specific Data Sets
4. Deny access to specific Data Sets

Deny access to all Observability data

Administrators possess the capability to impose access restrictions on entire observability datasets for specific roles, significantly enhancing data security. This measure explicitly denies access to observability data for roles where heightened security is a priority. Example: Consider a scenario where a user is assigned a role configured with the “Deny Access to all Observability Data” policy in the Data Access settings. In this case, the user mapped to this role will be unable to access any observability data. The resulting dashboard will display no data, showing the restricted access enforced by the specified data policy.

Allow access to all Observability data

Administrators possess the authority to grant access to the entire observability dataset for specific roles, providing meticulous control over data permissions. This facilitates precise management of observability data access in alignment with distinct roles and responsibilities, allowing seamless data access with a single click.

Example:

Consider a scenario where a user is assigned a role configured with the “Allow Access to all Observability Data” policy in the Data Access settings.

In this case, the user mapped to this role will have unrestricted access to all observability data. The resulting dashboard will display the complete dataset, showcasing the comprehensive access granted to the user based on the specified data policy.

Allow access to specific Data Sets

With the “Allow access” policy, users can meticulously choose data categories and grant access to specific datasets, fostering a streamlined approach to viewing tailored data while adhering to organizational data compliance.

Users have the flexibility to select desired datasets within predefined categories such as Traces, RUM, Logs, Metrics, Events, and Transactions, or even opt for a custom dataset.

In the case of a “Custom” category selection, users can create a custom category with a designated name and choose specific tables for access.

Example:

Imagine a user assigned a role configured with the “Allow access to specific Data Sets” policy,  within the  “custom” data category, allowing access to the particular log table.

In this scenario, when the user accesses the Log Analytics module, the system will list only the log tables the user can view. While other log tables outside the user’s access scope will be excluded. This ensures secure and compliant access, allowing the user to view only the relevant log data as per the configured policy.

Deny access to specific Data Sets

By adopting the “Deny access” policy, users can define access restrictions, enhancing security measures through a user-friendly interface within vuSmartMaps.

Upon selecting the policy, users are empowered to choose one or more data categories for denial, ensuring a tailored approach to access control. For instance, an administrator aiming to limit data access for a specific role in the APM data category can seamlessly select the APM category under the “Deny Access to specific data category” policy.

In cases where a “Custom” category is chosen, users are provided the flexibility to create a custom category with a designated name and specify tables to be denied access. vuSmartMaps diligently enforces these access restrictions, actively preventing users associated with the configured role from accessing the restricted datasets.

Example:

Consider a role configured with the “Deny access to specific Data Sets” policy, denying access to data categories such as transactions, traces, rum, events, and custom.

For a user linked to this role, the dashboard will display visible data only for permitted datasets, exemplifying the effective implementation of access restrictions based on the configured policy.

Adding Record Level Policies

In vuSmartMaps, administrators can establish access controls at the granular level of individual records within a specific data category. This level of precision empowers administrators to define access policies tailored to their organization’s requirements.

Administrators can initiate the creation of a new access policy by clicking on the + Add Policy button, and selecting the option that leads to policy definition.

1. Users are prompted to choose the relevant “Data Category” for which the access policy will be formulated.
2. Upon selecting the data category, the system automates the population of the “Name” and “Tables” fields, streamlining the configuration process.  In cases where “Custom” is selected as the data category, users have the flexibility to manually enter the “Name” and “Table Name.”
3. Users are then guided to input the specific “Column Name” for which the access policy will be applied.
4. Users are presented with the option to specify whether the policy is intended to “Allow” or “Restrict” access.
5. To enact the policy, users input desired column values within single quotes, separating each value by a comma (e.g., ‘John, Smith’, ‘Ram’).
6. For further refinement, the system allows users to choose “Yes” or “No” for “Must Match” when applying a “Restrict access policy”. When the “Restrict access policy” is applied to a column, users with corresponding roles should be denied access to records that meet the specified criteria in the designated column within the defined “Data Category”.

Example:

Consider a scenario where the role denies access to the “rum” data category. Record level policies are then configured to allow access for “span id 112” in “rum,” restrict access for “appname UPI” in “transactions,” and allow access for “span attribute location chennai” in “traces”.

For the user associated with this role, the resulting dashboard reflects visible and hidden data as per the defined dataset and record-level policies.