Difference between revisions of "LTI-Basic Authentication"

From WeBWorK_wiki
Jump to navigation Jump to search
m
m
Line 1: Line 1:
−
== Under Construction ==
  
   
 
The Learning Tools Interoperability (LTI) protocols provide a means to interface
  
The Learning Tools Interoperability (LTI) protocols provide a means to interface
Line 28: Line 27:
 
If your institution uses an LMS that has support for Basic LTI (i.e., LTI 1.0)
  
If your institution uses an LMS that has support for Basic LTI (i.e., LTI 1.0)
 
and you would like to begin testing how to use it to connect to WeBWorK,
  
and you would like to begin testing how to use it to connect to WeBWorK,
−
then we host a WeBWorK test site to which you may connect.
 +
then we host a WeBWorK test site to which you may connect. Please skip to
  +
to [[Instructions for using LTI Basic to connect to the IU Bloomington WebworkLTIBasic site]].
   
−
=== Instructions for using LTI Basic to connect to the IU Bloomington WebworkLTIBasic site ===
  
  +
== Obtaining, Installing, Configuring, and Using the LTI Authentication package ==
  +
  +
=== Obtaining the LTI Authentication package ===
  +
  +
The package is, at this time, not in the trunk distribution.
  +
Instead, the package may be obtained either from the
  +
SVN [system]/branches/wheeler/webwork2 branch or from
  +
the github http://www.github.com/wheeler/webwork2.
  +
  +
There are six files in the package:
  +
  +
webwork2/lib/global.conf.dist
  +
webwork2/lib/WeBWorK/Authen.pm
  +
webwork2/lib/WeBWorK/Authen/LTIBasic.pm
  +
webwork2/lib/WeBWorK/Authen/Basic_TheLastOption.pm
  +
webwork2/lib/WeBWorK/DB.pm
  +
webwork2/lib/WeBWorK/ContentGenerator/Login.pm
  +
  +
=== Installing the LTI Authentication package ===
  +
  +
First, one must install the Perl module Net::oauth , which is available from CPAN.
  +
Depending on one's installation, one may also have to install several prerequisites
  +
of Net::oauth.
  +
  +
The changes to Authen.pm are significant. They enable Authen
  +
  +
to use an array of authentication hashes so that Authen
  +
can try several authentication methods in sequence, e.g.,
  +
LIT Basic, then an institution's local Central Authentication System, and
  +
then just password authentication (provided by the Basic_TheLastOption.pm module), and
  +
  +
to use either session_cookies or the Key database for session management.
  +
  +
(Heretofore, using the Key database was the only method for session management.
  +
But that requires obtaining a write lock for the Keys table, which can be problematical
  +
under heavy loads.)
  +
  +
The changes to global.conf.dist configure
  +
the LIT Basic environment,
  +
the sequence of Authentication modules to be tried, and
  +
the type of session management.
  +
  +
The LTIBasic.pm module implements the LTI 1.0 authentication protocol.
  +
It is compliant with the IMS specification with one exception.
  +
The exception arises from the incompatibility between the roles
  +
supported by WeBWorK and the roles that may be passed from the
  +
local Course Management System.
  +
  +
  +
The change to DB.pm is a minor change to enable WeBWorK to write "nonces" to the Key database.
  +
  +
The change to Login.pm is to suppress the Remember option for an enduring non-session cookie
  +
if a site is using session cookies rather than the Key database for session management.
  +
  +
=== Configuring the LTI authentication package ===
  +
  +
Configuring the LTI authentication package consists of modifying
  +
an installations global.conf file and the course.conf file
  +
of each site that will use LTI authentication.
  +
  +
The new LTI parameters have been grouped together at the bottom
  +
of the global.conf.dist file.
  +
  +
One should copy all of this section to the end of one's global.conf file.
  +
Then one should go through the section and select/set appropriate
  +
values for the parameters.
  +
  +
Two of the parameters must be set in each site's course.conf file.
  +
These parameters are
  +
  +
#$LTIBasicToThisSiteURL = "URL to site", e.g.,
  +
$LTIBasicToThisSiteURL = "https://localserver/webwork2/DemoCourse";
  +
  +
and
  +
  +
#$LTIBasicConsumerSecret = "Consumer Secret - shared with the Course Management Site", e.g.,
  +
