Roles and Permissions Technical Specification

Context

The goal of the first phase of this project is to complete discovery on the current roles and permissions (authorization) implementation in Open edX with the goal of discovering the path forward towards an implementation that will allow for creating a more robust solution that includes solutions to the current problem set (custom roles, bulk assignment, etc) and be flexible enough to allow for future requests/requirement changes.

The authorization system currently includes multiple ways to assign a user an access level. The first phase of this project will focus on course level roles. 

Links/Research

R&P Problem Set

Open-edX Authorization Issue

Architectural Vision & Principals - Authorization

Key Decisions

• Roles should be context dependent

• Roles will exist system wide, but are not required to be used system wide

• New code will be within the edx-platform repo, but will have new models

• Implement course level role changes first

• Changes will be incorporated into Edge

• MVP will include:

  • 1 new role designed to improve the studio/CMS experience

  • Visual representation of the broad permissions a role has

  • DB change - Linking a role to a set of permissions (first step towards making roles customizable)

  • Stretch Goal: Course Teams UI update to facilitate easier role assignment

Risks

Authorization touches many other parts of the codebase. As such any change can have significant impact, but also significant risks. In order to limit risks, we are:

• Prioritizing understanding the current ecosystem

• Prioritizing socialization of the solution

• Planning an incremental approach

• Not planning any changes to the current roles, until after we’ve proven out this solution with a new role 

External Dependencies

Many/most portions of the code touch some portion of authorization. We anticipate dependencies with only the following areas for the MVP, but acknowledge that later on this list will grow to include other areas.

Known External Dependencies for the MVP include:

• the Course Teams Page within the CMS

• the Instructor Dashboard within the LMS

Out of Scope for Phase 1

• Django admin dashboard permission sets - potential phase 2

• V2 Library context level permissions

• edx-rbac permissions

• Student/Learner role (implicit role)

High Level Work Plan

Phase 1

current phase as of July 2023

Pre-MVP Work

1. Research current authorization implementation

2. Proposed changes needed to meet problem set goals

3. Map existing roles to permission sets 

   1. Does not require completion prior to starting MVP, but must be completed to finish the MVP

MVP

4. Add 1 new course level role

   1. Does not require using new architecture, but the new architecture will be used as a test case to validate assumptions and lower the risk when switching to the new architecture

5. Add visualization of course level roles and their permissions to the UI (potentially as a matrix)

Post MVP

6. Implement new architecture for existing course level roles

   1. Switch course level roles and discussion roles to roles based on permission sets

   2. Update code authorization checks to check for permission and not specific role

      1. Must be done in a way that allows the current and the new systems for course level roles to continue to function

7. Potential features to be completed as part of Phase 1:

   1. Bulk role assignment

   2. Bulk role removal

   3. Custom roles

   4. Admin Panel

   5. Assigning course roles at an org level

Phase 2

Phase 2 features will be determined based on the impact of the phase 1 changes. Areas that may be included are:

1. Django Admin Dashboard role assignment

2. Potential UI changes for user/group assignment

3. Potential UI changes to allow visualization of roles within the LMS/CMS (studio) views

4. Bulk access removal changes to include access granted via django admin, not just course roles

5. v2 Library Roles

6. etc

Measuring Outcomes

Each phase will have separate goals and outcomes. 

MVP 

We will know that it is successful when we see users using the new role and through partner/stakeholder feedback. 

Phase 1

We will know that it is successful when we see users using bulk assignment/removal of user roles.

We will know that it is successful when we see users creating custom roles.

Other Requirements

• Accessibility

  • Any UI changes should meet minimum A11y requirements for the Open edX platform.

• Data Engineering

  • Changes should be backwards compatible with a plan to slowly remove the current course roles systems as adoption of the new system occurs.

• Open edX and open-source communication

  • Solution should be developed in the open source repos. Documentation should be created and made available in the open source documentation locations (confluence, read the docs, etc).

  • Solution should be socialized and accepted by the open source community (Axim and key third parties should be involved in vetting the proposal before it is implemented).

• Scalability

  • System must meet current scalability standards as it will be implemented within the edx-platform repo and MySQL db.

• Security

  • System must meet current security standards as it will be implemented within the edx-platform repo and MySQL db.

  • Roles should not provide more access than needed by a user to complete their tasks.

• Related technical debt

  • The work will generate technical debt (removal of current course level authorization systems) that should be accounted for after adoption has reached a high enough level.

Rejected Alternatives

Each decision document includes a list of alternative options considered as well as the pros and cons for each option considered, including the chosen option. The specific reasons why an option was chosen were not documented, however each decision was discussed in an Open edX Arch Hour meeting. 

Key Alternatives Considered

Utilizing the existing edx-rbac pattern

• This option was determined to be risky because of the increased data being stored in the JWT. Additionally there was not a clear option for custom roles utilizing this pattern.

Building on top of the existing course roles tables

• This option was considered, but would add complexity to the work to create custom roles. The chosen solution is very similar, but will simplify custom roles and migration of data. It will also require less complexity in order to maintain backwards compatibility during the transition.

Creating an IDA for authorization

• This option was determined to be conceptually strong, but to require the largest amount of work before value was added by the work. Additionally it adds technical complexity (both in having a new IDA and in order to ensure there isn’t latency in retrieving roles data for use by edX Studio/CMS and the platform/LMS).