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

LTI Ecosystem is enriched by services. For example, the membership service allows a Tool to discover a course roster, while the Gradebook Services ([1]) offers a more flexible integration with the gradebook. Services as specifications have no dependencies on LTI 2.0 Tool Proxy i.e. they can be used directly with manual deployments. However the current implementation in Moodle mandates a Tool Proxy deployment in order for a Tool to be able to leverage LTI services. 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 Site Tools (Tool Type)

Access to services are proposed to be limited to Site tools; External Tools added by the instructor will not offer those options. Security options will be stored in mod_lti_types_config like other tool type settings.

Uniqueness of Tool Consumer Key

Tool Consumer Key are required to be unique in a given Moodle install so that when service calls are made, the caller can be properly identified.

When a Tool Consumer Key is not unique:

• A warning will be displayed by the side of the Consumer Key (not unique)
• Service groups will be disabled
• It will not be possible to save a tool which has a duplicate Consumer key

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.

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 is not at least one activity (link) deployed to it. To validate access, the check_authorization will be passed the context id by the service.

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 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 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) {}

}