$LTIBasicConsumerSecret = "webworkLTIB";
  +
  +
=== Using the LTI Authentication package ===
  +
  +
According to the IMS LTI 1.0 specifications, when a user authenticates via LTI
  +
from a Learning Management System (LMS) (e.g., Sakai, Moodle, and Blackboard)
  +
to a Learning Tool (LT) (e.g., WeBWorK), the Learning Tool is supposed to accept
  +
as valid all of the information that the Learning Management System passes to it.
  +
This includes demographic data, e.g., name, email address; custom information,
  +
e.g., section; and, most importantly, role information, e.g., student, guest, TA,
  +
librarian, teacher, administrator. If the user has not previously registered
  +
with the Learning Tool, then the Tool is supposed to accept the authentication
  +
from the Learning Management System as authorization to register the
  +
user with the Learning Tool with the role passed from the Learning Management System
  +
to the Learning Tool.
  +
  +
But this can cause significant problems if the roles passed by the Learning
  +
Management System are coarser than the roles used by the Learning Tool.
  +
For example, the default implementation of LTI in the Sakai LMS passes
  +
only two roles, "student" and "teacher" regardless of the roles that
  +
the Sakai LMS uses internally. Accordingly, the Sakai roles of
  +
visitor, guest, and student are all collapsed in the LTI to just the role
  +
of student. The Sakai roles of TA, Librarian, Assistant, Teacher, and
  +
(System) Administrator are all collapsed to the single role of teacher.
  +
This is obviously unsatisfactory for WeBWorK. For instance, at Indiana University,
  +
many more than 100 and perhaps as many as 200 of the staff of the University
  +
Information Technology Service across the eight campuses throughout the state
  +
have Administrator privileges in the University's Sakai LMS, some of whom
  +
are students who help staff Help Desks. If the LTI specification were followed
  +
strictly, then all of these staff members would have Teacher privileges
  +
in all of the WeBWorK sites. This is untenable.
  +
  +
Accordingly, the LTIBasic module proceeds as follows:
  +
  +
If a previously unknown
  +
user authenticates via LTI, that person is assigned a role of "student"
  +
in WeBWorK and of the information transmitted with the authentication,
  +
e.g., first name, last name, username, id, email address, etc., is used
  +
to set the corresponding data fields in WeBWorK.
  +
  +
If a known user who has a WeBWorK role of student or less authenticates
  +
via LTI, then the accompanying demographic information, e.g., first name, last name,
  +
id, email address (but not username) is compared to the existing
  +
WeBWorK data, and if there are any discrepancies, then the new data
  +
replaces the old data.
  +
  +
If a known user who has a WeBWorK role greater than that of a student
  +
authenticates via LTI, then the accompanying demographic information
  +
is ignored.
  +
  +
Consequently, it is imperative that users who are to have WeBWorK roles
  +
higher than that of students, e.g., proctors, TA's, instructors, etc.,
  +
must be installed by the existing WeBWorK facilities. Ideally,
  +
this should happen before the individual first authenticates
  +
via LTI. But if a privileged user, e.g., a TA, does happen
  +
to authenticate via LTI before having been added via WeBWorK facilities,
  +
then the WeBWorK facilities for modifying users should be used
  +
to fix the user's permission, section, and other data.
  +
  +
  +
In addition, hen a wnew user first authenticates to WeBWorK via LTI, the LTIBasic
  +
module will, in addition to adding the user as a student, will
  +
(attempt to) assign versions of all existing sets (both visible
  +
and invisible, both homework and tests/quizzes) to the new user.
  +
Furthermore, if the configuration variable
  +
  +
$adjustDueDatesForLateAdds = "1";
  +
  +
then LTIBasic will compute the number of assigned
  +
problems in all of the closed sets, i.e., those whose due dates
  +
have passes, will divide that total by the value of the
  +
configuration variable
  +
  +
$reasonableProblemsPerDayMakeup = 15;
  +
  +
and extend all of the expired due dates by that
  +
number of days.
  +
  +
In practice, this is usually OK. But if any
  +
of the expired assignments were tests or quizzes,
  +
then this automatic extension may be unsatisfactory.
  +
The instructor should monitor the dates
  +
