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

This document describes the design and integration plan of the Administrative Console MVP, covering the first integration of the platform with the library-scoped AuthZ implementation. The document outlines how the MVP is incorporated in the existing libraries experience and provides technical guidance for development and integration.

The MVP serves as a foundational step toward the creation of a new complete application to centralize the platform administration. It allow us to validate assumptions about usage and architecture while delivering immediate value centralizing AuthZ functions.

Refer to https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5032509472 for a product POV.

This MVP is part of a phased rollout of a broader administrative console. In Phase 1, the focus is to embed AuthZ management features for the libraries scope directly into the authoring MFE, avoiding the complexity of managing a complete separate interface. The goal is to deliver visibility into user roles and permissions and to provide basic management capabilities with minimal changes to infrastructure. The MVP will be limited to what is described in the scope definition and future phases may decouple the console for broader administrative functions and scopes.

• Administrative Console (or Console): A unified interface/service designed for administrators to perform essential platform operations across Open edX. The Console will eventually centralize administrative tools, including role and permission management, in a standalone, cohesive UI.

• Console Panel (or Panel): A dedicated section within the Administrative Console that focuses on a specific domain or function.

For the purposes of this MVP, the Panel refers to the library-scoped role and permission management UI.

• Limit the scope to content libraries.

• Frontend development in Authoring MFE for quick iteration.

• No specific backend, connect to AuthZ service directly.

• Use deep linking (URL queries and parameters) for giving the specific scope to the AuthZ panel during the redirection.

• Use libraries as the unique entry point to access the console MVP.

• It is desired to implement the MVP for Ulmo release.

• Limit the views to just the library in scope (no library filter selection).

The information here is consolidated and updated according to the feedback in this document, the PRD https://openedx.atlassian.net/wiki/x/IAD2KwE and the weekly meeting notes https://openedx.atlassian.net/wiki/x/AYDmHgE.

• Centralize AuthZ operations (view users/roles, assign roles) in a library-scoped Console Panel.

• Provide a single UI entry point for admins via the Authoring MFE.

• Document technical constraints and decisions for Ulmo.

The information described in this section is complemented by the work developed by the UX/UI team in the wireframes https://www.figma.com/design/q3Knq0BKoVTBbtaxb81n9R/RBAC---Console---Wireframes?node-id=2214-1603&m=dev&t=txIaINx3fretsp3o-1.

The library administrator is the main persona. For more information, see https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5032509472/MVP+-+Administrative+Console+AuthZ#4.1--Personas. For this document, all user personas are referred to as library admin.

• The navigation to AuthZ Panel could be leverage using the current mechanism, that mean, the “Manage Access“ button in library information sidebar component.

• The interaction with the button should open a new tab in the browser with the route of the Console Panel. This one should be register in the Authoring MFE router to work as a path of the application. Additionally, the context is added by the inclusion of the library_id in the URL.

• This approach introduces the new experience and workflow but keeps users in the library context.

• From the point of development, the implementation is supported by the existing session/auth context, reducing any initial configuration or specific integration with the backend.

The user capabilities are described in https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5032509472/MVP+-+Administrative+Console+AuthZ#4.2--Key-Jobs%E2%80%91to%E2%80%91Be%E2%80%91Done-(JTBD).

• Currently, the libraries module makes the permission-aware UI by:

  • Metadata in the library that check if the library is configured as public (allow_public_read). In this case, allows read access to users in general.

  • Validation of edition permission with the canEditLibrary flag, and the interaction with the TeamModal component. Once the modal is displayed, the API return the list of library members that includes the access_level and email, finally the fronted validate the condition of administrator (in the scope or global) to show the action buttons or just view the list of members (author role).

From the perspective of the Console MVP integration, the Panel:

• Must restrict UI access exclusively to library administrators, who are authorized to manage users and roles within the scope. This validation should occur through backend checks, and an error message should be displayed if access is denied.

• Libraries could need modifications in the validations to reflect any change based on the new roles and permissions.

