Implement LTI 1.3 dynamic registration with the LMS. #2798
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements the specification detailed at https://www.imsglobal.org/spec/lti-dr/v1p0.
To use this the LMS administrator enters the URL
https://your.webwork2.server.edu/webwork2/ltiadvantage/registration
. That automatically adds the LTI 1.3 configuration for the webwork2 server to the LMS. Then the LMS administrator just needs to activate the tool.On the webwork2 side of things the LTI 1.3 configuration for the LMS will be saved into a file in the directory
webwork/DATA/LTIRegistrationRequests
. The file will be named$lmsName-XXXX.conf
where$lmsName
is whatever the tool reported in theproduct_family_code
subkey of thehttps://purl.imsglobal.org/spec/lti-platform-configuration
key in the configuration webwork2 obtains from the LMS andXXXX
is whatevertempfile
fills in to ensure the file is unique. Note that theproduct_family_code
is "moodle", "canvas", etc. Unfortunately, there isn't really a unique identifier that can be used here in the information sent from the LMS, so not much better can be done for the file name.The webwork2 system administrator then needs to copy and paste the contents of that file into either the
conf/authen_LTI_1_3.conf
file for site wide setup, or into all of the appropriatecourse.conf
files for course specific setup. Note that depending on the LMS the data in the file may not be complete. The specification essentially states that it is optional for the LMS to sent this value. Moodle sends thedeployment_id
in the returned configuration, but Canvas does not. Of course I don't know what D2L or Blackboard will do. In this case the generated will contain'obtain from LMS administrator
' for the$LTI{v1p3}{DeploymentID}
. So for Canvas, at least, the webwork2 administrator will still need to communicate with the LMS administrator to obtain thedeployment_id
. Eventually, a user interface in the admin course could perhaps be implemented for dealing with these configurations in a nicer way than cutting a pasting from this file that is created. However, that most likely will require a change in how the LTI configurations are saved. The config file approach is a limiting factor in this.Also, there may be additional configuration that the LMS administrator needs (or may want) to do, and how the tool is presented in the LMS when editing it may be different than how it was previously with the manual configuration approach.
For Moodle the tool that is automatically created needs to be activated (a click of a button does this), but furthermore, the administrator will probably want to edit the configuration and set the "Tool configuration usage" to "Show in activity chooser and as preconfigured tool" (it is set to "Show as preconfigured tool when adding an external tool" by default), and set "Default launch container" to "New Window" (it is set to "Embed, without blocks" by default). Also, the way the tool is presented when editing it is indistinguishable from a tool created using the manual configuration approach. This means that all aspects of the tool can be edited as before.
For Canvas even before the tool is created in the LMS there are some options that can be configured although usually they should be left with the defaults. The only things that can be changed are if certain things in the configuration from webwork2 are enabled or not. For example, placements in the configuration from webwork2 can not be added, but can only be disabled. Also, the way the tool is presented when editing it is quite different from a manually configured tool. None of the URLs can be edited, and the things that were in the configuration from webwork can only be disabled again.
Of course, it remains to be seen what D2L or Blackboard do with this.
Note that there is a little more that can be added to this. Before the tool is added to the LMS, webwork2 could present a page that allows the LMS administrator to select options for the tool. For example, the current tool name will be "WeBWorK at your.webwork2.server.edu", but that could be allowed to be changed by the LMS administrator. Note that for Moodle that can be changed later anyway, but Canvas does not provide a way to change the tool name. Also, it may be desirable to allow the administrator to determine if grade passback is allowed or not. Although, for both Moodle and Canvas this can still be done in any case.
Note that LTI 1.1 does support something like this, but I haven't found any documentation on it (although I haven't looked to hard).