that are assigned to students who add the course
  +
after the first quiz or test.
  +
  +
  +
----
  +
  +
  +
== Instructions for using LTI Basic to connect to the IU Bloomington WebworkLTIBasic site ==
   
 
Configure the LMS's LTI Basic tool with the following parameters:
  
Configure the LMS's LTI Basic tool with the following parameters:
Line 128: Line 292:
 
With Safari and Chrome, the default WeBWorK display mode is "formatted
  
With Safari and Chrome, the default WeBWorK display mode is "formatted
 
text". (We'll be changing that this summer.)
  
text". (We'll be changing that this summer.)
  +
  +
----
   
 
=== Please send problem reports to wheeler@indiana.edu ===
  
=== Please send problem reports to wheeler@indiana.edu ===

Revision as of 17:29, 29 May 2012

The Learning Tools Interoperability (LTI) protocols provide a means to interface a Learning Tool, e.g., WeBWorK, with a Learning Management System (LMS), e.g., Angel, Blackboard, Canvas, Moodle, and Sakai. The LTI protocols are defined by the IMS Global Learning Consortium (Learning Tools Interoperability home page).

Basic LTI (i.e., LTI 1.0) provides a protocol for authenticating from an LMS to a Learning Tool (LT) and passing information such as names, email addresses, and roles (e.g., Instructor, Learner) from the LMS to the LT. Basic LTI is roughly comparable to the initial Moodle-WeBWorK integration at the University of Rochester. Basic LTI is presently supported by most LMS's (see the table at the bottom of the page [http://www.imsglobal.org/cc/statuschart.cfm IMS Interoperability Conformance Certification Status]).

LTI 1.1 (full LTI) will (eventually) provide additional protocols for returning data from a LT to the LMS.

The WeBWorK group at Indiana University Bloomington began developing an LTI-Basic package for WeBWorK in the summer of 2011. We have used LTI-Basic for authentication from the Sakai LMS to WeBWorK since September, 2011. The perl module WeBWorK::Authen::LTIBasic and instructions for additions and modifications to other WeBWorK modules and configuration files will be posted on the MAA WeBWorK site by the end of May.

If your institution uses an LMS that has support for Basic LTI (i.e., LTI 1.0) and you would like to begin testing how to use it to connect to WeBWorK, then we host a WeBWorK test site to which you may connect. Please skip to to Instructions for using LTI Basic to connect to the IU Bloomington WebworkLTIBasic site.

Obtaining, Installing, Configuring, and Using the LTI Authentication package

Obtaining the LTI Authentication package

The package is, at this time, not in the trunk distribution. Instead, the package may be obtained either from the SVN [system]/branches/wheeler/webwork2 branch or from the github http://www.github.com/wheeler/webwork2.

There are six files in the package: 

 webwork2/lib/global.conf.dist
 webwork2/lib/WeBWorK/Authen.pm
 webwork2/lib/WeBWorK/Authen/LTIBasic.pm
 webwork2/lib/WeBWorK/Authen/Basic_TheLastOption.pm
 webwork2/lib/WeBWorK/DB.pm
 webwork2/lib/WeBWorK/ContentGenerator/Login.pm

Installing the LTI Authentication package

First, one must install the Perl module Net::oauth , which is available from CPAN. Depending on one's installation, one may also have to install several prerequisites of Net::oauth.

The changes to Authen.pm are significant. They enable Authen 

 to use an array of authentication hashes so that Authen
 can try several authentication methods in sequence, e.g.,
 LIT Basic, then an institution's local Central Authentication System, and
 then just password authentication (provided by the Basic_TheLastOption.pm module), and

 to use either session_cookies or the Key database for session management.

(Heretofore, using the Key database was the only method for session management. But that requires obtaining a write lock for the Keys table, which can be problematical under heavy loads.)

The changes to global.conf.dist configure 

 the LIT Basic environment,
 the sequence of Authentication modules to be tried, and
 the type of session management.

The LTIBasic.pm module implements the LTI 1.0 authentication protocol. It is compliant with the IMS specification with one exception. The exception arises from the incompatibility between the roles supported by WeBWorK and the roles that may be passed from the local Course Management System.


The change to DB.pm is a minor change to enable WeBWorK to write "nonces" to the Key database.

