Levelbrook Labs

Building User Management & RBAC Demo: Notes on Technology Consulting

Patrick Donahue · Levelbrook Consulting

Try the interactive demo

In technology consulting, certain problems reappear with uncanny regularity. They aren't novel, yet their implementation details are consistently underestimated. At the top of this list is user management, specifically Role-Based Access Control (RBAC). It's the bedrock of any multi-tenant SaaS application, internal tool, or enterprise system. On the surface, it seems simple: users have roles, roles have permissions. Done. But this simplicity belies a deep complexity that touches every layer of the stack, from the database schema to the user interface.

This is what makes it a technically interesting problem. It's not an abstract algorithm; it's a socio-technical system that must precisely model an organization's trust boundaries and operational realities. Getting it wrong leads to security vulnerabilities, operational chaos, or a user experience so restrictive it grinds productivity to a halt. As an exercise, I built a working demo to codify some of these thoughts into a tangible artifact. These are the notes from that process.

The Domain Problem: A System of Record for Trust

At its core, an RBAC system answers one question, repeatedly and with high performance: "Can this user perform this action on this resource?" This question is asked implicitly with nearly every API call and UI render. The system must be both correct and fast.

The technical interest comes from the "based" in Role-Based. Access is not granted to users directly, but to roles, which are abstract representations of job functions (`Accountant`, `Project Manager`, `Read-Only Auditor`). This indirection is powerful. It allows administrators to reason about permissions at a functional level rather than an individual one. But it also introduces a layer of complexity that systems must manage. When a role's permissions change, that change must propagate to all users assigned that role, often in real-time.

Furthermore, in any real-world consulting engagement, the model quickly evolves beyond this simple structure to include:

This is no longer a simple CRUD feature; it's a core subsystem that dictates the architecture of everything else.

Architecting the System: From Data Model to UI

Any stack can solve this problem, from .NET and Java in the enterprise to Go, Python, or Node.js for more modern microservice architectures. The principles remain the same. Let's start with the foundation.

The Data Model: A Relational Core

Despite the popularity of NoSQL databases like MongoDB, the relationships inherent in RBAC are a natural fit for a relational model. PostgreSQL is my default choice for its robustness and support for complex queries. The core schema is a set of join tables modeling many-to-many relationships:

-- Users have Roles
Users (id, email, ...)
Roles (id, name, description)
UserRoles (user_id, role_id) -- Join Table

-- Roles have Permissions
Permissions (id, action, resource) -- e.g., ('edit', 'invoice'), ('view', 'dashboard')
RolePermissions (role_id, permission_id) -- Join Table

This structure is normalized and flexible. Adding hierarchical roles can be done with a self-referencing `parent_role_id` on the `Roles` table. Resource-specific roles would require modifying the `UserRoles` join table to include a `resource_id` (e.g., `project_id`), making the primary key `(user_id, role_id, resource_id)`.

A document database could model this by embedding roles and permissions within the user document. This makes reads for a single user extremely fast. However, it creates a significant write-side problem: if you update the permissions for the "Accountant" role, you must now find and update every user document with that role. This is a classic denormalization trade-off that often breaks down at scale for a write-heavy system like permission management.

The Backend: Centralized Logic and Authorization Middleware

Whether you choose a monolith (like Ruby on Rails or .NET MVC) or a dedicated microservice (in Go or Node.js), the authorization logic must be centralized. A common pattern is to issue a JSON Web Token (JWT) upon login that contains the user's ID and perhaps a list of their role names.

A critical decision is what to store in the JWT. Storing the full list of permissions can lead to token bloat and stale data. A better approach is to store just the `user_id` and role identifiers, then have the API gateway or backend middleware perform a fast lookup (ideally from a cache like Redis) to get the user's current permissions for each incoming request.

This check can be implemented as middleware that decorates each API endpoint:

// Pseudocode for a Node.js/Express middleware
function can(action, resource) {
  return async (req, res, next) => {
    const userPermissions = await getUserPermissions(req.user.id);
    if (userPermissions.has(`${action}:${resource}`)) {
      return next();
    }
    return res.status(403).send('Forbidden');
  };
}

// Usage
app.post('/api/invoices', can('create', 'invoice'), createInvoiceHandler);

The Frontend: Declarative UI and Real-Time Updates

On the frontend (React, Vue, Angular), the challenge is to prevent the UI from displaying options the user cannot act upon. A poor implementation shows a disabled button. A better implementation doesn't render the button at all. This requires the frontend to be aware of the user's permissions.

Upon login, the frontend should fetch the user's complete set of permissions and store them in a global state management solution (React Context, Redux, Zustand, etc.). This allows for the creation of a declarative `Can` component:

// TypeScript with React
interface CanProps {
  perform: string;
  on: string;
  children: React.ReactNode;
}

const Can: React.FC = ({ perform, on, children }) => {
  const { permissions } = useAuth(); // Hook to get permissions from global state
  const isAllowed = permissions.has(`${perform}:${on}`);
  
  return isAllowed ? <>{children}</> : null;
};

// Usage
<Can perform="edit" on="invoice">
  <EditInvoiceButton />
</Can>

The most interesting UX challenge is handling real-time permission changes. If an admin revokes a user's access while they are using the application, their UI should update immediately. This is where technologies like WebSockets or Server-Sent Events (SSE) shine. As a Rails developer, I often reach for Hotwire/Turbo Streams for this. The backend can push a targeted stream event to the specific user, which can trigger a page refresh, a redirect, or simply remove the now-forbidden UI elements from the DOM. This closes the loop between a backend state change and the user's immediate experience, which is crucial for security.

Pragmatic Tradeoffs and the Human in the Loop

Building a robust RBAC system is an exercise in managing tradeoffs. The perfect is the enemy of the good.

Performance vs. Freshness: Checking permissions against the database on every single API call is too slow. Caching is mandatory. A common pattern is to cache a user's permission set in Redis with a short TTL (e.g., 5 minutes). When an admin changes a role, you can either wait for the cache to expire or implement an explicit cache invalidation strategy. The latter is more complex but provides immediate consistency.

Off-the-shelf vs. Custom: Services like Auth0, Okta, and Clerk are excellent for authentication (AuthN) and basic authorization. They handle the complexities of password management, multi-factor auth, and social logins. However, when authorization logic is deeply intertwined with your application's core domain—like "a user can only edit invoices for the department they manage"—a purely external system often falls short. A pragmatic approach is a hybrid: use a third-party service for AuthN, but build the fine-grained authorization (AuthZ) logic in-house, tied directly to your application's data model.

Correctness and the Human Factor: An incorrect permission grant is a security breach. An incorrect denial is a frustrating user experience and a support ticket. This is where a human-in-the-loop process becomes invaluable. For high-stakes permission changes, especially creating or modifying powerful admin roles, the system shouldn't apply the change immediately. Instead, it could create a "proposed change" that requires review and approval from another authorized administrator. This pattern, borrowed from code reviews and Git pull requests, introduces a manual verification step that can prevent catastrophic mistakes. The system's job is to enforce the process, but a human provides the final judgment.

A Closing Reflection

User management and RBAC are not just features to be checked off a list. They are a manifestation of an organization's structure, trust, and processes, encoded in software. The engineering challenge is to build a system that is not only secure and performant but also flexible enough to evolve with the organization it serves. It's a problem space where a deep understanding of the database, backend logic, and frontend user experience must come together. It's a perfect microcosm of the full-stack engineering challenges that make technology consulting a perpetually engaging field.