In addition, the Console MVP does not attempt to modify the current user experience for those that do not have permission related to role management, which means the current modal is used as a read-only list of team members within the library context.

Open

Architecture Diagram for Console MVP

• Integration model:

• UI Composition:

  • New Console Panel to manage library-scoped AuthZ functionality.

  • Component to display users and roles.

  • Component for explanation of roles.

  • Group action for user and role management.

  • Authoring alert/toast build-in system for displaying user action feedback.

  • UI relies on existing shared layout components (header/footer) and navigation framework.

From the Console perspective, the first iteration aims to connect the Panel directly with the backend API defined by the AuthZ service. As a consequence we should:

• Adapt the current libraries API to match the AuthZ roles and permissions validations in require_permission_for_library_key. Then the authoring MFE will connect with the following endpoints, maintaining the ongoing request contract.

• The AuthnZ service creates its own API, and the Panel connects to it to manage roles (CRUD operations).

The AuthZ features will rely on the LMS/Studio session, which is already active in the authoring MFE. API endpoints should use the standard way of communication client-server (JWT) https://docs.openedx.org/projects/edx-platform/en/latest/concepts/rest_apis.html. No separate login flow is needed.

The MVP will focus on identifying extension points through slots within the Panels. While some general points may apply, it's important to recognize that each Panel may have different requirements, leading to the development of distinct slots.

The phased rollout helps us iterate on integrating these slots by considering usability (identifying real case scenarios for it) and security (balancing flexibility with the management of sensitive data and compliance).

Some potential points of extension for the MVP are:

• org.openedx.console.[panel].title.section.v1: For changing the default title or adding any additional information (e.g. a descriptive paragraph, informative banner).

  Open

  

• org.openedx.console.[panel].table.actions.v1: Useful for adding/limiting bulk actions (e.g., export button).

• org.openedx.console.[panel].table.filters.v1: Modify(limiting) the default filters on a data table visualization.

The name of the listed slots follow the standards of frontend-plugin-framework https://github.com/openedx/frontend-plugin-framework/blob/master/docs/decisions/0003-slot-naming-and-life-cycle.rst. For the MVP the word panel in the slot name could be replaced with authz.

From the backend perspective, the MVP will not provide any extensibility points, as there is no backend specific yet.

• Frontend (Authoring MFE):

  • Update the button validation in libraries for the redirection to the new view.

  • Integrate the new module inside the application (add it to the MFE router). The routes could be under /console/authz/libraries/{library_id} or similar.

  • Update the endpoint and/or code logic to match the changes in roles and permissions do it by the new AuthnZ service.

  • Authoring MFE has a set of generic components that could help with some of the steps in the user interaction, and allow developers to focus on the development of the AuthnZ related components and logic. The components that could leverage the console are:

    • Alert components: Feedback and error messages could be manage by the reusable Alert Context of the MFE.

    • Modal Notification: Actions that require confirmation could use the component with a confirmation and cancel button.

• Frontend Components to Build:

  • AuthZPanel: Main panel rendering users and roles.

  • UserList: Displays all users in a library with role status.

  • RoleManagement: UI for assigning/removing roles.

  • PermissionDeniedView: Shown on 403 errors.

  • RoleExplanation: Describes role definitions in the scope.

  • AuthZContext: Centralized place to manage the logic given a scope.

• API Client Usage & Error Handling:

  • Use AlertContext to show success/failure messages.

  • Display loading indicators when fetching the data.

• Backend (Minimal Support):

  • Endpoints Required:

    • List users (team) in library with it corresponding roles.

    • Assign role to user.

    • Revoke role from user.

The current permissions per role are located here https://github.com/openedx/edx-platform/blob/master/openedx/core/djangoapps/content_libraries/permissions.py.

• Permission Checks:

  • Only library admins can modify user roles.

  • API must validate session and role-based access.

• API Contracts:

  • Specified by the AuthZ design.

• Should be integrated in the current authoring workflow.

• Should not add any extra step for operators at this stage.

• Relies on existing session/auth flows, no external setup needed.

• Only minimal backend support added and tied to RBAC/Libraries API contract.

