Introduction to Express Role-Based Access Control (RBAC)

Overview

RBAC (role-based access control) is the most secure way to make sure that end-users End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. have the right permissions in your application. In Unqork, you'll have Creator Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform. users and Express users. Creator users can access and edit your application in the Designer view (also known as the Module Builder). Express users are the end-users accessing your application in Express View Express View is how your end-user views your application. Express View also lets you preview your applications to test your configuration and view the styling. This is also the view your end-users will see when interacting with your application. After configuring a module, click Preview in the Module Builder to interact with the module in Express View.. Most applications have many types of Express users. You might have customers, managers, administrators, and others visiting your application. In RBAC RBAC (Role-Based Access Control) is a method to control system access for authorized users. The role in RBAC refers to the levels of access employees have to a network. terms, we call these user types "roles." Users can have as many roles as is necessary.

What You'll Learn

In this article, you'll learn about the types of RBAC permissions and RBAC hierarchy,

RBAC Permission Types

You get to choose what access or abilities you want each user role to have. For example, giving a customer full or partial access. In RBAC, you have five permission types:

Access Level	Description
No Access	An end-user End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. cannot access your application, module, or component.
Read-Only	An end-user can view but cannot write or engage with your application, module, or component.
Write	An end-user has full access to write and engage with your application, module, or component.
Inherit	This permission is available at the module and component-level only. The module or component inherits permissions from their parent. For example, let's say a Text Field component lives inside a Panel component. The Text Field would inherit the permissions set up in that Panel component. The highest level component in a module would inherit permissions from the module. Modules would inherit permissions from the environment-level role defaults.
Obfuscate	This permission type is available at the component-level only. Information entered into a field with this permission gets replaced by asterisks in your submission data instead of what your end-user entered. Obfuscate is great for social security numbers or PII Personal Identifiable Information (PII) is any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. (personally identifiable information) you don't want certain end-users seeing.

RBAC Levels

There are different types or levels of RBAC. You can set up RBAC for your environment, workspace, modules, and even individual components.

Environment-Level RBAC

To manage environment-level permissions, Unqork classifies end-users by roles and groups. End-users are the ones using your application on the front-end in Express View. Let's examine how roles differ from groups, and how they work to secure your application.

• Groups: Determine what submissions team members see. When you set up your groups, you can decide whether the end-user can access only their data, a specific set of data, or all data.

• Roles: Set what your end-users can do. You can also use roles to regulate access to a module or component. For instance, end-users might have read-only access to modules or a module's components in a given role.

Full Submission Access

Environment-level RBAC includes Full Submission Access in addition to the Write, Read-Only, and No Access permissions. Full Submission Access overrides all other permission settings in the environment. User roles with Full Submission Access have Read and Write access to all submissions regardless of their role hierarchy, group membership, or component-level permissions.

To learn more about Environment-Level RBAC, see our Environment Level Role-Based Access Control (RBAC) article.

When creating and updating Unqork submissions as a non-Administrator Express role, saved Property IDs must be present as a component in the module or application where the submission is written. When writing to Unqork submission data, Super-Users (Administrators with Full Submission Access) behave differently than non-Administrators. The Super-User role superseding all RBAC controls for writing Property IDs to Unqork submissions. Therefore, Super-Users can write Property IDs to a module even if the Property ID doesn't exist on the module.

Module-Level RBAC

Module-level RBAC is unique because it lets you can overwrite a role's default permission for a module. Changes to permissions at the module-level do not impact other modules. So, ensure you customize each module as needed.

In Module Builder settings, you'll set Customize RBAC for the Module to  (ON). A grid displays displaying a list of all module permissions in your environment. By default, each role is set to Inherit. Inherit means that the role's access in this module is the same as at the environment-level. You can change this access to No Access, Read-Only, Write, or Inherit.

You can also set up access for anonymous (unauthenticated) end-users for your module.

It's best practice to enable and configure RBAC on every module. There are only two exceptions here. One is if the module is available anonymously. The other is if you're confident this module will remain accessible to all end-users.

To learn more about module-level RBAC, see our Module Permissions article.

Component-Level RBAC

You can also overwrite access for specific components in your modules. Let's say you want a role to have different access to a component than their default role allows. Setting RBAC for specific components is how you handle this level of access.

In Module Builder Settings, set the Customize RBAC for the Module toggle to (ON). Then, override default permissions for any role at the component-level. To access component-level RBAC, click the Permissions tab in any component's configuration window. Here you'll see a list of roles and the option to edit their permissions for that component. You can set the permission to No Access, Read-Only, Write, Inherit, or Obfuscate.

To learn more about component-level RBAC, see our Component Level Role-Based Access Control (RBAC) article.

RBAC Hierarchy

For Express View, RBAC hierarchy determines what RBAC permissions are active for an end-user. RBAC hierarchy is determined by specificity. The component-level RBAC overrides module-level RBAC, which overrides the environment-level RBAC.

The order of Express View RBAC Hierarchy is:

For example, userRole1 might only have Read access to a specific module. However, userRole1 also needs Write access to a specific component in that module. Changing userRole1's RBAC access to Write for the component overrides the module-level RBAC's Read permission. Because the change in permissions is set at the component-level, userRole1's Read access does not change for the rest of the module.