AuthZ MVP: Libraries

AuthZ MVP: Libraries


1. Overview

Content Libraries allow course teams to create and curate reusable content in one place. Today, anyone who needs to work in a Library must be granted broad roles, exposing permissions that reach far beyond the Library itself. The Libraries MVP introduces library‑scoped roles (Admin, Author, and User) and a streamlined interface for assigning or revoking them. This change lets teams share work with only the access they need, reduces support overhead, and serves as the first production test of the new RBAC abstractions.

2. Background

Libraries enable a modular approach to content creation: authors, instructional designers, and subject‑matter experts can build learning sequences and lessons outside the course outline, tag and search them, group items into collections or randomized pools, and reuse them across courses with live updates.

Because these workflows often occur before a full course exists, and Libraries operate as a self‑contained area of the platform, they are a natural pilot for the new authorization model. Under the legacy system, contributors receive broad permissions, limiting control and clarity. The new AuthZ system is flexible enough to entroduce entroduce Library-scoped roles, making Libraries an ideal MVP for testing and refining upgraded authorization capabilities.

3. Problem Statement

  • Excessive permissions: Contributors still receive broad permissions, including Studio access, to work in Libraries. This grants more access than necessary.

  • Limited cross‑library visibility: Each Library shows its own access list in two clicks, but there is no consolidated dashboard. Admins cannot view or export a single report of permissions across all Libraries.

  • Manual workload at scale: Without bulk tools, admins must audit and adjust access one Library at a time. This repetitive process is slow and error‑prone as the number of Libraries grows.

4. Goals

  • Enable library‑scoped role assignment and management.

  • Provide clear visibility into Library access rights.

  • Reduce admin overhead when onboarding or off‑boarding contributors.

5. Scope

In Scope (MVP)

  • Library‑level roles: Library Admin, Library Author, Library User.

  • Role‑management UI (initially in Django Admin or interim screen).

  • Map each library action to a specific permission.

  • Permission checks along user flows to block any action a user is not authorized to perform.

Out of Scope (Post‑MVP)

  • Custom role builder.

  • Bulk role assignment API endpoints. (TBD)

6. Constraints

  • UI must live in Django Admin or a minimal standalone page until the new dashboard is ready.

  • Authorization logic relies on the RBAC abstractions draft; definitions may adjust to technical constraints.

  • No back‑compat breaking changes for existing Library users.

7. User Personas

RBAC User Persona mapping

8. Library Roles & Permissions

Quick summary of the MVP roles:

  • Library Admin - Full control: create/edit/delete libraries, manage users and roles, publish libraries and content, manage tags, create/edit/delete collections, reuse content.

  • Library Author - Create and edit content, import from courses, publish content, manage tags, manage collections, reuse content, view library team. Cannot delete libraries or manage roles.

  • Library Collaborator - Create and edit content, import from courses, manage tags, manage collections, reuse content, view library team. Cannot publish content, delete libraries, or manage roles.

  • Library User - View and reuse published content, view library team. No editing or deletion rights.

Full doc: Library Roles and Permissions

9. Detailed Specifications & Validation Flows

10. 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.

11. Risks & Dependencies

  • Feature parity with the current version of Libraries

  • Spike research UX/UI

  • Spike Tech Architecture 

  • Review flows with the current UI to propose patches or enhancements