/
Requirements: Roles and Permissions

Requirements: Roles and Permissions

This document aims to clarify the requirements for the roles and permissions system based on the PDR and System Abstraction. We strive to establish a clear consensus on mandatory and optional features to identify the essential requirements for our new implementation, enabling us to evaluate various frameworks, services, and libraries.

Functional Requirements

Core

  • Role Management: The system must provide Create, Read, Update, and Delete (CRUD) operations for roles.

  • Permission Management: The system must provide Create, Read, Update, and Delete (CRUD) operations for individual permissions.

  • Support for Implied Permissions: The system should allow specific permissions to implicitly grant other, related permissions (e.g., 'edit' implying 'read').

  • Grant Management: The system must provide Create, Read, Update, and Delete (CRUD) operations for managing associations between users, roles, and scopes.

Granularity & Scope

  • Object-Level Permissions: The system must support assigning permissions to specific individual resources (e.g., "course A").

  • Multi-Resource Permissions: The system must allow granting a single permission across multiple specific resources (e.g., "view" for "course A" AND "course B").

  • Resource Grouping: The system must enable the creation and management of resource groups (e.g., "all courses in Org A", "site", "all Course-Runs in CourseX").

Extensibility

  • Plugin-Defined Permissions: The system must provide a mechanism for external plugins to register and define roles and permissions within the core service.

Non-Functional Requirements

  • Scalability: The system must be designed to handle a large number of users, resources, and permission rules without significant performance degradation.

  • Performance: Permission checks must be efficient and introduce minimal latency.

  • Auditability: The system should provide mechanisms to audit permission assignments and changes related to role management.

  • Manageability: The system must offer administrative tools or APIs for easy role and permissions management.

  • Query Support: The system should expose APIs or interfaces that enable efficient querying of permission data.

  • Integration: The system must integrate seamlessly across Open edX services (e.g., LMS, Studio, etc), ensuring consistent permission enforcement and compatibility with existing authentication and data models.

  • Maintainability: The system should be modular and well-documented. The implementation should avoid unnecessary complexity to facilitate future updates and debugging.

  • Operational overhead (complexity, deployment, resource usage)

Optionals

  • Logical Combinations: The system should support defining permissions using logical combinations (e.g., boolean operators) of resources within permission rules.