Standard LMS Integration (LTI)

Outlining Webassessor integration with a Learning Management System (LMS) using IMS LTI 1.3, including sign-in, adding exams to a course (Deep Linking) and returning grades (Assignment and Grade Services).

Unlike SAML and OIDC, which sign a user in to Webassessor from an identity provider, LTI lets a student or instructor open Webassessor from inside an LMS course. The LMS has already authenticated the user, and tells Webassessor who they are and what course activity they opened. LTI is offered by Kryterion, Inc. alongside SAML, OIDC.

LTI has two parties:

• Platform: Always the Client's LMS (for example Moodle).

• Tool: Always Webassessor (the Webassessor SSO Service).

What is supported

Pre-requisites

• The client must have an LTI 1.3 compliant LMS and an LMS administrator able to register an external tool.

• The client must be created in the Webassessor system as an entity and region with a brand, and the region must be Active. A launch for an inactive region is rejected.

• Kryterion must create an LTI configuration for the client's region (Step 3).

• The LMS must send the user's email claim for existing users to be matched, and email, given_name and family_name for new users to be created (see "How Webassessor identifies the user").

• The LMS and Webassessor clocks should be synchronized. Webassessor accepts a clock difference of up to 5 minutes on the launch token.

Integration Points and Flows

1. Login initiation. The LMS sends the browser to the Webassessor login initiation URL (Step 2) with iss, login_hint, target_link_uri and client_id (and optionally lti_message_hint and lti_deployment_id). If any required value is missing, or no configuration matches the issuer and client ID, the user is sent to the Webassessor login page.

2. Webassessor stores a single-use state and nonce server-side for 10 minutes (not in a browser session cookie, so the flow works inside an LMS iframe) and redirects the browser to the LMS authorization endpoint (scope=openid, response_type=id_token, response_mode=form_post, prompt=none).

3. Launch. The LMS posts a signed id_token and the state back to the Webassessor launch URL.

4. Webassessor validates the token in this order, and stops at the first failure: well-formed JWT; signature against the LMS JWKS (with a refetch if the LMS has rotated keys); issuer; audience; azp when the audience has several values; subject; expiry and issued-at; nonce present, matching and not reused; message type; LTI version 1.3.x; deployment ID present and registered; deployment ID matching the one sent at login (when one was sent); roles present; for a resource link launch the resource_link claim with an id; for a Deep Linking launch the deep_linking_settings claim and a valid return URL; target_link_uri matching the one sent at login. Any failure sends the user to the Webassessor login page and no session is created.

5. Webassessor resolves the Webassessor user, optionally creating one (JIT), and signs them in, or for a Deep Linking launch shows the exam picker.

Implementation Steps

Step 1: Client provides the LMS platform details

Kryterion needs the following from the client's LMS. These are registered in the client's LTI configuration.

Step 2: Client registers Webassessor as an external tool in the LMS

Give the LMS administrator the following Webassessor values.

1. Login initiation URL

   1. Sandbox: https://sb01.webassessor.com/SsoService/lti/login

   2. Production: https://www.webassessor.com/SsoService/lti/login

2. Redirect / launch URL (the LMS posts the launch token here)

   1. Sandbox: https://sb01.webassessor.com/SsoService/lti/launch

   2. Production: https://www.webassessor.com/SsoService/lti/launch

