Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

LTI 2 support

From MoodleDocs
LTI 2 support
Project state Implemented
Tracker issue MDL-45843
Discussion Adding LTI 2.0 support
Assignee Stephen Vickers

Project goals

The main goal of this project is to implement LTI 2.0 functionality for Moodle which is capable of passing the IMS certification tests. It is not expected that the required changes will have any significant impact on the current LTI 1.1 functionality; indeed it is hoped that the work will also have some beneficial side-effects for the current LTI implementation.

Background

Vital Source Technologies recognises the benefits that the IMS Learning Tools Interoperability (LTI) 2 specification can deliver to tool providers and has, therefore, agreed to sponsor this project in the interests of the whole community. The work will be undertaken in collaboration with Moodlerooms as an adaptation of the existing LTI (External tool) module which they manage on behalf of the Moodle community.

Introduction

Moodle already provides support for LTI 1.1, this project will build on this support to add support for LTI 2.0; it will not remove any existing functionality but it is expected that the LTI 1 support will also be enhanced as a consequence of this work. The main differences between LTI 1.1 and LTI 2.0 are as follows:

Tool registration
Rather than passing a launch URL, consumer key and shared secret from the tool provider to the tool consumer using some out-of-band communication, LTI 2 uses an interactive registration process; all a tool consumer administrator needs is the URL for initiating this process.
Tool Consumer Profile
as part of the registration process, a tool consumer makes available to the tool provider a profile describing itself and the capabilities/services it is willing to make available.
Tool Proxy
when "sealing the deal" between the two parties, the tool provider sends a Tool Proxy to the tool consumer which includes a profile about itself and details of the capabilities/services which it proposes to use. A tool Proxy can be used to register more than one tool (resource handler), all of which are secured using the consumer key and shared secret agreed by the two systems during this process.
Launch process
whilst the mechanics of launching an LTI tool remain unchanged from LTI 1, the tool proxy allows the data passed on launch to be tailored to specific requirements. The custom parameter substitution variables (available in LTI 1 but not implemented in the current Moodle implementation) are used to enable this functionality.
Tool Settings service
LTI 2.0 includes a service which allows a tool provider to request a tool consumer to record data (name and value pairs) which are passed back on each launch. Settings may be saved at one of three levels: system-wide (Tool Proxy level), context-wide (Tool Proxy binding level, e.g. course-wide) and resource specific (LTI link level, i.e. specific to an individual link added to a course). This service is helpful as it ensures settings are deleted when a link or course is deleted, and it can also help when a course containing links to a tool provider is copied.
Discoverable services
the addition of the tool consumer and tool profiles allows each party to declare services which it is willing to offer the other party. These services may be ones included in the IMS LTI specification (e.g. Tool Settings), but may equally be ones written by other parties which have yet to become part of the specification (and perhaps never will). Provided both the tool consumer and tool provider have implemented the service, the trust relationship established using LTI can be leveraged to secure the request messages between the servers. This transforms an LTI tool consumer into an extensible platform for learning tools and resources.

Current issues with existing LTI functionality

There are a number of open Moodle Tracker items relating to enhancements to the LTI implementation. Whilst this project is not directly concerned with resolving these issues, it does provide an opportunity to review them and see how they might guide the decisions being taken so they are consistent and may indeed provide solutions as a byproduct. Here is a list of those identified so far (some are from discussion postings or other sources):

  1. Add support for multi-tenancy sites to permit different LTI credentials for courses in different sites
  2. MDL-37041: The LTI consumer does not pass the user's profile picture in the user_image launch parameter
  3. MDL-37445: Add ability to set Maximum Grade for External Tool
  4. MDL-38120: course reports for external tool misssing
  5. MDL-39134: Create an LTI filter
  6. MDL-41202: LTI course identifier is not configurable; relies on shortname exclusively
  7. MDL-41724 (Fixed, as of Moodle 3.0): Implement the IMS LTI contexts membership service
  8. MDL-45064 (Fixed, as of Moodle 3.1): Option to add LTI Tool to Activity Chooser
  9. Visibility of external tools in the activity choose
  10. Support for both activity and resource types
  11. passing the Username?
  12. More flexibility with passing appropriate roles
  13. Support for success and log messages on return URL

If you know of any missing from this list then please add a comment or get in touch; no promises that it will get included!

User interface changes

It is anticipated that the LTI 2 functionality can be added on top of the existing LTI 1.1 support with minimal impact on the current user interface. This section describes the current proposals for the new registration workflows.

Plugin settings page (existing)

  1. Move the "Add external tool configuration" link outside the "Active" tab and place below the tool list (may need to go above to save scrolling when the list of tools is long)
  2. Add a new link labelled something like "Register new external tool" which can be used to initiate the tool registration process
  3. Add a new tab set to list enabled and disabled services with icon to toggle their current status (by default a new service would be disabled)

