MVP - Administrative Console: AuthZ

A central space to gather user input, data and requirements for the Administrative Console MVP.

1  Overview

1.1  Purpose

This console aims to centralize platform-level settings and administrative tasks—including authorization (AuthZ) and, eventually, other key configurations—into a single, extensible UI. It reduces platform fragmentation and improves administrator efficiency.

1.2  Background & Context

Currently, Open edX administrators must rely on multiple disjointed tools (e.g., Django Admin, CLI, config files) for platform management. This situation results in overly broad permissions for simple tasks and inconsistent workflows. This MVP is the first step toward solving that by delivering a foundational admin console with a panel for AuthZ support for Libraries as the first iteration of the tool.

2  Problem Statement

There is no unified interface for day-to-day platform administration. Basic operations require high clearance or technical skills, and platform extensions lack a consistent configuration entry point. This increases operational risk and limits flexibility for institutions.

3  Goals & Objectives

3.1  Primary Goals

• Unify platform‑level administration in a single management console.

• Support AuthZ management in MVP by implementing a management panel; design architecture for future use cases (user groups, 3rd‑party integrations, etc.).

• Provide an extensible foundation that supports future AuthZ use cases beyond Libraries.

3.2  Success Metrics / KPIs

• Qualitative feedback from pilot users (admin efficiency, ease of use).

4  User Personas & Use Cases

4.1  Personas

For the MVP, these are the personas we’re targeting for:

• Library administrator: Manage roles and users within library scope.

• Platform administrators: Manage user access across the instance.

WIP

4.2  Key Jobs‑to‑Be‑Done (JTBD)

1. Assign and revoke roles or permissions for users, with visibility into current access levels and the scopes where those permissions apply, all from within the console panel.

2. View and audit recent privileged actions across the platform to ensure security and compliance.

3. Filter users by role or scope to simplify user and permission management at scale.

4. Prepare for future extensibility, such as configuring external services, general settings, waffle flags, or managing user groups from the same interface.

5. Navigate to the console to specific panels (in this case, AuthZ) from areas like Libraries, with context applied.

6. Support future extensibility for broader scopes like courses or forums (AuthZ).

WIP

5  Scope

5.1  In Scope (MVP)

• Panel for AuthZ management (view, assign, revoke roles for Libraries).

• User overview: list of users with current roles and scopes.

• Role overview: view available roles and their permission sets.

• Filter by role and scope.

• Entry point from Library section to the management panel with scoped filtering.

5.2  Out of Scope (MVP)

• Configuration of services outside of RBAC.

• Role creation or customization.

• Cross-service role propagation.

• Cross-library views and filtering

6  Requirements

6.1  Functional Requirements

This MVP will introduce foundational capabilities that enable authorization management for Libraries and lay the groundwork for future extensibility in the console itself and for authorization. Features are grouped by area to support design and architectural planning.

User Management

• View users and their assigned roles and scopes

• Filter and search users by username, email, role, or scope

• Access user detail to see full role and permission breakdown

Role Management

• View available roles and their permission sets

• Filter roles by permission

Role Assignment

• Assign roles to one or more users within a defined scope

• Modify the scope associated with a user's existing role

• Remove a role from a user, with safeguards to prevent complete access loss

General Expectations

Some of these expectations must be considered during the discovery phase, but won’t be addressed as part of the MVP since they don’t solve an immediate need:

• The same role must not be assignable more than once to the same user

• Users may hold multiple roles with overlapping permissions

• Roles are stackable (effective permissions are cumulative)

• Existing flows in Studio may be deprecated to avoid duplication

• Permission groups should support collapsibility and be truncated after N items or a scalable information architecture that allow navigation through long lists.

• Role removal must require confirmation, if it would leave the user without access the interface should notify that.

• Interface should anticipate future support for custom roles and advanced scope logic

• Permission dependencies must be considered (e.g., can’t assign “edit” without “view”, so “edit” must imply “view”). Not enforced in MVP, but must be accounted for in the UI or logic.

Benchmark Figma: Canvas Roles & Permissions – UX BenchmarkPreview

AuthZ MVP Wireframes: RBAC / Console - WireframesPreview

6.2  Non‑Functional Requirements

• Prioritize clarity and readability of the user-role views.

• Indicate scope boundaries and action affordances through visual hierarchy.

• Support responsive UI across different screen sizes.

• Render UI elements conditionally based on current user's permissions.

• Validate user permissions on the backend before executing AuthZ actions.

• Follow modular design principles to enable smooth progression to future development phases.

7  Extensibility & Integration Needs

The console must provide a stable core for AuthZ workflows, while supporting long-term extensibility. This includes:

• Entry points from other sections (e.g., Library detail opens the console panel for libraries authZ management in new tab with filters applied)

• The system must be flexible enough to support the console's evolution according to the phased rollout strategy in Extensibility and Pluggability FrameworkPreview

Beyond the MVP, the Console is expected to evolve into a fully extensible platform. This is covered here:PRD long-term vision - Administrative ConsolePreview

8  Architecture & Technical Constraints

• The console will be implemented as a module within the existing Authoring MFE, that communicates with the AuthZ service.

• Entry point opens a new tab filtered to the relevant scope.

• The MVP should deliver clear user value within a scoped, low-friction implementation, while setting the stage for potential expansion and decoupling in future phases.

Refer to:

Foundations and Technical Evolution | 1. New Authoring view + Administrative Django pluginsPreview

Technical Approach: Console MVP (AuthZ-Scoped, Ulmo Release)Preview

for a more detailed description.

9  UX/UI Considerations

• Focus on clarity, overview-first flows, and ease of navigation.

• Prioritize readability of roles and scopes.

• Allow collapsed views of long permission lists.

• UI slots for future extensions.

• Design starting after architecture spike.

Current wireframes and design WIP: RBAC / Console - WireframesPreview

10  Milestones & Timeline

11  Risks & Assumptions

• Unclear location (Studio vs new UI) could delay frontend work.

• Community plugin expectations exceed MVP scope.

• Possible user confusion if two RBAC interfaces coexist (Library view vs Console).

12  Open Questions

1. Should RBAC editing be restricted to Console only?

2. How will we prepare UI for custom roles and complex scopes?

3. Should permission groups be tagged by theme to simplify filtering?

4. How should we handle permission dependencies in the future?

5. Should removing all roles from a user always require confirmation?

13  Dependencies

• Backend RBAC system (Grants, Roles, Scopes, Permissions).