Custom User Roles

1. Overview

Access to Data, Data Management Artifacts, and Actions is governed by User Groups, Dashboard Groups, and User Roles. A User Group defines detailed data access by assigning a set of Data Access Policies, Tags, Organizations, and a User Role to the group. A Dashboard Group provides access to Dashboards by assigning a collection of Dashboards to a User Group. A User Role defines the permissions for actions within Dashboards. Custom User Roles and Permissions are further explained in the following sections of this document.

RDAF includes a set of predefined System User Roles, each assigned based on the user's access level. For more granular control, admins can create Custom User Roles with specific permissions. When a user with a custom role logs in, their access and actions within the system are governed by the assigned permissions, ensuring precise control over artifact management.

The details of Permissions, Permission Groups, and Custom Roles are further explained in the corresponding sections.

2. Permissions

Permissions are granted for specific actions, which are tied to Dashboard Widgets. When a dashboard is launched, the actions available for each widget are filtered based on permission checks. For every action, a permission check is performed to verify if the logged-in user's User Role includes the required permission. If the user's role has the necessary permission, the corresponding action is allowed.

Sample Permission of an Action

{
   "permission":"rda:organization:add",
   "title":"Add",
   "type":"POPUP_FORM",
   "selectionType":"NONE",
   "identifier":"saas-service-action:rda.saas.organization.add",
   "api-endpoint":{
      "service-name":"saas-reports",
      "methodName":"getForm",
      "stringified-params":true,
      "parse-output":false,
      "params":[
         {
            "formId":"rda.saas.organization.add"
         }
      ]
   }
}

A permission is represented as a string with the following format:

<Domain>:<Component>:<Privilege>  Ex. rda:dataset:add

Understanding Domains and Components in Permissions: A Domain can be one of the following: rda/aia, oia, ml, or custom. It serves as a category for Components, which represent artifacts, logical constructs, and concepts within a specific domain. For instance, components such as dataset, pipeline, pstream, usergroup, project, and credential belong to the rda domain. The combination of Domain and Component provides an organized structure, enhancing both the manageability and understanding of permissions.

Using Wildcards in Permissions: A permission can include the wildcard * for either a component or a privilege. If the component is *, the specified privilege is granted for all components within that domain. Similarly, if the privilege is *, all privileges are granted for the specified component.

Examples:

• rda:*:view – This grants the view privilege for all components within the rda domain. A user with this permission will be able to perform actions such as rda:dataset:view, rda:pstream:view, rda:credential:view, and similar actions across all rda components.

• rda:userprofile:* – This grants all privileges for the rda component userprofile. A user with this permission will be authorized to view, edit, delete, and perform other actions on the user profile. This includes actions like rda:userprofile:view, rda:userprofile:edit, rda:userprofile:delete, and rda:userprofile:export.

2.1 System Permissions

RDAF bundles a set of system-defined permissions for each domain: rda/aia, oia, and ml. These permissions are displayed in popup reports named RDA Permissions, OIA Permissions, and ML Permissions, respectively.

2.2 Custom Permissions

User-defined permissions utilize the custom domain. The components and privileges within Custom Permissions are entirely determined by the end users, with no restrictions or guidelines on what can be used. However, it is recommended that the privileges clearly reflect the specific action associated with the permission.

To create Custom Permissions, use the Add Permissions action in the Custom Permissions report. Start by launching the Administration app, then navigate to the Permissions tab on the Users page (Administration → Users → Permissions).

In the Add Permissions popup, enter one permission per line. Custom Permissions follow the format custom:<component>:<privilege>, with the custom domain automatically applied. Simply input the permissions in the format <component>:<privilege>, one per line. The wildcard ‘*’ can be used for a component, meaning the specified privilege applies to all custom components. For example, entering *:view will result in the custom permission custom:*:view, which grants the view privilege for all custom components.

These custom permissions should be added to a Custom Permission Group, which can then be assigned to a Custom User Role. To allow certain actions for a user with this custom role, the relevant custom permissions from the assigned permission group must be included in the dashboard widget action definitions.

3. Permission Groups

A Permission Group is a collection of permissions from a specific domain. For instance, the RDA Permission Group consists of permissions from the ‘rda’ domain. There are three types of permission groups:

1) System Permission Group – A pre-defined, system-generated group that contains system defined permissions.

2) Domain Custom Permission Group – A user-defined permission group that allows the selection of system-defined permissions from a specific domain.

3) Custom Permission Group – A user-defined permission group containing custom permissions, associated with the User/Custom domain.

3.1 System Permission Groups

RDAF incorporates a collection of system-defined permission groups tailored for each of the core domains: RDA/AIA, OIA, and ML. These groups are pre-configured bundles of permissions designed to streamline access control and ensure consistency across the platform.

• RDA Permission Group - system-defined permissions from the RDA domain.

• OIA Permission Group - system-defined permissions from the OIA domain.

• ML Permission Group - system-defined permissions from the ML domain.

• Custom Permission Group - user-defined permissions from the User/Custom domain.

What is a System RDA Permission Group?

A System RDA Permission Group is a predefined set of permissions within the RDA domain. These groups are created and managed by the system, ensuring a standardized approach to access management. Similar groups exist for the OIA and ML domains, each with their own system-defined permissions.

Accessing System Permission Groups

User can view the complete list of System RDA Permission Groups, OIA Permission Groups, and ML Permission Groups in the corresponding reports under the Permission Groups tab. Navigate to: Administration → Users → Permission Groups.

