Safe LTI instructor provisioning

Let instructors access SolidProfessor through LTI

The scope is instructor access through the school's existing LTI integration. When an instructor selects the SolidProfessor tool in the LMS, the validated launch should sign them into SolidProfessor and create, connect, or promote their account just in time. Returning launches should recognize and reuse that same instructor account.

Instructor access—not institution provisioning

LTI just-in-time access is one way to support instructors. It can be made available across an existing mapped school, but each instructor is created or connected only when they launch the tool. A district may still use SSO, roster sync, or administrative provisioning alongside this option.

Five guarded steps from launch to instructor

The Packback library already validates the LTI launch before application provisioning begins. The new logic should consume only that validated launch data.

Backend touch points

These are the expected production and test changes. A final file count depends on the licensing decision described later.

Re-reviewed at cc6a47a28 — what landed since, and what to fold in

This proposal is pinned to baseline c8799473d5a5 and remains accurate against it. Re-reviewed against main at cc6a47a28 (Sept 2026): the conclusions still hold — the LTI roles claim is still unread, and new users still default to Student. Two things to fold in: changes that landed in ASE-1221, and additional touch points surfaced by the feasibility review (Report 02).

Changes that landed since (ASE-1221)

• Item #05's file was refactored. FindOrCreateUserForLtiContext.php now has a flag-gated (ACADEMIC_LTI_PRESERVE_MIGRATED_MEMBER_STATUS) path that claims an unlinked migrated member and preserves their status and role, and the new-user role is now a ternary. The #05 change (resolve role once, provision/promote, never demote) must integrate with this structure — there are now two privileged-role decision points plus the flag. No conflict: the roles claim is still unread.
• ProvisionUserToSchool.php did change. ASE-1221 added a primary-account fix (match null or false) that was 500ing LTI launches. The "no change expected" note still holds in intent (it accepts INSTRUCTOR and creates the default class), but the file has since changed for that unrelated reason.
• Item #08's scope narrows. The migrated known-LMS-inactive symptom that partly motivated the role-aware redirect is now separately fixed by ASE-1221's status preservation. #08 is now specifically: do not route a valid instructor to the student payment path.
• Item #11 line numbers. The dd($e) calls are at 154 / 176 / 191 at current HEAD (Lti13Service.php was untouched by ASE-1221; the pinned-baseline "175, 190" were correct for c8799473d5a5). The inventory row above has been updated to current HEAD.

Additional touch points from the feasibility review (Report 02)

Small, isolated decisions—not role logic scattered across controllers

These snippets illustrate the intended contracts. They are proposed implementation shapes, not code already present in the backend.

final class ResolveLtiProvisioningRole
{
    public function handle(array $launchData): string
    {
        $roles = Arr::wrap(Arr::get(
            $launchData,
            LtiContextRole::CLAIM,
            []
        ));

        return in_array(LtiContextRole::INSTRUCTOR, $roles, true)
            ? Role::INSTRUCTOR
            : Role::STUDENT;
    }
}

$launchRole = ResolveLtiProvisioningRole::run($launchData);

$roleToApply = $schoolUser
    ->accountUser
    ->roles()
    ->whereIn('name', [
        Role::SUPER_ADMIN,
        Role::DISTRICT_ADMIN,
        Role::INSTRUCTOR,
    ])
    ->exists()
        ? null       // Never demote a protected role.
        : $launchRole; // Student can be promoted to Instructor.

public function handle(
    LtiRegistrationDeployment $deployment,
    array $custom
): School {
    $lmsSchoolId = Arr::get($custom, 'lms_school_id');

    return $deployment
        ->schools()
        ->wherePivot('lms_school_id', $lmsSchoolId)
        ->firstOr(fn () => throw new SchoolNotLinkedToDeployment);
}

final class NormalizeLtiUserIdentifier
{
    public function handle(string $subject): string
    {
        // Phase 1 preserves current Schoology compatibility.
        return Str::of($subject)->before('::')->toString();
    }
}

$launchData = $ltiMessageLaunch->getLaunchData();
$role = ResolveLtiProvisioningRole::run($launchData);

throw_unless(
    $role === Role::INSTRUCTOR,
    new InstructorRoleRequiredForDeepLinking
);

$schoolUser = FindOrCreateUserForLtiContext::run(
    $deployment,
    $launchData
);

Rules that make role mapping safe

An LMS role becomes a SolidProfessor permission boundary. These constraints should be treated as acceptance criteria, not optional polish.

Four decisions required before implementation

The code answers how roles work today, but it cannot decide licensing and permission policy. These decisions are owned and tracked in Report 02 §4 (several are already settled there); they are summarized here for the implementer.

Regression coverage required before rollout

Tests should be written around the role resolver first, then the provisioning and launch flows. Existing Student behavior must remain unchanged.

Current backend sources behind this proposal

Links are pinned to the reviewed commit so the proposal remains auditable if the main branch changes.