LTI Services on LTI 1x

LTI Services on LTI 1x
Project state	Planning
Tracker issue	MDL-60416
Discussion	LTI Services available for manually configured tools
Assignee	Claude Vervoort

LTI Services on LTI 1x
Project state	Planning
Tracker issue	MDL-60416
Discussion	LTI Services available for manually configured tools
Assignee	Claude Vervoort

Project goal

With the retirement of LTI 2.0 and the LTI Advantage push, it becomes essential for the LTI module to expose services for LTI 1.1 deployments (see [1]).

For example, the membership service allows a Tool to discover a course roster, while the Gradebook Services ([2]) offers a more flexible integration with the gradebook. However the current implementation in Moodle mandates a Tool Proxy deployment in order for a Tool to be able to leverage LTI services, which is now deprecated. This is a significant barrier to adoption; this project proposes to lift it by allowing Tools to be granted access to services as part of the manual deployment of the Tool.

Changes to Manual Tool configuration

New Services option group

Tool manual configuration will contain a Services section, allowing the administrator to grant access to the services either fully, read-only or no access. This will be similar to the enabled capabilities found in the Tool Proxy.

A proposed option would be to create a Services section in the Configuration page, as illustrated by this mock:

Restricted to Course and Site Tools (Tool Type)

Access to services are proposed to be limited to Course and Site tools as they require a mod_lti_type record; External Tools added by the instructor will not offer those options. Security options (which authorization are granted to the tool) will be stored in mod_lti_types_config like other tool type settings.

Identify the tool on service requests

=== URL needs to uniquely identify the Tool Type making the service call

Unfortunately the consumer key was never guaranteed to uniquely identify a tool deployment and can thus not be used uniquely to identify a caller on the service API. It will therefore fall on the lapse of the service to embed that information on every service URL passed on launch.

For example, a service may:

• embed the tool type id directly in the URL passed on launch
• infer the tool type from other parts of the request: for example, a grade is attached to a grade item itself attached mod_lti itself attached to an mod_lti_type

In any case, the service will pass the tool type id making the request to the security method.

Changes to membership service

Memberships service template URL will be modified to embed tool type id and remove any reference to LTI 2.0 constructs (tool, vendor codes).

Memberships will also be modified to use the new authorization services added under this project.

Changes to Service Base

The Service (service_base.php) contract will be extended with:

Configuration Options

get_configuration_option will return a configuration option to be used to populate the Services section in the Add/Edit external page (see example above). One service may expose multiple configuration options. Configuration options are for now solely aimed at enabling or disabling all or parts of the services, although they may be used to capture other configuration options would that become needed.

Each configuration option is described as: name, value, extra help, array of options (name, value) in the order they should be presented. A Not Allowed option must be exposed as the 1st option.

See security below for the actual values that would allow to leverage the automatic security check done by the service_base.

On Save, the choices will be added as tool type config, one entry per option; The config entry will be: services_{option_value} = {selected option value}.

Option is single select. Not selecting an option is the same as denying access to the service altogether (see security section).

On editing a tool, the current service options would be pre-selected based on the tool type config.

Basic Outcome Replacement

Basic Outcome is a service directly embedded in the core of LTI. It may be replaced by another Grade Service (see https://docs.moodle.org/dev/LTI_Gradebook_Services). A service will have the ability to mention it replaces the basic outcome, so that lis_result_sourcedid and lis_outcome_service_url are not included in the launch parameters.

Authorization check

Access to services will be limited based on the rights granted to the Tool. The service code must then assess the rights to perform an operation based on the tool configuration. The service infrastructure will have an helper method to assert an access right granting a proper format for authorization was used as the config value:

• options are comma-separated list of permissions
  • each permission is the id for the resource, and the HTTP action (lower case)
  • example, services_lineitem = LineItem.item:get, LineItem.item:put, LineItem.collection:post, LineItem.collection:get. This is similar to LTI 2.0 capabilities.
• resource definition has a permission key identifying the config key to use to check access for the resource
• resource_base check_authorization(lti_type, context_id, body) method is used to assert access authorization
  • the body is used to validate the signature (oauth_body_hash)
  • the context_id is used to assert the tool is indeed engaged in the course (there is at least one lti link to it)
  • will use the resource id and the request method to build the permission to check
  • for example, if access a resource with id: LineItem.item and doing a get, the permission will be LineItem.item:get
  • will check the permission is in the list for based on the value found for that config key
  • will call the current tool proxy method if no authorization is found in config and a tool proxy exists
  • service_base will throw a 401 exception if authorization is not granted (seems better than returning a 0)

A Service can only access a Context where the tool is used

The Services router will prevent a service to access a context where:

• If a Course Tool, the tool must be defined for that context
• If a Site Tool, default check will be that at least one mod_lti entry exists for that tool and context. To validate access, the check_authorization will be passed the context id by the service. This behavior may be overridden on a per service bases.

Launch Parameters

Each service may expose additional parameters, usually actual end points to access the actual resource (like a Score URL to post new scores, or a membership URL to get the course roster). A new Service base method is added, somewhat similar to parse_values, but returning an array of key/value pairs to be added as parameters to the launch based on the tool configuration.

Summary of API changes

Only showing the proposed changes:

abstract_class service_base {

   /*
   * @return an array of options to add to the add/edit external tool
    */
   get_configuration_options() {}

   /*
   * @return true if this services replaces the basic outcome service in the context of that tool. Default is false.
    */
   is_gradebook_service($lti_type) {}

   /*
   * @return an array of key/value pairs to add as launch parameters; type is passed to check the configuration
   * and not return parameters for services not used
    */
   get_launch_parameters($messagetype, $course, $user, $lti_type, $mod_lti = null) {}

}

abstract_class resource_base {

   public function __construct($service) {
       this->permission_config_key = null;
   }

  get_endpoint() {
    // modified to include the current mod_lti id in the request
  }

   /*
    * get permissions from the config of the tool for that resource
    */
   get_permissions($lti_type) {}

   /*
    * @throw 401 is access is not authorized (wrong signature, tool not used in context, ...)
    */
   check_authorization($lti_type, $context_id, $body = null) {}

   /*
    * @return an array of key/value pairs to add as launch parameters; type is passed to check the configuration
    * and not return parameters for services not used
    */
   get_launch_parameters($messagetype, $course, $user, $lti_type, $mod_lti = null) {}

}