feat: Role based access control #277

New Issue

MrUnknownDE · 2026-04-05T16:17:14+02:00

MrUnknownDE commented

2026-04-05 16:17:14 +02:00

Originally created by @wayneshn on 8/21/2025

This pull request introduces a comprehensive Role-Based Access Control (RBAC) system using the CASL (pronounced "castle") library. This is a major enhancement to the application's security, moving from a basic authentication model to a fine-grained permissions system.

Summary

The primary goal of this update is to secure the application by ensuring users can only access resources and perform actions they are explicitly permitted to. We have replaced the previous custom IAM implementation with CASL, which provides a more flexible, and maintainable way to manage permissions. #23

Key Features & Changes

CASL for RBAC:
- Policies are now defined using CASL's JSON-based rules, which include actions, subjects, and optional conditions for attribute-based and resource-level control.
Resource-Level Access Control:
- Ingestion sources are now associated with the user who created them.
- Permissions can be defined to grant users access only to their own resources (e.g., a user can only see and manage their own ingestion sources).
Secure API Endpoints:
- A new requirePermission middleware has been implemented and applied to all relevant API routes (dashboard, ingestion, search, archive, iam, users).
- This middleware checks if the authenticated user has the necessary permission to perform the requested action on the given subject before allowing the request to proceed.
User & Role Management:
- New API endpoints have been added for full CRUD (Create, Read, Update, Delete) functionality for users.
- Role management endpoints are now secured, allowing only users with manage: all permission (i.e., Super Admins) to create, update, or delete roles.
Secure, Filtered Search:
- The search service now enforces permissions at the query level.
- CASL conditions are translated into Meilisearch and Drizzle queries, ensuring that search results and data fetching only return records the user is authorized to view.
Inherent Permissions:
- The system now supports derived permissions. For example, a user with read access to a specific ingestion source will automatically have read access to all emails archived from that source. This simplifies policy management significantly.

*Originally created by @wayneshn on 8/21/2025* This pull request introduces a comprehensive Role-Based Access Control (RBAC) system using the CASL (pronounced "castle") library. This is a major enhancement to the application's security, moving from a basic authentication model to a fine-grained permissions system. ### Summary The primary goal of this update is to secure the application by ensuring users can only access resources and perform actions they are explicitly permitted to. We have replaced the previous custom IAM implementation with CASL, which provides a more flexible, and maintainable way to manage permissions. #23 ### Key Features & Changes * **CASL for RBAC:** * Policies are now defined using CASL's JSON-based rules, which include actions, subjects, and optional conditions for attribute-based and resource-level control. * **Resource-Level Access Control:** * Ingestion sources are now associated with the user who created them. * Permissions can be defined to grant users access only to their own resources (e.g., a user can only see and manage their own ingestion sources). * **Secure API Endpoints:** * A new `requirePermission` middleware has been implemented and applied to all relevant API routes (`dashboard`, `ingestion`, `search`, `archive`, `iam`, `users`). * This middleware checks if the authenticated user has the necessary permission to perform the requested action on the given subject before allowing the request to proceed. * **User & Role Management:** * New API endpoints have been added for full CRUD (Create, Read, Update, Delete) functionality for users. * Role management endpoints are now secured, allowing only users with `manage: all` permission (i.e., Super Admins) to create, update, or delete roles. * **Secure, Filtered Search:** * The search service now enforces permissions at the query level. * CASL conditions are translated into Meilisearch and Drizzle queries, ensuring that search results and data fetching only return records the user is authorized to view. * **Inherent Permissions:** * The system now supports derived permissions. For example, a user with `read` access to a specific ingestion source will automatically have `read` access to all emails archived from that source. This simplifies policy management significantly.

MrUnknownDE closed this issue

2026-04-05 16:17:14 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OpenArchiver#277