LTI Security Update

Learning Tools Interoperability Security Update

IMS Final Release
Version 1.0
IMS Final Release
Date Issued: 22 July 2019
Status: This document is made available for adoption by the public community at large.
This version: https://www.imsglobal.org/spec/lti/security-update/v1p0/

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright © 2019 IMS Global Learning Consortium. All Rights Reserved.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/speclicense.html.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.

Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources.

© 2019 IMS Global Learning Consortium, Inc. All Rights Reserved.

Trademark information: http://www.imsglobal.org/copyright.html

Abstract

This document provides a security update to address cross-site request forgery threats applicable to versions of LTI released prior to v1.3. The security updates described here apply specifically to LTI v1.0 and v1.1.1. This solution may also be applied to other versions of LTI (1.2 and 2.0) but are not directly addressed here as IMS encourages implementors to adopt the latest version (1.3) as soon as possible.

LTI Security Update: LTI Launch with Authentication Flow Representing New Security Requirements for LTI v1.0.1 and LTI v1.1.2

  1. Introduction

The purpose of this document is to address a login cross-site request forgery (CSRF) threat that has been identified to IMS.

  1.1 Documentation

The following LTI v1.3 and LTI Advantage related specification documents are available:

  • IMS Security Framework Version 1.0 [SEC-10] specification
  • LTI Core Version 1.3 [LTI-13] specification
  • Deep Linking Version 2.0 [LTI-DL-20] specification
  • Names and Role Provisioning Services Version 2.0 [LTI-NRPS-20] specification
  • Assignment and Grade Services Version 2.0 [LTI-AGS-20] specification
  • LTI Advantage Implementation Guide [LTI-IMPL-13] specification

This security update, already accounted for in the LTI Advantage specifications, applies specifically to these earlier versions of LTI:

  1.2 Conformance Certification Options

  • Conformance certification testing for this security update as LTI v1.0.1 and v1.1.2 is available to IMS members.

  2. LTI 1.1.2 Launch Flow Overview

Launch Flow Overview

In this flow, each LTI message request is treated as an authentication request, which triggers an implicit flow between the Tool Provider (TP) and the Tool Consumer (TC).

Identity information will only be sent to a TP once an XSRF token has been exchanged (see tool_state). The initial launch is therefore anonymous, and must not contain any user identity information, including user_id. It contains the relaunch_url which will allow the TP to pass the token (tool_state) back to the TC to re-initiate a full launch, now containing user identity.

The first stage of the launch will always be made anonymously, and will carry extra parameters to let a TP complete the workflow to find out which user the LTI launch is for.

The following stages of the workflow permit the TP to handshake with the TC to agree on who the user is. This results in a full, user-included, LTI launch payload being sent to the TP.

  3. LTI Launch Authorization Flow

  3.1 Step 1: Anonymous Resource Request

When a user wants to launch into a TP, the TC will start the resource request flow by redirecting the UA to the 3rd party initiated login endpoint. Standard LTI parameters may be sent excluding any user information such as user_id, roles, lis_person_name_given and lis_person_contact_email_primary. This should include at a minimum lti_message_type (the value should match the value in the ultimate launch), lti_version, and the necessary oauth signature values.

If the TP accepts anonymous launches, the TP may choose to not continue the workflow beyond this point and instead fulfill the LTI request as it normally would.

This launch should be signed with a OAuth consumer key and secret. Personally identifiable information must not be sent while other attributes such as roles is acceptable.

The redirect is a Form POST

Parameter Description Note
relaunch_url required, is the place where the TP comes to in case it needs to settle who the user is and request the full launch data This will indicate to the tool that it may get an LTI launch with user information by triggering a relaunch.
platform_state required, a TC generated opaque string identifying the lti message to launch. For example it may be the resource link id when the message is a resource link request. A TC may use the browser context to know which lti launch to do, for example by attaching state to the launcher iframe.

  3.2 Step 2: Relaunch Request

The TP must then perform an authentication request