3. Public keyset (JWKS) URL (the LMS uses it to verify Webassessor's signed messages)

   1. Sandbox: https://sb01.webassessor.com/SsoService/lti/jwks

   2. Production: https://www.webassessor.com/SsoService/lti/jwks

4. Tool URL / target link URL: the launch URL above.

5. Deep Linking (if the client wants instructors to add exams from inside a course): enable Deep Linking on the tool, using the same launch URL as the content-selection URL.

6. Services / scopes (for grade passback), if the LMS asks which to grant:

   1. https://purl.imsglobal.org/spec/lti-ags/scope/score

   2. https://purl.imsglobal.org/spec/lti-ags/scope/lineitem

   3. https://purl.imsglobal.org/spec/lti-ags/scope/lineitem.readonly

7. User data to share: name and email of the user (the claims email, given_name, family_name), the user's roles, and custom parameters where used (see "Adding an exam to a course").

Webassessor's public keys (RS256) are served at the JWKS URL; give the LMS that URL rather than a copy of the key. Webassessor creates the signing key itself.

Step 3: Kryterion creates the LTI configuration

Kryterion Support configures the client's region in the Webassessor admin application (SSO details for the client region, type LTI) using the Step 1 values.

Step 4: Instructors add Webassessor activities in the LMS

Once the tool is registered, an instructor adds Webassessor to a course either as a generic Webassessor link, or by choosing a specific exam through Deep Linking (see below).

How Webassessor identifies the user

For a resource link launch, Webassessor resolves the Webassessor account in this order:

1. By LMS identity. Webassessor remembers the combination (LTI configuration, deployment ID, sub) from a previous launch. If it is known, that account is used.

2. By login. The email claim, trimmed and in lowercase, is looked up as a Webassessor login in the client's region.

3. By email. The same value is looked up as the email address of a Webassessor user in the client's region. If more than one user in the region has that email address, it is treated as no match.

4. By JIT provisioning, if nothing matched (see below).

Steps 2 and 3 need an email claim. After a successful launch, Webassessor records the (configuration, deployment ID, sub) combination against the account.

An inactive account is not signed in and the user is shown the "not authorized" page.

Student launch (resource link)

• New candidate UI regions: the student is handed off to the new candidate UI through a one-time credential and arrives at the candidate pages.

• Legacy candidate UI regions: the student is signed in with a login cookie and sent to the Landing Page configured on the LTI configuration (Home, Registration or Assessments).

• If the launch carries exam routing (see "Adding an exam to a course"), the student is sent to the new candidate UI so the routing can be applied, even in a region that otherwise uses the legacy UI.

• LTI launches use the candidate sign-in hand-off only; there is no administrator sign-in through LTI. Administrators sign in to Webassessor with SAML, OIDC or a Webassessor password.

Roles

Webassessor classifies the LTI roles claim into one role, accepting the membership, institution and system role vocabularies:

If several roles are present, Administrator wins, then Instructor, then Learner. Role classification is used for Deep Linking access and for JIT provisioning. It does not otherwise change how a launch resolves the user.

Just-in-time (JIT) provisioning

JIT creates a Webassessor candidate account automatically the first time a student launches, when no existing account matches.

JIT happens only when all of the following are true:

• JIT Provisioning is Yes on the LTI configuration.

• The region uses the new candidate UI. JIT is not available for legacy UI regions.

• The token's roles classify as Learner. Instructors, administrators and unknown roles are not created.

• The token has an email claim.

What is created:

• A candidate with status Active in the client's region, with the login set to a generated unique value, the email address from the email claim (trimmed, lowercase), and first and last name from given_name and family_name (blank if absent).

• A candidate record and a random placeholder password. Students never sign in to Webassessor with a password through LTI.

• No address or custom field data, because an LTI token does not carry it. The candidate application is responsible for asking the student to complete their profile.

If the email address is already used by another user in the region, the account is not created.

JIT rejection outcomes (the student is sent to the login page with an error):

Adding an exam to a course

An exam can be tied to an LMS activity in two ways.

Deep Linking (instructor picks the exam)

1. In the LMS, the instructor chooses to add content from Webassessor. The LMS sends a LtiDeepLinkingRequest to the launch URL.

2. Only an Instructor or Administrator (by the role classification above) may continue. Anyone else is sent to the login page.

3. The LMS request must include deep_linking_settings with deep_link_return_url, accept_types and accept_presentation_document_targets. The return URL must be http or https and its host must match the registered platform issuer's host.

4. Webassessor shows a picker page listing the exams that are Active in the client's region, have at least one allowed delivery type, and are currently open for registration. Each exam has a delivery type choice.

5. Delivery types not offered through LTI: Proctored, Paper Based, and Event Proctored. Types shown to instructors are labelled Not Proctored, Online Proctored (OLP), Web Proctored (Legacy), AI First and AI Record Review.

6. The instructor picks one exam and one delivery type. Webassessor revalidates the choice and returns a signed response to the LMS (valid for 5 minutes) containing a single resource link content item: the Webassessor launch URL, titled with the exam name, with the custom parameters wa_product_id and wa_delivery_type. Webassessor returns exactly one content item per selection, regardless of whether the LMS allows several. If the LMS sent a data value, it is returned unchanged.

7. The picker session is single-use and expires after 10 minutes.

Custom parameters (administrator sets them on the link)

An LMS administrator or instructor can set the custom parameters on the activity link by hand. When a student launches:

Both are required together. Webassessor then routes the student as follows:

1. The exam must exist, be Active, and belong to the client's region.

2. If the student already has a registration for that exam and delivery type that is not cancelled and not completed, the student is taken straight to launch it. (Registrations on hold or in progress are still treated as existing.)

3. Otherwise the delivery type must be allowed for LTI and the exam must be open for registration; the student is taken to register and schedule that exam and delivery type.

4. If any check fails, or a parameter is missing or invalid, the student goes to the normal landing page instead. The launch itself still succeeds.

A link with no custom parameters is a generic link and takes the student to the landing page.

Grade passback (Assignment and Grade Services)

When the LMS includes the AGS endpoint with at least one granted scope and a resource link ID, Webassessor records the grading information for that student and activity at launch. When the student's exam is graded, Webassessor posts the result to the LMS gradebook.

• When: Webassessor sends the result when the exam is scored (and, for manually scored exams, when scoring is completed).

• What: userId (the LMS sub), scoreGiven, scoreMaximum, activityProgress and gradingProgress. The score and maximum are the transcript's score and maximum score, for point, percentage and scaled scoring alike.

• Which gradebook column: Webassessor uses the column the student launched from: first a column already linked to that registration, then a link created for the same exam and delivery type (newest launch), then a generic link without an exam (newest launch). If the registration is linked to columns in several courses, the score is posted to each.

• Line item: if the LMS did not provide a single line item at launch, Webassessor queries the LMS line items for the resource link and, if none exists and the lineitem scope was granted, creates one (label from the activity title, otherwise "WA Assessment"; maximum score from the result, or 100 when not known).

• Scopes: the score scope must have been granted at launch. lineitem or lineitem.readonly is needed to look up a line item. lineitem is needed to create one.

• How Webassessor authenticates to the LMS: it requests an access token from the Auth Token URL using a signed client assertion (private_key_jwt), verified by the LMS against the Webassessor JWKS URL.

• Grade passback is best-effort. If posting fails, the exam result is not affected.

Launch error outcomes

If a launch cannot be validated, the user is sent to the Webassessor login page and no session is created. Webassessor logs a specific reason for each of these; the user does not see it.

A student with a valid launch but no account, an inactive account, or a JIT rejection is sent to the login page or "not authorized" page with an error, as described above.

Logout

LTI sessions are logged out locally in Webassessor only. Webassessor does not call back to the LMS and there is no identity provider session to end.

Access to certain features is restricted based on role type in an effort to reduce item exposure and promote process integrity. Please see the member role description page for information on permissions.