• Follow frontend architecture conventions of Authoring MFE.

• Must avoid leaking sensitive data to unauthorized users.

• MVP should align with Ulmo release timelines.

• MVP limited to library scope only; not intended for global or cross-domain RBAC management yet. However, the MVP save as foundation for future stages and should contemplate it in the design.

Risk:

• Decisions in the AuthZ system might affect the Console Panel approach.

• The deprecation of the legacy system and the adoption of a new one could introduce delays or resistance if the transition is not clearly communicated and well understood by stakeholders.

• Incomplete or inconsistent permission definition may cause confusion and lead to unauthorized access or over-restriction.

• Large user/role list that might cause performance issues or reduce the user experience.

Trade-offs:

• Embedding in Authoring MFE accelerates MVP delivery, but couples the Console Panel to a specific domain and may constrain design in some parts due to the reuse of components.

• Delaying standalone console limits future extensibility for broader use cases.

• Frontend Tasks:

  • Build AuthZPanel, UserList, RoleManagement.

  • Integrate route /console/authz/libraries/:id or similar.

  • Update the “Manage Access” button logic for redirection of library admins.

  • Apply permission-aware rendering logic in the Panel.

  • Update permission-aware Library Module validation to match the new AuthZ service.

• Backend Tasks:

  • Validate if new endpoints are needed.

  • Add/extend/modify role assignment/revocation APIs based on AuthZ implementation.

  • Ensure permission checks on each endpoint based on AuthZ implementation.

• Integration Tasks:

  • Register new route in Authoring MFE.

  • Ensure session/auth context is available.

  • Create a component to communicate the changes in roles and permissions. We can explore the creation of an Info/Alert Banner at the top either Libraries or Console Panel (in this case we can use org.openedx.console.[panel].title.section.v1 if we want to create a temporal component).

This section outlines the pathway to a gradual transition into phase 2 of the Console, as envisioned in the long-term approach https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5119967254/Foundations+and+Technical+Evolution#2.-Standalone-MFE-%2B-Administrative-Django-plugins.

From the user perspective, the Authoring module will work until the AuthZ Panel has been fully migrating to the Console MFE.

• During the iteration of the MVP, adjust and modify any identified issue, especially but not limited to the backend and frontend API contract.

• Set up the foundations for the Console standalone MFE repo (CI, building, i18n, layout, etc.) following the Open edX standards.

• Integrate with the existing Open edX platform (share session/authentication and authorization).

• Create a router strategy that builds a dynamic routing register power-up with frontend-plugin-framework, enabling future panel additions using the env.config.[tsx|jsx] file.

• Extract the logic and UI components for AuthZ Panel to the Console MFE repository.

• Replicate or adopt a system for generic components used in Authoring (Alert context and confirmation modal, for user feedback).

• Register the Panel in the Console MFE router.

• Test the library scope is working properly.

• Update Authoring MFE to redirect to the new Console MFE (with deep link to the library scoped panel).

• If there is no regression in the user experience, deprecate/remove the module from the Authoring MFE.

Note: This part could be limited by the AuthZ service development and approach.

• Allow the panel to work with multiple libraries when accessed from the standalone MFE. Introduce a library filter for this case.

• Choose a second scope (Course, Forum, Organization, or Site), that uses the AuthZ service.

• Test the AuthZ Panel with the new scope, if necessary modify the logic or UI for adapting the given scope.

Note: Other considerations may arise when we implement the console IDA. We will review potential impacts on panel behavior in future stages.

• How should the UI behave if the user loses permission mid-session?

• What could be the best strategy for gathering the user feedback once the MVP is launched?

• https://openedx.atlassian.net/wiki/x/IAD2KwE

• https://openedx.atlassian.net/wiki/x/AgAwMQE

• https://openedx.atlassian.net/wiki/x/FoAsMQE

• https://www.figma.com/design/q3Knq0BKoVTBbtaxb81n9R/RBAC---Console---Wireframes?node-id=2214-1603&m=dev&t=txIaINx3fretsp3o-1