Access Control RBAC

Production-grade role-based access control for securing UI components, routes, and actions in Dashforge applications.

What is Access Control?

Dashforge Access Control is a role-based permission system that determines who can do what in your application. Instead of scattering permission checks throughout your code, you define a central policy that maps roles to permissions, then the system enforces those rules automatically.

The system integrates directly with Dashforge components. Fields can hide, disable, or become read-only based on permissions. Navigation items filter automatically. Routes protect themselves. No manual wiring required.

import { TextField } from '@dashforge/tw';

function BookingForm() {
  return (
    <TextField
      name="customerName"
      label="Customer Name"
      access={{
        action: 'edit',
        resource: 'booking',
        onUnauthorized: 'readonly'
      }}
    />
  );
}

// Field becomes read-only if user lacks 'edit booking' permission
// No manual if statements. No scattered checks. Just declarative access.

The Problem

Without a central access control system, permission logic spreads across your entire application. Every component needs to know who the current user is, what roles they have, and what they're allowed to do. This creates three major problems:

1. Duplication: The same permission checks appear in dozens of components. "Can this user edit bookings?" gets repeated everywhere.
2. Inconsistency: One component hides the field when unauthorized. Another disables it. A third shows it anyway. No unified behavior.
3. Change amplification: When permission rules change, you must find and update every location. Miss one, and you have a security hole.

// BEFORE: Manual permission checks scattered everywhere

function BookingForm({ user }) {
  const canEdit = user.roles.includes('admin') || 
                  user.roles.includes('editor');
  const canDelete = user.roles.includes('admin');
  
  return (
    <>
      <TextField 
        name="customerName"
        disabled={!canEdit}
      />
      <TextField 
        name="bookingDate"
        disabled={!canEdit}
      />
      {canDelete && <Button>Delete</Button>}
    </>
  );
}

// Every component duplicates this logic
// Changing "who can edit" requires finding all these checks
// Easy to miss one. Easy to create inconsistencies.

Dashforge RBAC solves this by centralizing all permission logic in a single policy. Components declare what they need. The system enforces it automatically.

Core Features

Dashforge Access Control is built on three core capabilities:

• Central Policy Definition: Define all roles, permissions, and inheritance rules in one place. Supports wildcards, role inheritance, and allow/deny precedence.
• Three Unauthorized Behaviors: Components can hide, disable, or become readonly when access is denied. Declarative. No manual if statements.
• React + Dashforge Integration: Works with React hooks (useCan, useRbac), declarative components (Can), and all Dashforge form fields (TextField, Select, etc.).
• Navigation & Route Filtering: Built-in helpers for filtering LeftNav items, toolbar actions, and protecting routes based on permissions.
• Condition Support: Permissions can have dynamic conditions (e.g., "can edit if owner"). Synchronous evaluation. Type-safe.
• Framework-Agnostic Core: The RBAC engine is pure TypeScript with zero dependencies. Use it anywhere: Node.js, browser, edge functions.

Architecture

Dashforge RBAC is structured in three distinct layers, each with a clear responsibility:

Layer 1: Core Engine

Framework-agnostic RBAC engine. Evaluates permissions, resolves roles, handles precedence. Pure functions. Zero dependencies.

Layer 2: React Integration

React-specific bindings. Provides RbacProvider, useRbac, useCan hooks, and Can component. Manages context and lifecycle.

Layer 3: Dashforge Helpers

Dashforge-specific utilities. Includes resolveAccessState (for components), filterNavigationItems (for LeftNav), filterActions (for toolbars), and createAccessGuard (for routes).

This separation means you can use the core engine anywhere (even outside React), use the React layer in any React app, and use the Dashforge layer only when working with Dashforge components.

When to Use RBAC

Use Dashforge RBAC when you need:

• Multiple user types with different permissions (admin, editor, viewer, etc.)
• Component-level access control — hiding, disabling, or making fields read-only based on user role
• Navigation filtering — showing menu items only to users with appropriate permissions
• Route protection — preventing unauthorized users from accessing certain pages
• Centralized permission management — one source of truth instead of scattered checks

Don't use RBAC if:

• Your app has no user authentication (public-only app)
• You have only one user type with identical permissions
• Permissions are extremely dynamic and change on every request (RBAC assumes relatively stable rules)
• You need attribute-based access control (ABAC) with complex multi-factor decisions (RBAC V1 supports basic conditions, not full ABAC)

Next Steps

• Quick Start — Get RBAC running in your app in under 5 minutes
• Core Concepts — Learn about subjects, roles, permissions, and policies
• Dashforge Integration — See how RBAC works with TextField, Select, and other components