Role Architecture for Students, Teachers and Administrators

Education permissions depend on relationship and context

Student, teacher, and administrator are useful role labels, but EdTech authorization usually depends on relationships: which course a student is enrolled in, which cohort a teacher is assigned to, who owns an assessment, and which administrative unit an operator manages. Server-side policies must evaluate those scopes.

Roles alone are not enough

• A student may read content only for active enrollments and submit only their own work.
• A teacher can manage resources/grades for assigned offerings, not every course with the same subject.
• Administrators may have campus/program scopes rather than global access.
• Grade changes and certificate overrides require stronger permissions and audit.
• Relationship changes should immediately affect access; cached authorization needs safe invalidation.

Authorization across course resources

Permission establishes the capability, then enrollment/assignment/campus scope proves that the actor can apply it to this resource.

Teacher access after a cohort transfer

Permission leaks common in EdTech

RBAC checklist

• Define capabilities and relationship scopes separately.
• Check enrollment/assignment on every resource mutation.
• Scope admin roles by organization where possible.
• Audit grade/certificate/identity changes.
• Test access immediately after enrollment and assignment changes.