LTI Services on LTI 1x: Difference between revisions
No edit summary |
No edit summary |
||
Line 17: | Line 17: | ||
== Project goal == | == Project goal == | ||
LTI | 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 [https://www.imsglobal.org/lti-advantage-overview]). | ||
For example, the membership service allows a Tool to discover a course roster, while the Gradebook Services ([https://github.com/IMSGlobal/LTI-spec-Gradebook-Services]) 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 == | == Changes to Manual Tool configuration == | ||
Line 35: | Line 37: | ||
[[File:moodle_services11diagram.png|800px]] | [[File:moodle_services11diagram.png|800px]] | ||
=== | === Tool Id in service URL === | ||
Since Tool Consumer Key are not guaranteed to be unique, the Service base URL will need to be modified to embed the LTI Tool Type Id in the request. | |||
== Changes to Service Base == | == Changes to Service Base == | ||
Line 111: | Line 107: | ||
this->permission_config_key = null; | this->permission_config_key = null; | ||
} | } | ||
get_endpoint() { | |||
// modified to include the current mod_lti id in the request | |||
} | |||
/* | /* |
Revision as of 17:46, 14 November 2017
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 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.
Tool Id in service URL
Since Tool Consumer Key are not guaranteed to be unique, the Service base URL will need to be modified to embed the LTI Tool Type Id in the request.
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_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) {}
}