/
System Abstractions

System Abstractions

Owned by Guillermo Viedma
Last updated: Feb 27, 2025
2 min read

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

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"

Related content