Authorization

Owned by Nimisha Asthagiri (Deactivated)
Last updated: Oct 16, 2022 by Alexander Dusenbery
3 min read

Background

Hypothesis: An intentional separation between each of the concepts below will allow us to have more flexibility in the platform without much-added complexity.

• (OAuth-)Client-level permissions are implemented as OAuth Scopes and captured in OEP-4.
• System-wide Roles are a set of roles that are to be used across the platform. They are configurable for the instance of the platform. That is, different Open edX instances may have different sets of Roles.
• System-wide User-Roles are mappings between users and system-wide roles, stored in a centralized user service (LMS today). They are communicated in JWT Tokens so different Features can enforce them.
• Feature-specific Roles are mappings between System-wide Roles and Feature-specific Roles. These are specific to the Feature and configurable for the instance of the platform.
• Feature-specific Role-Permissions are mappings between Feature-specific Roles and Feature-specific Permissions.
• Feature-specific Permissions are relevant to the features specific to the Feature and implemented as described in OEP-9.

Current Roles in the platform

System-wide Roles

  • Global Staff - a system-wide role to be used across our services to denote edX staff access.
    • Propagated in JWTs as the "administrator" field.
  • Enterprise Roles - system-wide roles that are propagated in the "roles" field in JWTs.
    • Enterprise User - to denote the user belongs to an enterprise
    • Enterprise Admin - to denote the user is an administrator of an enterprise

Service-specific Roles

  • Super User - a service-specific role to denote high-privileged access to a service (such as read-write access to Django admin and all exposed models).

Course-specific Roles

  • Course Staff - a course-specific role for read-write access to its content in studio, read-write access to learners' grades, etc.
  • Course Admin - a course-specific role with the same permissions as Course Staff, plus permissions to manage course team members and their own roles.
  • Course Data Researcher - a course-specific role that denotes whether the user is allowed to download learner data of the course.
  • Discussion Moderator and Community TA - roles denoting privileged access to discussion forums.

Use edx-rbac to perform JWT-role-based authorization across services

We offer edx-rbac to help manage role-based access control across services.  Seehttps://github.com/openedx/edx-rbac/blob/master/docs/how_to_guide.rst for background and implementation guidance.

Super quick explanation

With RBAC, you want your IDA to map system roles to feature roles.  The source of truth for the system roles is the LMS, and the LMS is what populates the roles in the JWT payload.  Your IDA will declare a mapping of  system roles to lists of feature roles in its settings.  It will also declare some rules predicates that check the JWT for the presence of some system roles, and then infers from the mapping that the user is assigned the associated feature roles. Optionally, you may declare predicates to check the RBAC tables in the IDA’s database for “explicit” user-feature-role assignments.  Your rules.py file will define some Django permissions based on the predicate functions you defined.  Lastly, RBAC provides a mixin you can use in your DRF viewsets to utilize the permissions you defined.  Here’s some prior art to (hopefully) tie this all together.