Implement LTI 1.3 dynamaic registration with the LMS.

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 the `product_family_code` subkey of the
`https://purl.imsglobal.org/spec/lti-platform-configuration` key in the
configuration webwork2 obtains from the LMS and `XXXX` is whatever
`tempfile` fills in to ensure the file is unique.  Note that the
`product_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 appropriate `course.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 the
`deployment_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 the `deployment_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).

Author: drgrice1

lib/WeBWorK/ContentGenerator/LTIAdvantage.pm

@@ -1,11 +1,12 @@
 package WeBWorK::ContentGenerator::LTIAdvantage;
-use Mojo::Base 'WeBWorK::ContentGenerator', -signatures;
+use Mojo::Base 'WeBWorK::ContentGenerator', -signatures, -async_await;
 
 use Mojo::UserAgent;
 use Mojo::JSON           qw(decode_json);
 use Crypt::JWT           qw(decode_jwt encode_jwt);
 use Math::Random::Secure qw(irand);
 use Digest::SHA          qw(sha256_hex);
+use Mojo::File           qw(tempfile);
 
 use WeBWorK::Debug qw(debug);
 use WeBWorK::Authen::LTIAdvantage::SubmitGrade;
@@ -425,4 +426,120 @@ sub purge_expired_lti_data ($c, $ce, $db) {
 	return;
 }
 
