Module-Level Role-Based Access Control (RBAC)

Module-level RBAC provides default permissions for all components in a module. It sits between environment-level role defaults and component-level permissions, enabling efficient security across entire modules.

Module-level RBAC controls end-user access to modules by setting default permissions for each Express Role at the module level.

How Module-Level RBAC Works

Module-level RBAC behavior differs depending on whether the Customize RBAC for This Module toggle is on or off, and how effective permissions are computed from the inheritance chain.

When RBAC Is Enabled

When Customize RBAC for This Module is enabled, the system activates granular permission control:

• Explicit permissions can be set for each Express Role.
• Components inherit the module's permission settings by default.
• Components can override module permissions individually.
• The system computes effective permissions by evaluating the permission hierarchy.

Permission Hierarchy:

none (lowest) < read < write (highest)

When an end-user has multiple roles, the highest permission level wins.

Note: The Obfuscate permission is only available at the component level, not at the module level.

When RBAC Is Disabled

When Customize RBAC for This Module is OFF:

• The permissions table is disabled.
• Only end-users with the NoAccess role are restricted.
• All other roles automatically get Write access to the module and its components.
• Component-level permissions are ignored.
• Anonymous Access is automatically disabled.

Critical Distinction: Disabling RBAC grants Write access to all non-NoAccess roles by default, instead of requiring explicit permission grants.

Effective Permissions

Effective permissions are the final computed permissions after evaluating the entire inheritance chain.

The system tracks:

• Permission value: The actual permission level (none, read, write).
• Source: Where the permission came from:
  • Role Defaults: Inherited from the Express Role's default permission.
  • Module: Set explicitly at the module level.

Evaluation Order:

1. Admin roles: Always get Write permission.
2. NoAccess role: Always gets None permission.
3. Other roles:
   • If the component has an explicit permission set, the component permission applies.
   • If the module has an explicit permission set, the module permission applies.
   • If the role has a default permission, the role default applies.
   • If none of the above are set, None applies.

Module RBAC Settings

The following settings appear in the User Permissions section of the module settings panel.

Customize RBAC for This Module

What it does:

• When ENABLED:

  • Activates the permissions table.
  • Explicit role-to-permission mappings become active.
  • Components can have field-level permissions.
  • End-users see the module based on their explicit permissions.

• When DISABLED:

  • Permissions table is disabled.
  • Only the NoAccess role is restricted.
  • All other roles get Write access automatically.
  • Component permissions are ignored.
  • Anonymous access is disabled.

Storage: Stored as module.settings.enableRbac (boolean)

Allow Access to Anonymous Users

What it does:

• Lets unauthenticated end-users access the module.
• Only works when Customize RBAC for This Module is enabled.
• When enabled, specific permissions can be set for the Anonymous role.

Restrictions:

• Automatically disabled when Customize RBAC for This Module is set to OFF.
• Cannot be enabled without RBAC customization.

Storage: Stored as module.settings.enableAnonymous (boolean)

Permissions Table

The permissions table displays all Express Roles and their permission settings for the module.

Columns:

Permission Options:

At the module level, the following options are available:

• Inherit: Use the role's default permission from environment settings.
• No Access: Block access completely. End-users cannot see or access the module.
• Read-Only: End-users can view data but cannot edit it.
• Write: End-users have full access to view and edit data.

Note: The Obfuscate option is only available at the component level, not at the module level.

Disabled Rows:

• Locked modules: All selectors are disabled.

Enabling Module-Level RBAC

1. Open the module in Module Builder.
2. From the Definition drop-down, select Settings.
3. In the left sidebar, select User Permissions.
4. Toggle Customize RBAC for This Module to ON. The permissions table becomes active.
5. For each Express Role, select a permission from the Permission drop-down:
   • Inherit: Use the role's default permission.
   • No Access: Block access completely.
   • Read-Only: View only.
   • Write: Full access.
6. Review the Effective Permission and Inherited From columns to verify the computed result.
7. Click Save.

To grant unauthenticated access, toggle Allow Access to Anonymous Users to ON and set a permission for the Anonymous role, typically Read-Only or No Access.

Permission Inheritance Examples

The following examples show how permission levels are computed across different configurations of RBAC, role defaults, and module overrides.

Example 1: Basic Inheritance

Environment Setup:

• Role: Standard User
• Role Default Permission: Read

