System Abstractions
This document outlines the core abstractions for the new Role-Based Access Control (RBAC) system. These abstractions are intended to facilitate discussion and guide the architectural design process. They are not final definitions but serve as a foundation for collaboration.
Most of the proposals here are inspired by AWS IAM. Although we may not need to implement all of its features, it is know for its stability and scalability.
Permission
Defines what a user is allowed to do in the system.
Attributes:
Action: Specific action granted (e.g., "Edit Course Content").
Resource Type: The type of resource this action applies to.
Example:
PermissionA: {
"action": "create_course",
"resourceType": "Course"
}PermissionB: {
"action": "edit_organization_logo",
"resourceType": "Organization"
}
Resource Type
Defines structured platform entity categories that serve as fundamental components within the system.
Site: The highest level of administration, governing platform-wide settings, configurations, and access controls.
Organization: An administrative grouping for authoring and delivering learning experiences–typically an institution or department.
Course: A structured learning program containing instructional materials, activities, and assessments.
Course-Run: A scheduled instance of a Course with defined start and end dates, enrollment periods, and participant cohorts.
Library: A structured repository of reusable learning content that can be shared across multiple courses. Libraries allow content authors to manage a centralized collection of resources such as problem sets, videos, and assessments, which can be linked to various courses instead of duplicating content.
Note: This list is not final; additional resourceTypes will be added later in the project.
Resource
Represents specific instances of a Resource Type within the system. Resources are the concrete elements governed by permissions and scopes. Represents specific instances of a Resource Type that exist within the system.
Scope
A Scope defines how the system resolves relevant Resources Types for a given Permission.
Attributes:
Resource Type Mappings: Defines what subset of the platform is relevant.
Exceptions: Defines explicitly excluded Resources.
Scope Examples:
ScopeSite: {
"Site": *,
"Organization": *,
"Course": *,
"Course-Run": *
}
ScopeOrgA: {
"Organization": "OrgA",
"Course": "all Courses in OrgA",
"Course-Run": "all Course-Runs in OrgA"
}
ScopeCourseX: {
"Course": "CourseX",
"Course-Run": "all Course-Runs in CourseX"
}
Note: Excuse the unusual JSON formatting, these are not suggestions on how to structure the solution, but I believe it helps clarify the concept more effectively
Role
A Role is a set of permissions. Roles are stackable, meaning a user can hold more than one role simultaneously. Stackability implies that the user’s effective permissions are the union of all permissions granted by their assigned roles.
Attributes:
Name: The role name (e.g., "Instructor").
Permissions: The set of Permissions the role grants.
Examples:
Role: Instructor
Permissions:
"Edit Course Content"
"View Reports"
Role: Admin
Permissions:
"Delete Course"
"Manage Permissions"
Grant
A Grant relates a User with a Role and a Scope, mapping each permission to a Scope.
Attributes:
User: The individual receiving the role.
Role: The set of permissions assigned.
Scope: The resources where the role applies.
Examples:
User: Jane Doe → Role: Instructor → Scope: "Organization X"
User: John Smith → Role: Admin → Scope: "Global"
User Policies
User Policies define exceptions to standard role behavior.
Attributes:
User: The individual affected.
Permission: The action granted or restricted.
Scope: Where the exception applies.
Examples:
User Policy: Jane Doe
Permission: "Edit Course Content"
Scope: "Course 101"
User Policy: John Smith
Permission: "Delete Course"
Scope: "Organization Y"