Implementing Basic Permission Systems

When designing a permission system, the architecture you choose shapes how your application handles security for months or years to come. Let’s explore the fundamental concepts of implementing permissions and how they relate to roles, independent of any specific language or framework.

Core Permission Concepts

At its heart, a permission system answers one question: “Is this action allowed?” To answer this question effectively, we need several key components:

1. Resources

Resources are the objects or entities that users interact with in your system. These might be:

• Data entities (documents, products, user profiles)
• System features (reports, dashboards, admin panels)
• Operations (payment processing, account management)

2. Actions

Actions define what can be done to resources:

• Read/View
• Create
• Update/Edit
• Delete
• Approve
• Share/Assign

3. Permissions

A permission is the combination of an action on a resource. Examples include:

• view_document
• edit_product
• delete_user
• run_report

Relating Permissions to Roles

Roles serve as collections of permissions that represent common user responsibilities. A well-designed system keeps these relationships clean and maintainable:

Role-Permission Mapping

The most common approach is to create a many-to-many relationship between roles and permissions:

• A role can have multiple permissions
• A permission can belong to multiple roles

For example:

• Admin role: [create_user, edit_user, delete_user, view_analytics]
• Editor role: [edit_document, publish_document]
• Viewer role: [view_document]

Permission Checking Models

When implementing permission checks, you have several patterns to consider:

1. Direct Permission Checks

Check if a user has a specific permission directly:

if (userHasPermission(currentUser, "edit_document"))

2. Role-Based Checks

Check if a user belongs to a role with the required permission:

if (userHasRole(currentUser, "editor") || userHasRole(currentUser, "admin"))

3. Resource-Specific Permissions

For more granular control, permissions can be scoped to specific resources:

if (canUserAccess(currentUser, "edit", documentId))

Storage Strategies

How you store permissions and roles affects both performance and flexibility:

1. Database Tables: Most common approach with tables for users, roles, permissions, and their relationships
2. Config Files: For smaller applications with static permissions
3. In-Memory Structures: For high-performance applications that can reload permission data

Common Implementation Patterns

Regardless of your technology stack, these patterns help build maintainable permission systems:

Permission Guards

Centralize permission checks in “guard” functions that run before actions:

function guardResourceAccess(user, action, resource) {
  if (!hasPermission(user, action, resource)) {
    throw new AccessDeniedError();
  }
}

Permission Decorators

Wrap functions that need protection with permission requirements:

@requiresPermission("edit_document")
function editDocument() {
  // Function code
}

Permission Inheritance

Allow roles to inherit permissions from other roles to reduce duplication:

• Admin inherits all Editor permissions
• Editor inherits all Viewer permissions

Best Practices

1. Default to Deny: Users should have no permissions by default
2. Principle of Least Privilege: Grant only the permissions necessary for users to perform their functions
3. Separation of Duties: Critical operations should require multiple roles
4. Regular Auditing: Review permission assignments periodically

By understanding these core concepts, you can implement a permission system that grows with your application, regardless of which technologies you eventually choose.