See also "Registration process" section below.

Register new external tool page (new)

New page allowing the following data entry:

registration URL
simple text box
select capabilities to be offered to the tool provider
textarea of selected capabilities, textarea of potential capabilities, buttons to add and remove capabilities from selection
select services to be made available for use by the tool provider
textarea of selected services, textarea of potential services, buttons to add and remove services from selection
option to initiate the registration process
button
option to cancel the process
button

Initiating the registration would generate a random key and secret and redirect the administrator to the tool provider using a ToolProxyRegistrationRequest message. The next part of the process is dependent upon the implementation by the tool provider based on their business rules. It would, however, depend upon the provision of a Tool Consumer Profile service; the profile provided would be based on the capabilities and services selected on this page (i.e. would be specific to a registration request). On completion the tool provider will call the Tool Proxy service.

Registration process

Once initiated a Tool Proxy registration will have one of the following states:

  1. created
  2. in process
  3. completed
  4. rejected
  5. cancelled

A rejected or cancelled registration would be logged but not remain visible in the UI. A new tab would be required on the Plugin settings page for any "in process" registrations (initiated but not yet completed by the creation of a tool proxy). An icon would be included next to each link to cancel a registration. A completed registration will generate a tool proxy associated with each of the tools (resource handlers) it specifies (which would be added to the "Pending" tab on the Plugin settings page).

Managing tools

Once a Tool Proxy has been accepted its resource handlers will be added as if they were external tools created manually using the current LTI 1 process. Their initial state will be pending; an administrator must enable them to make them available. They will appear to instructors (and learners) just like an LTI 1 external tool - there is no need for them to see any difference. The only difference will be behind the scenes when a launch request is made, the launch parameters will be determined on the basis of the resource handler definition from the tool proxy rather than being a generic LTI 1 launch. Support would also be added for custom parameter substitution variables which could/would also be available to LTI 1 launches.

Database changes

It is anticipated that the addition of LTI 2 support will require the following database changes:

  • new table to capture details of tool proxies
  • new fields to lti_types table to record:
    • foreign key for tool proxy
    • enabled capabilities
    • launch parameters
    • icon and secureicon URLs
  • new table to record tool settings

lti_tool_proxies table

Field name Type Description
id int(10) Primary key
regurl text Registration URL
state tinyint(2) Current state of tool proxy processing
guid varchar(255) Consumer key
secret varchar(255) Shared secret
capabilityoffered text Capabilities offered to Tool Provider
serviceoffered text Services offered to Tool Provider
toolproxy text Copy of agreed Tool Proxy (JSON)
createdby int(10) ID of user which initiated the registration process
timecreated int(10) Date/time at which the record was created
timemodified int(10) Date/time at which the record was last modified

lti_types table

Field name Type Description
toolproxyid int(10) Primary key of related tool proxy (null for LTI 1 tools)
enabledcapability text Enabled capabilities (null for LTI 1 tools)
parameter text Launch parameters (null for LTI 1 tools)
icon text URL to icon file
secureicon text Secure URL to icon file

lti_tool_settings

Field name Type Description
id int(10) Primary key
toolproxyid int(10) Primary key of related tool proxy
course int(10) Primary key of course (null for system-wide settings)
coursemoduleid int(10) Primary key of course module - tool link added to course (null for system-wide and context-wide settings)
name varchar(255) Setting name
value varchar(255) Setting value

Defining services

The goal is to enable the list of available services to be extensible, this includes the Tool Consumer Profile, Tool Proxy and Tool Settings services which are required elements of LTI 2.0. A service is an endpoint to which requests may be sent; these requests send or receive resources of a specified media type.

Service definitions

  • Properties:
    • ID - unique ID for service
    • Name - a display name for service
    • IsEnabled - whether the service is currently enabled
    • Resources - list of media types associated with the service
    • Endpoint - URL for service requests
  • Methods:
    • ParseValue - parse a custom parameter value for substitution variables defined by the service and/or its resources
    • CheckSignature - check the OAuth signature for a request received

Resource definitions

  • Properties:
    • ID - unique ID for resource
    • Template - URL template for service requests
    • Media types - list of supported media types
    • Methods - supported HTTP methods
    • Capabilities - names of available capabilities
    • Parameters - values of parameters included in request template
  • Methods:
    • Endpoint - fully qualified URL
    • ParseValue - parse a custom parameter value for substitution variables defined by the resource

Installing services

The initial approach will be to try to implement the above requirements using the existing LTI Source Plugins functionality.

Tasks

  • registration page
  • defining services
  • tool consumer profile service
  • tool proxy service
  • tool settings service
  • enable/disable tools
  • generate launch request (including custom parameter substitution variables)