Bug - RBAC AuthZ - Course Admin gets 403 when assigning or removing roles on course scopes

[wgu-taylor-payne]

Description

A Course Admin (non-superadmin) receives a 403 Forbidden error when attempting to assign or remove roles on a course scope via the Admin Console.

Affected endpoints:

• PUT /api/authz/v1/roles/users/ (assign role)
• DELETE /api/authz/v1/roles/users/ (remove role)
• GET /api/authz/v1/roles/ (list roles — also affected)

Steps to Reproduce

1. Log in as a Course Admin on a specific course (not a superadmin)
2. Go to Settings > Roles and Permissions
3. Use the Assign Role button to assign Course Staff to a new user on the course
4. Observe a 403 error instead of a success toast
5. Open an existing team member's audit view and click the trash icon to remove their assignment
6. Observe a 403 error after confirming the deletion

Root Cause

Three issues in the permission layer:

1. @authz_permissions on the PUT/DELETE/GET methods only listed library permissions (manage_library_team, view_library). The corresponding course permissions (manage_course_team, view_course) were missing.
2. No CoursePermission class was registered for the course-v1 namespace, so DynamicScopePermission fell back to BaseScopePermission which denies by default.
3. DynamicScopePermission only read a single scope from requests, but the PUT endpoint now accepts a scopes list for bulk assignment.

Expected Behavior

A Course Admin should be able to assign and remove roles on courses they have management access to, matching the behavior that Library Admins already have on library scopes.

[wgu-taylor-payne]

Approach A: Try-Any-Match

List both library and course permissions in the @authz_permissions decorator. The permission class tries each candidate against the scope and grants access if any one matches.

@authz_permissions([
    permissions.MANAGE_LIBRARY_TEAM.identifier,
    permissions.COURSES_MANAGE_COURSE_TEAM.identifier,
])
def put(self, request):
    ...

For a course scope, manage_library_team fails (no policy grants it on a course), then manage_course_team passes. For a library scope, the reverse happens. A new CoursePermission class (namespace course-v1) would be added alongside the existing ContentLibraryPermission (namespace lib), and a validate_any_permission method added to MethodPermissionMixin.

For multi-scope PUT requests (scopes list), each scope is checked individually — all must pass or the entire request is denied.

Pros:

• Consistent with existing codebase patterns — UserValidationAPIView, TeamMembersAPIView, AssignmentsAPIView already list both library and course permissions this way
• The @authz_permissions decorator remains the single source of truth for what permissions are relevant to a method
• Simple to understand — "this endpoint accepts these permission types"

Cons:

• Introduces validate_any_permission alongside the existing validate_permissions (all-match) — two similar methods with different semantics
• Every time a new scope type is added, every @authz_permissions decorator on every affected view must be updated manually
• For a library scope, it still tries the course permission (wasted is_user_allowed call that always returns False), and vice versa

[wgu-taylor-payne]

Approach B: Scope-Aware Dynamic Resolution

Keep @authz_permissions listing both permissions as candidates, but have DynamicScopePermission resolve the correct single permission per scope using ScopeData.get_admin_manage_permission() / get_admin_view_permission(). Each scope is checked against exactly one permission — no trial-and-error.

# DynamicScopePermission.has_permission (hypothetical)
for scope_value in self._get_all_scope_values(request):
    scope_data = api.ScopeData(external_key=scope_value)
    correct_perm = scope_data.get_admin_manage_permission().identifier
    if not api.is_user_allowed(request.user.username, correct_perm, scope_value):
        return False
return True

The CoursePermission class becomes optional since DynamicScopePermission can handle any scope type generically via ScopeData subclass dispatch.

Pros:

• No new validation method needed — each scope is checked against exactly one permission
• No wasted permission checks — each scope resolves to the right permission directly
• Adding a new scope type only requires implementing get_admin_manage_permission() on the new ScopeData subclass; no decorator changes needed across views

Cons:

• The @authz_permissions decorator becomes documentation rather than the enforcement mechanism — the actual permission checked is determined by ScopeData, not the decorator
• Couples the REST permission layer to ScopeData's API-layer methods (get_admin_manage_permission, get_admin_view_permission)
• Harder to reason about — "what permission does this endpoint check?" requires knowing the scope type, not just reading the decorator
• Needs a way to distinguish "manage" vs "view" intent from the decorator to pick the right ScopeData method

Security note (applies to both approaches): There is no scope mismatch risk. is_user_allowed(username, permission, scope) checks the specific permission on the specific scope in the Casbin policy store. A library permission granted on a library scope cannot authorize access to a course scope.

[MaferMazu]

@wgu-taylor-payne, thanks for this detailed diagnostic and proposed solutions. ✨
I prefer approach A because, with approach B, we could be hiding the authorization logic, making debugging difficult. As you mentioned, "Harder to reason about — "what permission does this endpoint check?" requires knowing the scope type, not just reading the decorator."