The change to Login.pm is to suppress the Remember option for an enduring non-session cookie if a site is using session cookies rather than the Key database for session management.

Configuring the LTI authentication package

Configuring the LTI authentication package consists of modifying an installations global.conf file and the course.conf file of each site that will use LTI authentication.

The new LTI parameters have been grouped together at the bottom of the global.conf.dist file.

One should copy all of this section to the end of one's global.conf file. Then one should go through the section and select/set appropriate values for the parameters.

Two of the parameters must be set in each site's course.conf file. These parameters are 

 #$LTIBasicToThisSiteURL = "URL to site", e.g.,
 $LTIBasicToThisSiteURL = "https://localserver/webwork2/DemoCourse";

and 

 #$LTIBasicConsumerSecret = "Consumer Secret - shared with the Course Management Site", e.g.,
 $LTIBasicConsumerSecret = "webworkLTIB";

Using the LTI Authentication package

According to the IMS LTI 1.0 specifications, when a user authenticates via LTI from a Learning Management System (LMS) (e.g., Sakai, Moodle, and Blackboard) to a Learning Tool (LT) (e.g., WeBWorK), the Learning Tool is supposed to accept as valid all of the information that the Learning Management System passes to it. This includes demographic data, e.g., name, email address; custom information, e.g., section; and, most importantly, role information, e.g., student, guest, TA, librarian, teacher, administrator. If the user has not previously registered with the Learning Tool, then the Tool is supposed to accept the authentication from the Learning Management System as authorization to register the user with the Learning Tool with the role passed from the Learning Management System to the Learning Tool.

But this can cause significant problems if the roles passed by the Learning Management System are coarser than the roles used by the Learning Tool. For example, the default implementation of LTI in the Sakai LMS passes only two roles, "student" and "teacher" regardless of the roles that the Sakai LMS uses internally. Accordingly, the Sakai roles of visitor, guest, and student are all collapsed in the LTI to just the role of student. The Sakai roles of TA, Librarian, Assistant, Teacher, and (System) Administrator are all collapsed to the single role of teacher. This is obviously unsatisfactory for WeBWorK. For instance, at Indiana University, many more than 100 and perhaps as many as 200 of the staff of the University Information Technology Service across the eight campuses throughout the state have Administrator privileges in the University's Sakai LMS, some of whom are students who help staff Help Desks. If the LTI specification were followed strictly, then all of these staff members would have Teacher privileges in all of the WeBWorK sites. This is untenable.

Accordingly, the LTIBasic module proceeds as follows: 

 If a previously unknown
 user authenticates via LTI, that person is assigned a role of "student"
 in WeBWorK and of the information transmitted with the authentication,
 e.g., first name, last name, username, id, email address, etc., is used
 to set the corresponding data fields in WeBWorK.  

 If a known user who has a WeBWorK role of student or less authenticates
 via LTI, then the accompanying demographic information, e.g., first name, last name,
 id, email address (but not username) is compared to the existing
 WeBWorK data, and if there are any discrepancies, then the new data
 replaces the old data.

 If a known user who has a WeBWorK role greater than that of a student
 authenticates via LTI, then the accompanying demographic information
 is ignored.

Consequently, it is imperative that users who are to have WeBWorK roles higher than that of students, e.g., proctors, TA's, instructors, etc., must be installed by the existing WeBWorK facilities. Ideally, this should happen before the individual first authenticates via LTI. But if a privileged user, e.g., a TA, does happen to authenticate via LTI before having been added via WeBWorK facilities, then the WeBWorK facilities for modifying users should be used to fix the user's permission, section, and other data.


In addition, hen a wnew user first authenticates to WeBWorK via LTI, the LTIBasic module will, in addition to adding the user as a student, will (attempt to) assign versions of all existing sets (both visible and invisible, both homework and tests/quizzes) to the new user. Furthermore, if the configuration variable 

 $adjustDueDatesForLateAdds = "1";

then LTIBasic will compute the number of assigned problems in all of the closed sets, i.e., those whose due dates have passes, will divide that total by the value of the configuration variable 

 $reasonableProblemsPerDayMakeup = 15;

and extend all of the expired due dates by that number of days.

