LMS User Identities and Conflicts¶
When a learner or instructor launches from an LMS, NETLAB+ has to decide which NETLAB+ account they are. It does so with LMS identities: records that tie the identifier the LMS sends for a person to a NETLAB+ account. An account has one identity in effect per LTI version; the records of earlier and pending claims on that slot are kept alongside it. This page explains how identities are created, what a conflict is, and how an instructor or administrator resolves one.
How a Launch Finds an Account¶
Every LTI launch carries an identifier for the person launching, assigned by the LMS, together with their name and email address. On each launch NETLAB+ looks for an identity that matches the identifier under that LTI version:
A match is found. The launch signs in to that account.
No match, but an account in the community has the same email address and has launched from an LMS before. For a student account, the launch binds the identifier to that account and signs in. For an instructor or administrator account the binding is never made automatically; see Approval for privileged accounts.
No match, and the account with that email address has never launched from an LMS. The launch is refused. An account created directly in NETLAB+, by an administrator or an import, cannot be claimed by a launch, whatever its type. The learner sees “this NETLAB+ account was not created by an LMS launch and cannot be claimed by one”. The person can sign in to NETLAB+ directly with the account’s password. If they should instead work through the LMS, an administrator changes the local account’s email address, or removes the account, so that the next launch creates one.
No match and no account. NETLAB+ creates an account for the person, binds the identifier to it, and signs in. The account is a student account unless the LMS says the person is an instructor or administrator in the course, in which case an instructor account is created.
The identifier an LMS sends for a person can change. The common cases are a migration of the LMS itself, a person being re-created in the LMS, and the move from LTI 1.1 to LTI 1.3: Canvas, for example, sends a different identifier for the same person under 1.3, so every existing user’s first 1.3 launch arrives with an identifier NETLAB+ has never seen. Because identities are tracked per version, a student’s first 1.3 launch finds the account by email address and binds the new identifier without disturbing the 1.1 one. An instructor’s first 1.3 launch is instead held for approval and refused until an administrator approves it, as described below; expect this from every instructor on the day their LMS moves to 1.3.
Conflicts¶
A conflict arises when a launch arrives with a new identifier for an account that already holds an identity under the same LTI version. Only one identifier can hold the slot. NETLAB+ knows which identifier arrived first and what each launch asserted, but it does not know which person is entitled to the account, so it records the newcomer as Awaiting Decision and leaves the choice to a person.
What happens to the account in the meantime depends on how the existing identity reached it:
The existing identity reached the account on a matching email address alone. It may not belong to the person who holds the account. Launches under that version are refused for both identifiers until someone decides, the account’s password is reset, and any session the account holder has open is ended.
The existing identity did not rely on email alone. NETLAB+ created the account for it, or a person approved it. Nothing about the account changes: it continues to work, its password stands, and only the new identifier is refused until someone decides.
Only student accounts can be bound automatically. A student launch can therefore never lock an instructor or administrator out of their account.
While a decision is waiting, a launch that arrives with yet another identifier for the same account is refused and logged, but not recorded, so the page never shows more than the identity in effect and the one claimant awaiting a decision.
The account’s page shows an LTI Conflict button while a
decision is waiting, and an LTI Identities button otherwise.
Resolving a Conflict¶
An instructor can resolve conflicts on the accounts of students in classes they lead; an administrator can resolve any. The subject of the identity never decides their own case.
Warning
The name and email shown for each identity are claims made by each launch, not proof. Names change legitimately, and a matching email address is the very thing in dispute. Confirm out of band which person is entitled to the account before choosing.
Login to NETLAB+ as the administrator, or as an instructor who leads the student’s class.
Open the account. As the administrator, click >
Accounts, find the user, and click their row. As an instructor, open
the class roster and select the student.
Click LTI Conflict. The Resolve LTI Identity
page opens, headed LMS Associations and the user’s name, with one
section per LTI version that has identities.
Read the explanation at the top of the section; it says which of the
two situations above applies. Compare the identities listed, and read
Launch Detail below the table, which shows the LMS identifier, LMS,
class and exercise that the active identity and each identity awaiting a
decision launched with. Denied and revoked identities have no detail shown.
For an LTI 1.1 launch from Moodle the LMS identifier shown is a value NETLAB+
derives from the Moodle site and user, not the user ID a Moodle administrator
sees.
In the Correct column, select the identity that belongs to
the person who holds the account, or None of these, and click
Resolve. Confirm in the dialog, which lists what will be in
effect and what will be denied.
Field Descriptions
- Correct:
The choice. The selected identity becomes the one in effect; every other identity listed is denied.
- Status:
Active, the identity in effect; Awaiting Decision, an identity waiting to be approved or denied; Denied, an identifier refused on sight; Revoked, a formerly active identity set aside by a later decision.
- Name and Email:
What the launch asserted about the person. Claims, not proof.
- First Seen and Last Launch:
When the identifier was first recorded and when it last launched successfully.
- Decided By:
The person who made the decision that put this identity in its current state, or None when it was bound automatically.
- None of these:
Refuses nobody and empties the slot. Every identity that is in effect or waiting is set aside, and the next launch under this version claims the account first come first served, or, for an instructor or administrator account, is held for approval. Use it when there is no way to tell, and expect the same conflict to arrive again.
Note
A denied identifier is refused on sight and cannot claim the account by launching again. It stays listed, and someone with authority over the account can reverse the denial later by choosing it on this page. That is also how a decision made in error is corrected.
Approval for Privileged Accounts¶
When a launch arrives whose identifier is unknown and whose email address matches an instructor or administrator account that has launched from an LMS before, NETLAB+ does not bind it automatically. The identity is recorded as Awaiting Decision, nothing about the account changes, and the page shows: “An LMS identifier is asking to use this account and nothing currently holds it.” The learner sees “this LMS identity must be approved before it can use a NETLAB+ instructor or administrator account”. An instructor account that has never launched from an LMS is refused outright instead, as described under How a Launch Finds an Account.
Open the account and click LTI Conflict.
Approve the identity only if you can confirm out of band that the
identifier belongs to the person who holds the account, then click
Resolve.
Until it is approved, launches with that identifier are refused. The person can still sign in to NETLAB+ directly with their password.
Reviewing Settled Identities¶
An account that has at least one LMS identity and no conflict waiting shows an
LTI Identities button; an account that has never launched
from an LMS shows neither button. The same page opens, and the section for each
version begins “Nothing is waiting on a decision for this LTI version.” The identity in effect is marked
Active and the rest is the record of how it got there.
The identity in effect can still be changed here: choosing a different row makes that one the association and denies the current one.
What the Learner Sees¶
A launch refused for reasons of identity shows one of the following messages under the heading “LTI Failed to Launch”. Each ends by asking the learner to contact their instructor or the NETLAB+ administrator, and includes a reference code that identifies the identity record for support purposes. The resolve page does not display the code, so locate the account by the learner’s name or email address. The code is the start of the identity’s full ID, which the NETLAB+ log records on the “Refusing” line written for the launch, so a quoted code can be matched there when two people each claim to be the account’s owner.
- this LMS identity cannot be matched to a single NETLAB+ account:
A conflict is waiting on the account, and this identifier is one of the two in dispute. Resolve it as described under Resolving a Conflict.
- this NETLAB+ account was not created by an LMS launch and cannot be claimed by one:
An account with the learner’s email address exists but has never launched from an LMS. See How a Launch Finds an Account.
- this LMS identity must be approved before it can use a NETLAB+ instructor or administrator account:
The identifier is waiting for approval. See Approval for Privileged Accounts.
- this LMS identity has been refused access to the matching NETLAB+ account:
The identifier was denied by a decision on the resolve page. Someone with authority over the account can reverse it there.