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