+async sub registration ($c) {
+	return $c->render(json => { error => 'invalid configuration request' }, status => 400)
+		unless defined $c->req->param('openid_configuration') && defined $c->req->param('registration_token');
+
+	# If we want to allow options in the configuration such as whether grade passback is enabled or to allow the LMS
+	# administrator to choose a tool name, then this should render a form that the LMS will be presented in an iframe
+	# allowing the LMS administrator to select the options. When that form is submitted, then the code below should be
+	# executed taking those options into consideration.  However, at this point this is a simplistic approach that will
+	# work in most cases.
+
+	$c->render_later;
+
+	my $configurationResult = (await Mojo::UserAgent->new->get_p($c->req->param('openid_configuration')))->result;
+	return $c->render(json => { error => 'unabled to obtain openid configuration' }, status => 400)
+		unless $configurationResult->is_success;
+	my $lmsConfiguration = $configurationResult->json;
+
+	return $c->render(json => { error => 'invalid openid configuration received' }, status => 400)
+		unless defined $lmsConfiguration->{registration_endpoint}
+		&& defined $lmsConfiguration->{issuer}
+		&& defined $lmsConfiguration->{jwks_uri}
+		&& defined $lmsConfiguration->{token_endpoint}
+		&& defined $lmsConfiguration->{authorization_endpoint}
+		&& defined $lmsConfiguration->{'https://purl.imsglobal.org/spec/lti-platform-configuration'}
+		{product_family_code};
+
+	# FIXME: This should also probably check that the token_endpoint_auth_method is private_key_jwt, the
+	# id_token_signing_alg_values_supported is RS256, and that the scopes_supported is an array and contains all of the
+	# scopes listed below. There are perhaps some other configuration values that should be checked as well.  However,
+	# most of the time these are all going to be fine.
+
+	my $rootURL = $c->url_for('root')->to_abs;
+
+	my $registrationResult = (await Mojo::UserAgent->new->post_p(
+		$lmsConfiguration->{registration_endpoint},
+		{
+			Authorization  => 'Bearer ' . $c->req->param('registration_token'),
+			'Content-Type' => 'application/json'
+		},
+		json => {
+			application_type           => 'web',
+			response_types             => ['id_token'],
+			grant_types                => [ 'implicit', 'client_credentials' ],
+			client_name                => 'WeBWorK at ' . $rootURL->host_port,
+			client_uri                 => $rootURL->to_string,
+			initiate_login_uri         => $c->url_for('ltiadvantage_login')->to_abs->to_string,
+			redirect_uris              => [ $c->url_for('ltiadvantage_launch')->to_abs->to_string ],
+			jwks_uri                   => $c->url_for('ltiadvantage_keys')->to_abs->to_string,
+			token_endpoint_auth_method => 'private_key_jwt',
+			scope                      => join(' ',
+				'https://purl.imsglobal.org/spec/lti-ags/scope/lineitem',
+				'https://purl.imsglobal.org/spec/lti-ags/scope/lineitem.readonly',
+				'https://purl.imsglobal.org/spec/lti-ags/scope/result.readonly',
+				'https://purl.imsglobal.org/spec/lti-ags/scope/score'),
+			'https://purl.imsglobal.org/spec/lti-tool-configuration' => {
+				domain          => $rootURL->host_port,
+				target_link_uri => $rootURL->to_string,
+				claims          => [ 'iss', 'sub', 'name', 'given_name', 'family_name', 'email' ],
+				messages        => [ {
+					type            => 'LtiDeepLinkingRequest',
+					target_link_uri => $c->url_for('ltiadvantage_content_selection')->to_abs->to_string,
+					# Placements are specific to the LMS.  The following placements are needed for Canavas, and Moodle
+					# completely ignores this parameter. Does D2L need any? What about Blackboard?
+					placements => [ 'assignment_selection', 'course_assignments_menu' ]
+				} ]
+			}
+		}
+	))->result;
+	unless ($registrationResult->is_success) {
+		$c->log->error('Invalid regististration response: ' . $registrationResult->message);
+		return $c->render(json => { error => 'invalid registration response' }, status => 400);
+	}
+	return $c->render(json => { error => 'invalid registration received' }, status => 400)
+		unless defined $registrationResult->json->{client_id};
+
+	my $configuration = <<~ "END_CONFIG";
+	\$LTI{v1p3}{PlatformID}      = '$lmsConfiguration->{issuer}';
+	\$LTI{v1p3}{ClientID}        = '${\($registrationResult->json->{client_id})}';
+	\$LTI{v1p3}{DeploymentID}    = '${
+		\($registrationResult->json->{'https://purl.imsglobal.org/spec/lti-tool-configuration'}{deployment_id}
+		// 'obtain from LMS administrator')
+	}';
+	\$LTI{v1p3}{PublicKeysetURL} = '$lmsConfiguration->{jwks_uri}';
+	\$LTI{v1p3}{AccessTokenURL}  = '$lmsConfiguration->{token_endpoint}';
+	\$LTI{v1p3}{AccessTokenAUD}  = '${
+		\($lmsConfiguration->{authorization_server}
+		// $lmsConfiguration->{token_endpoint})
+	}';
+	\$LTI{v1p3}{AuthReqURL}      = '$lmsConfiguration->{authorization_endpoint}';
+	END_CONFIG
+
+	my $registrationDir = Mojo::File->new($c->ce->{webworkDirs}{DATA})->child('LTIRegistrationRequests');
+	if (!-d $registrationDir) {
+		eval { $registrationDir->make_path };
+		if ($@) {
+			$c->log->error("Failed to create directory for saving LTI registrations: $@");
+			return $c->render(json => { error => 'internal server error' }, status => 400);
+		}
+	}
+
+	my $registrationFile = tempfile(
+		TEMPLATE =>
+			$lmsConfiguration->{'https://purl.imsglobal.org/spec/lti-platform-configuration'}{product_family_code}
+			. '-XXXX',
+		DIR    => $registrationDir,
+		SUFFIX => '.conf',
+		UNLINK => 0
+	);
+	$registrationFile->spew($configuration, 'UTF-8');
+
+	# This tells the LMS that registration is complete and it can close its dialog.
+	return $c->render(data => '<script>'
+			. q!(window.opener || window.parent).postMessage({ subject: 'org.imsglobal.lti.close' }, '*');!
+			. '</script>');
+}
+
 1;

lib/WeBWorK/Utils/Routes.pm

@@ -23,6 +23,7 @@ PLEASE FOR THE LOVE OF GOD UPDATE THIS IF YOU CHANGE THE ROUTES BELOW!!!
  ltiadvantage_launch                 /ltiadvantage/launch
  ltiadvantage_keys                   /ltiadvantage/keys
  ltiadvantage_content_selection      /ltiadvantage/content_selection
+ ltiadvantage_registration           /ltiadvantage/registration
 
  saml2_acs                           /saml2/acs
  saml2_metadata                      /saml2/metadata
@@ -147,6 +148,7 @@ my %routeParameters = (
 			ltiadvantage_launch
 			ltiadvantage_keys
 			ltiadvantage_content_selection
+			ltiadvantage_registration
 			saml2_acs
 			saml2_metadata
 			saml2_error
@@ -217,6 +219,12 @@ my %routeParameters = (
 		path   => '/ltiadvantage/content_selection',
 		action => 'content_selection'
 	},
+	ltiadvantage_registration => {
+		title  => x('LTI 1.3 Registration'),
+		module => 'LTIAdvantage',
+		path   => '/ltiadvantage/registration',
+		action => 'registration'
+	},
 
 	# This route also ends up at the login screen on failure, and the title is not used anywhere else.
 	saml2_acs => {