In practice, this is usually OK. But if any of the expired assignments were tests or quizzes, then this automatic extension may be unsatisfactory. The instructor should monitor the dates that are assigned to students who add the course after the first quiz or test.



Instructions for using LTI Basic to connect to the IU Bloomington WebworkLTIBasic site

Configure the LMS's LTI Basic tool with the following parameters: 

 Domain/URL:  https://estudy11.iu.edu:8082/~estudy11/webwork2/WebworkLTIBasic

 Consumer key:  webwork

 Shared Secret:  webworkLTIB

Also, the LTI Basic tool must send a username and/or an email address, in the form: 

 lis_person_sourcedid=username
 lis_person_contact_email_primary=username@school.edu

(lis_person_sourceid and lis_person_contact_email_primary are part of the LTI specification, so it should be possible fo the LTI Basic interface to send them, but some instances of LTI Basic interfaces (e.g., Canvas) require some tweaking.)

The WeBWorK::Authen::LTIBasic module will use the value of the lis_person_sourceid parameter as the WeBWorK username if it is present. If the lis_person_sourceid parameter is undefined, then the module will use the value of the lis_person_contact_email_primary parameter as the WeBWorK username.

On the first occasion on which a user authenticates to a WeBWorK site using LTIBasic, the WeBWorK::Authen::LTIBasic module will create the user record for the user and assign the user versions of all of the existing WeBWorK problem sets. For purposes of security, the user will be assigned a permission value of 0, regardless of the user's LMS role. This permission can subsequently be increased using the standard WeBWorK tools.

If one can use the LMS's LTI Basic tool in a debug mode that will show the parameters it is sending, then one can compare them to the following parameters that Sakai/Oncourse sends: 

 BasicLTI Endpoint
 https://estudy11.iu.edu:8082/~estudy11/webwork2/WebworkLTIBasic

 BasicLTI Parameters:
 user_id=wheeler
 lis_person_name_full=William H. Wheeler
 context_id=a75a6608-3698-4b62-803d-063040fce113
 context_title=Math Tools Pages
 oauth_signature=cDU1GfReli3QDeprOJwWv23ukq0=
 oauth_nonce=468921706075144
 lti_message_type=basic-lti-launch-request
 resource_link_description=Linking to WeBWorK@IU
 resource_link_id=109f9125-c711-4151-8601-4567518aed82
 ext_sakai_serverid=esoncprd11
 roles=Instructor
 oauth_signature_method=HMAC-SHA1
 oauth_callback=about:blank
 lis_person_name_family=Wheeler
 lis_person_contact_email_primary=wheeler@indiana.edu
 context_label=Math Tools Pages
 basiclti_submit=Press to continue to external tool.
 lis_person_sourcedid=wheeler
 launch_presentation_locale=en_US
 ext_sakai_server=https://resources.oncourse.iu.edu
 ext_sakai_session=5757ec78346099f129bb771043d0d1d5134b16de4692e8a05332f7c7e79be50c24039d7b92e774cb
 oauth_timestamp=1331327382
 lis_person_name_given=William H.
 lti_version=LTI-1p0
 oauth_version=1.0
 oauth_consumer_key=webwork
 resource_link_title=WeBWorK LTI

Alternatively, in order to find out what parameters one's LTI Basic tool is sending, one may change the URL to 

 https://estudy14.iu.edu:8082/~estudy14/oauthTest2.pl

One should get back a message that Oauth verification either succeeded or failed and then a list of the parameters that LTI Basic tool sent.

If the Oauth verification succeeded but one cannot connect to the WebworkLTIBasic site, then one should check whether the LTI Basic tool is sending the lis_person_sourcedid parameter and/or the lis_person_contact_email_primary parameter.

Note: Use Firefox 3.5 or later for the WebworkLTIBasic site

We use MathML for mathematics provided that the browser is Firefox 3.5 or later.

Internet Explorer will fail on our WeBWorK problems, because we use a mime type of XHTML + XML + SVG for WeBWorK problems.

With Safari and Chrome, the default WeBWorK display mode is "formatted text". (We'll be changing that this summer.)

Please send problem reports to wheeler@indiana.edu

Retrieved from "https://webwork.maa.org/mediawiki_new/index.php?title=LTI-Basic_Authentication&oldid=13341"