LTI Services on LTI 1x: Difference between revisions
No edit summary |
David Mudrak (talk | contribs) m (Text replacement - "</code>" to "</syntaxhighlight>") |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 17: | Line 17: | ||
== Project goal == | == 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 [https://www.imsglobal.org/lti-advantage-overview]). | 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. | 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. | ||
Line 31: | Line 31: | ||
[[File:mock_moodle_services_11.png|400px]] | [[File:mock_moodle_services_11.png|400px]] | ||
=== Restricted to Site Tools (Tool Type) === | === Restricted to Course and 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. | 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. | ||
[[File:moodle_services11diagram.png|800px]] | [[File:moodle_services11diagram.png|800px]] | ||
== | == 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 == | == Changes to Service Base == | ||
Line 58: | Line 73: | ||
On editing a tool, the current service options would be pre-selected based on the tool type config. | 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 === | === Authorization check === | ||
Line 78: | Line 97: | ||
== A Service can only access a Context where the tool is used == | == A Service can only access a Context where the tool is used == | ||
The Services router will prevent a service to access a context where | 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 == | == Launch Parameters == | ||
Line 87: | Line 108: | ||
Only showing the proposed changes: | Only showing the proposed changes: | ||
< | <syntaxhighlight lang="php">abstract_class service_base { | ||
abstract_class service_base { | |||
/* | /* | ||
* @return an array of options to add to the add/edit external tool | * @return an array of options to add to the add/edit external tool | ||
*/ | */ | ||
get_configuration_options() {} | 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) {} | |||
/* | /* | ||
Line 129: | Line 153: | ||
} | } | ||
</ | </syntaxhighlight> |
Latest revision as of 13:05, 14 July 2021
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) {}
}