Module Configuration:

• Customize RBAC: OFF

Result:

• Standard User gets Write access (disabling RBAC grants Write to all non-NoAccess roles).

Example 2: Module Override

Environment Setup:

• Role: Standard User
• Role Default Permission: Read

Module Configuration:

• Customize RBAC: ON
• Standard User Permission: Write

Result:

• Standard User gets Write access (module overrides role default).

Example 3: Multiple Roles

Environment Setup:

• User: Jane
• Roles: Viewer (default: Read), Editor (default: Write)

Module Configuration:

• Customize RBAC: ON
• Viewer Permission: Read
• Editor Permission: Write

Result:

• Jane gets Write access (highest permission from all roles).

Example 4: Anonymous Access

Environment Setup:

• Role: Anonymous (default: None)

Module Configuration:

• Customize RBAC: ON
• Allow Anonymous Access: ON
• Anonymous Permission: Read-Only

Result:

• Unauthenticated end-users can view the module but cannot edit.

When to Use Module-Level RBAC

Module-level RBAC is most effective when access rules are consistent across most or all components in a module, or when a secure default needs to be established before individual fields are tuned. The following scenarios illustrate where this approach adds the most value.

All Components Should Have the Same Rules

If every field in a module should have identical access rules for each role, set it once at the module level instead of configuring each component individually.

Tip: For example, an employee directory module where all fields (name, email, phone) should be read-only for Standard Users and writable for HR Managers.

Establishing a Security Baseline

Set conservative defaults at the module level, then override specific components that need different permissions.

Note: Set the module to Read-Only for most roles, but mark a Comments field as Write for all authenticated end-users.

Building Public-Facing Modules

Enable Anonymous Access and set appropriate permissions for unauthenticated end-users.

Note: A product inquiry form where anonymous users can submit data, with form fields set to Write, but cannot view submissions, with data tables set to No Access.

Minimal Component Overrides

If only a few fields need special permissions, it is more efficient to set module defaults and override exceptions.

Tip: For example, a claims form where most fields follow standard role permissions, but the SSN field needs to be obfuscated for certain roles.

Best Practices

The following practices reduce permission complexity and prevent unintended access.

1. Begin with Module Defaults

• Configure module-level permissions first.
• Set conservative defaults (Read-Only or No Access).
• Override at the component level only for exceptions.

2. Test with Different Roles

• Create test user accounts with different role assignments to test each role.
• Verify that effective permissions match expectations.
• Check the Inherited From column to understand permission sources.

3. Use Inherit When Possible

• Set roles to Inherit if the environment default is correct.
• Avoid unnecessary overrides that complicate maintenance.
• Override only when different behavior is needed.

4. Document Permission Decisions

• Add comments in Module Builder describing why certain roles have specific permissions.
• Maintain a permission matrix document for complex modules.
• Share with stakeholders before deployment.

5. Limit Anonymous Access

• Only enable anonymous access when absolutely necessary.
• Set Anonymous to Read-Only or No Access by default.
• Never grant Write access to Anonymous users for sensitive data.

6. Review Effective Permissions

• Always check the Effective Permission column after making changes.
• Verify that role hierarchy does not create unintended permissions.
• Use the lowest necessary permission level.

Common Patterns

The following patterns cover the most frequent module RBAC configurations.

Pattern 1: Public Submission Form

Use Case: Anonymous users can submit data, but cannot view other submissions.

Configuration:

• Customize RBAC: ON
• Allow Anonymous Access: ON
• Anonymous Permission: Write (for form fields)
• Component overrides: Set data tables to No Access for Anonymous

Pattern 2: Read-Only Reference Module

Use Case: Most end-users can view data; only admins can edit.

Configuration:

• Customize RBAC: ON
• Standard User Permission: Read-Only
• Administrator Permission: Write

Pattern 3: Progressive Disclosure

Use Case: Different roles see different levels of detail.

Configuration:

• Customize RBAC: ON
• Basic User Permission: Read-Only
• Advanced User Permission: Write
• Component overrides: Hide sensitive fields from Basic User (No Access), show to Advanced User

Pattern 4: Workflow with Stages

Use Case: Users can edit their own submissions, managers can edit all.

Configuration:

• Customize RBAC: ON
• Submitter Permission: Write
• Manager Permission: Write
• Use Groups to control data access between submitters and managers.