Instructor clicks from the LMS
Recognize or create that instructor at launch time using their signed identity, role, school, and course context.
Use LTI just-in-time onboardingLTI can support just-in-time instructor access.
An instructor can select SolidProfessor inside the LMS and enter the platform through the existing LTI integration. The same signed user identifier works for students and instructors; the separate signed role tells us which access to grant. On first use, the backend can create, connect, or promote the instructor. Later launches can recognize and reuse that account.
This is one supported instructor-onboarding option. It does not replace SSO, course roster retrieval, or institution-wide provisioning when those broader capabilities are required.
01 / START HERE
First decide what “support instructors” means
This discovery separates four different outcomes that can sound like the same request. The right integration depends on whether the need is one instructor launching today, one course roster, an existing-account sign-in, or an entire institution provisioned in advance.
Read the course roster
Retrieve the learners and instructors who belong to one LMS course, including their course-level roles.
Use NRPSOnboard a school or district
Synchronize organizations, schools, courses, users, and enrollments before individuals launch.
Use OneRoster, SIS, or LMS admin APIAuthenticate an existing account
Confirm the identity of a person who already has an account. This alone does not bring over courses or rosters.
Use SSO02 / SCOPE
LTI, NRPS, and rostering are related—not interchangeable
NRPS belongs to the LTI Advantage family. It extends an LTI integration with course membership data; it does not provision a complete institution.
SSO
Answers “Who is signing in?”
One person
LTI launch
Sends the current person, context, and role when a tool is launched
One launch
NRPS
Returns the membership and roles for the current course or context
One course
OneRoster / SIS
Synchronizes schools, courses, users, and enrollments across an institution
School or district
Minimum NRPS course-member data
{
"user_id": "stable-lti-user-id",
"roles": [
"http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor"
]
}Privacy and filtering: Names and email addresses are optional. An NRPS request can be filtered to course members with the Instructor role.
03 / IDENTITY
One launch carries four separate facts
An LMS does not need a special instructor identifier. Identity, organization mapping, course context, and role each have their own job.
Who is this?
The signed LTI sub value is the stable identifier and should be matched within its LMS issuer, iss. A custom user_id can help with compatibility and troubleshooting.
Which school?
The custom lms_school_id connects the LMS account or building to the correct SolidProfessor school.
Which course?
The standard LTI context.id identifies the course or other LMS context from which the tool was launched.
What is their role?
The signed LTI roles claim tells us whether the same person is an Instructor, Learner, or another role in this context.
Important: A person can be an instructor in one course and a learner in another. Role is contextual; it should not be inferred from the user ID. Name and email are optional, privacy-dependent claims—not prerequisites for a valid LTI identity.
Common course-level role values
.../membership#Learner
.../membership#Instructor
.../membership#TeachingAssistant04 / PRIVACY
An instructor can launch without sharing an email
The experience can be pseudonymous and LMS-only. It cannot be completely unidentified because SolidProfessor needs a stable value to recognize the same instructor later.
Launch
The instructor opens SolidProfessor from their LMS course.
Verify
SolidProfessor validates the signed LTI message, stable subject, and Instructor role.
Create
An LMS-only instructor record is created without requiring email or password.
Return
Future launches use the same signed subject to reconnect the instructor to their work.
NRPS is not required for this flow. It becomes useful only when we need to read the rest of the course roster before each person launches.
05 / LMS SETUP
The existing custom parameters can cover instructors
Both products substitute the identity of whichever logged-in user launches the tool. The standard signed LTI role should be used instead of adding a custom is_instructor flag.
Canvas
user_id=$Canvas.user.id
lms_school_id=$Canvas.account.idSchoology
user_id=$User.id
lms_school_id=$com.schoology.Context.Building.idSchoology nuance: The building ID is contextual. It can represent the course building, group building, or the user's primary building depending on where the launch occurs.
06 / CURRENT STATE
What SolidProfessor does today
The standards support instructor recognition, but the current backend does not yet turn a new LMS instructor into a SolidProfessor instructor automatically.
School matching uses lms_school_id. The custom value is required to locate the mapped SolidProfessor school.
User matching uses the signed LTI sub. The custom user_id is not the identifier used by the provisioning action.
Existing privileged roles are preserved. A current SolidProfessor instructor, district administrator, or super administrator is not downgraded to Student during the resource-launch path.
The incoming LMS roles claim is not consumed. The application currently recognizes the identity but does not use the course role to authorize a newly provisioned instructor.
Every new resource-launch user is assigned Student. The incoming LMS role is not used to create a new instructor.
Instructor Deep Linking expects an existing account. An unrecognized instructor is redirected to sign in and link their SolidProfessor identity.
NRPS is configured but not consumed. A deployment flag exists, but no roster-fetching or processing implementation was found.
Schoology-style subjects are handled inconsistently. Resource launches trim the identifier at ::, while instructor Deep Linking stores and matches the complete sub. The same user could appear different across the two paths.
07 / EVIDENCE
Primary standards and vendor documentation
The conclusions are grounded in 1EdTech specifications, official Canvas and Schoology documentation, and the current SolidProfessor backend snapshot.
011EdTech LTI 1.3 — Users and Roles
021EdTech LTI 1.3 — User Identity Claims
031EdTech Names and Role Provisioning Services
041EdTech Deep Linking 2.0
05Canvas LTI variable substitutions
06Canvas LTI provisioning guidance
07Schoology LTI apps and Advantage services
08Full research notes and code snapshots