The TP sets the XSRF token and binds it to a tool_state parameter, and redirects to the relaunch_url or sends a POST to the relaunch_url (does not need to be signed) with the following parameters:

Parameter Description Note
tool_state required, opaque value for the TC to maintain state between the request and callback and provide Cross-Site Request Forgery (CSRF, XSRF) mitigation. State needed by the tool to correlate an LTI launch request with the original tool-originated relaunch request.
platform_state required to be included if present in the initial anonymous launch. State needed by the TC to verify the user prompting the launch workflow, and correlate the tool-originate relaunch request with the proper relaunch response.

All platforms must handle either an unsigned GET or a POST - the tool gets to make this choice. The tool can sign the request using the OAuth consumer key and secret if it so chooses but the platform is not required to check for the signature nor reject invalid signatures.

  3.3 Step 3: Relaunch Response

Once the TC has validated the current logged in user matches the request, and the platform_state is valid for that user, the TC can construct the LTI launch including user information such as user_id, roles, lis_person_name_given and lis_person_contact_email_primary.

The authentication response is sent to the TP’s LTI launch url with the following additional parameters:

Parameter Description Note
tool_state required State needed by the TP to correlate an LTI launch request with the original TP originated relaunch request.

  3.4 Step 4: LTI Resource is Displayed

The TP, after decoding and validating the LTI launch and verifying the tool_state matches the current state attached to the browser session, will display the LTI resource.

  3.4.1 Authentication Error Response

Should be consistent with error messaging in LTI 1.1/2 and 2.0, for example, getting a Launch request that has a bad signature.

  4. Implementation Guidelines

  4.1 Use State to Pass Information in the Flow

This avoids for example to have to store additional state into the tool application state by including, in addition to a proper XSRF token, additional data for processing the request when the authentication response is received. For example, the state (TP or TC) can be a signed or encrypted JWT.

Annex Other documents where this was discussed and led to this proposal:

Original issue reported: https://github.com/IMSGlobal/security-framework/issues/52

  A. References

  A.1 Informative references

[BLTI-10]
IMS Global Basic Learning Tools Interoperability v1.0. C. Severance. IMS Global Learning Consortium. May 2010. IMS Final Release. URL: https://www.imsglobal.org/lti/
[LTI-11]
IMS Global Learning Tools Interoperability® Implementation Guide. G. McFall; M. McKell; L. Neumann; C. Severance. IMS Global Learning Consortium. March 13, 2012. URL: https://www.imsglobal.org/specs/ltiv1p1
[LTI-13]
IMS Global Learning Tools Interoperability® Core Specification v1.3. C. Vervoort; N. Mills. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/
[LTI-AGS-20]
IMS Global Learning Tools Interoperability® Assignment and Grade Services. C. Vervoort; E. Preston; M. McKell; J. Rissler. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti-ags/v2p0/
[LTI-DL-20]
IMS Global Learning Tools Interoperability® Deep Linking 2.0. C. Vervoort; E. Preston. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti-dl/v2p0/
[LTI-IMPL-13]
IMS Global Learning Tools Interoperability® Advantage Implementation Guide. C. Vervoort; J. Rissler; M. McKell. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/impl/
[LTI-NRPS-20]
IMS Global Learning Tools Interoperability® Names and Role Provisioning Services. C. Vervoort; E. Preston; J. Rissler. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti-nrps/v2p0/
[SEC-10]
IMS Global Security Framework v1.0. C. Smythe; C. Vervoort; M. McKell; N. Mills. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/security/v1p0/

IMS Global Learning Consortium, Inc. ("IMS Global") is publishing the information contained in this document ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS Global makes no warranty or representation regarding the accuracy or completeness of the Specification.

This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS Global would appreciate receiving your comments and suggestions.

Please contact IMS Global through our website at http://www.imsglobal.org.

Please refer to Document Name: Learning Tools Interoperability Security Update 1.0

Date: 22 July 2019