Introduction to Express Role-Based Access Control (RBAC)
Estimated Reading Time: 5 minutes
RBAC (role-based access control) is the most secure way to make sure that end-users End-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; 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 Editor). Express users are the end-users accessing your application in Express View Express View is how your end-user views you application. Express View also lets you preview your applications to test your configuration and view the styling. After configuring a module, click Preview in the Module Editor 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
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:
An end-user End-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.
An end-user can view but cannot write or engage with your application, module, or component.
An end-user has full access to write and engage with your application, module, or component.
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.
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.
There are different types or levels of RBAC. You can set up RBAC for your environment, your modules, and even individual components.
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.
TIP 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 is unique in that you can overwrite a role's default permission for a module. Changes to permissions at the module-level don't impact other modules. So, make sure to customize each module just the way you like it.
In Module Editor settings, you'll set the Customize RBAC for the Module toggle to (ON). A grid displays showing a list of all module permissions in your environment. By default, each role has Inherit as the permission. 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 keep it as Inherit.
You can also set up access for anonymous (unauthenticated) end-users for your module.
NOTE 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.
TIP To learn more about module-level RBAC, see our Module Permissions article.
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 Editor 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.
TIP To learn more about component-level RBAC, see our Component Level Role-Based Access Control (RBAC) article.
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.