Key Features of System Permission Groups

Read-Only: System Permission Groups are immutable. They cannot be edited or deleted, ensuring the integrity of predefined permissions to user roles.

Cloning and Customization: While these groups cannot be modified directly, they can be cloned and customized to create Domain Custom Permission Groups. This allows organizations to tailor permissions to their specific needs while maintaining a foundation of system-defined standards.

3.2 Domain Custom Permission Groups

Domain Custom Permission Groups are user-defined groups that allows user to tailor permissions to their specific needs. These groups are created by selecting system-defined permissions from a particular domain. For example, an RDA Custom Permission Group is formed by choosing system-defined RDA permissions.

User can create these custom groups in two ways:

• Using the ‘Add Permission Group’ action within the report.

• By cloning and customizing an existing system-defined permission group.

When creating a custom group, the ‘Select Permissions’ dialog will open, displaying a multi-selector table of all system-defined permissions for the corresponding domain. For instance, when creating a Custom RDA Permission Group, the ‘RDA Permissions’ table will be launched. Unlike system-defined groups, Domain Custom Permission Groups offer full flexibility. They can be: Cloned, Edited, Deleted

To define the appropriate permissions for a Domain Custom Permission Group, follow these steps:

• Identify the dashboards that will be assigned to the Custom Role User.

• Determine the actions within those dashboards that need to be permitted.

• Map out the required permissions for those actions.

For assistance in identifying the necessary permissions, refer to the ‘Dashboard Action Permissions’ table. This comprehensive resource documents all known dashboard action permissions, including: Dashboard Name, Dashboard Section Title, Widget Title, Action Title. By leveraging this table, user can ensure that their Domain Custom Permission Groups are precisely aligned with their organizational requirements.

For Dashboard Action Permissions Table please click here

3.3 Custom Permission Group

Custom Permission Groups enable users to define and manage their own permission sets. These groups are displayed in the Custom Permission Groups report and can be created in two ways:

• Using the Add Permission Group action within the report.

• Cloning and customizing an existing Custom Permission Group.

The Select Permissions dialog provides an easy way to add or remove pre-defined custom permissions, ensuring flexibility and control over access settings.

Custom Permission Groups are assigned to the custom domain. Their Group IDs follow the format <domain>:<name>, specifically custom:<group name>. These groups can be Cloned, Edited, Deleted as needed, offering flexibility in managing permissions.

4. Customer User Roles

A Custom User Role is a user-defined role that is tailored with selected Permission Groups. Custom User Roles define the permissions granted to users by assigning specific permission groups. These roles can include a combination of System Permission Groups and Custom Permission Groups, with up to four groups assigned to each role. The structure allows for one group for each domain as shown below

• RDA Permission Group: Either a system-defined RDA group or a user-defined RDA Custom Permission Group.

• OIA Permission Group: Either a system-defined or custom OIA group.

• ML Permission Group: Either a system-defined or custom ML group.

• Custom Permission Group: user-defined permission group from the custom domain.

Each role also specifies the Organization Access level, determining whether a user can access data from a single organization or multiple organizations. Based on this, one or more organizations can be assigned to a User Group, ensuring users only access data from the designated organizations.

4.1 Management and Visibility

Custom User Roles, along with System User Roles, are displayed in the User Roles report Administration -> Users -> User Roles. System User Roles are read-only and cannot be Edited or Deleted. Custom User Roles can be Cloned, Edited, Deleted as needed.

Custom User Roles are created using the Add Role action in the User Roles report.

• The Add Role form includes four Selector Dialog fields, each launching a single-select tabular report, These reports display all System and Custom Permission Groups for the corresponding domain (e.g., the RDA Permission Group field shows the RDA Permission Groups table).

• Custom User Roles provide a flexible and precise way to manage user access, ensuring alignment with organizational needs and security requirements.

The View Permissions action for a user role displays all assigned permissions in a pop-up window, organized by their respective permission groups for easy review.

4.2 Onboarding User with Custom Role

These are the sequence of steps for Onboarding a User with a Custom Role:

• Create Custom Permissions (Optional Step)

• Create a Custom Permission Group by selecting user-defined Custom Permissions(optional step)

• Create Domain-Specific Custom Permission Groups (Optional)

  - RDA Custom Permission Group: User selected RDA permissions.

  - OIA Custom Permission Group: User selected OIA permissions.

  - ML Custom Permission Group: User selected ML permissions.

• Create a Custom User Role by assigning one to four permission groups, including:

  - RDA Permission Group: System-defined or user-defined RDA Custom Permission Group.

  - OIA Permission Group: System-defined or user-defined OIA Custom Permission Group.

  - ML Permission Group: System-defined or user-defined ML Custom Permission Group.

  - Custom Permission Group: User-defined group of custom permissions.

• Create a User Group with a Custom User Role assigned to it

• Create a User with the above User Group assigned to it.

• Create a Dashboard Group, Assign the User Group to the Dashboard Group and select the dashboards you want the user to access.

When a user with a custom role logs in, they will see only two menu options: Home and User Dashboards. Clicking User Dashboards opens the Dashboards page, which displays all dashboards directly assigned to the user’s User Group, and dashboards tagged with any of the tags associated with the user’s User Group. The user can launch any of these dashboards, where Data visibility is determined by the Data Access Policies and the Organizations linked to the User Group. Allowed actions are governed by the permissions defined in the User Role. This setup ensures a streamlined and secure user experience, tailored to their specific access and permissions.

Custom Role User

My Dashboards