Today I upgraded our server to 2.12 and began exploring integrating with Brightspace (formerly D2L). I followed Geoff's blog post (http://webworkgoehle.blogspot.com/2016/03/webwork-lti-authentication.html) and uncommented the line
include("conf/authen_LTI.conf");
from localOverrides.conf. Then I realized no one could log into our courses. The login screens gave a message about logging in through the LMS. Is it possible to run your server in such a way so that some courses go through the LMS, but others are accessed in the usual way? Is it just that this line needs to be added in only the course.conf files for those courses which will be managed through the LMS?
And a related question, do I infer correctly that you can't have a course up that will be accessed both ways? That is, can I have a course where students access it through the LMS, but as a back up they can just go directly to the course address and log in the old fashioned way?
Hi Alex,
You can have it both ways. Just change
$external_auth =1;
which forces external auth, to
$external_auth = 0;
LTI will still be in the loop, but it won't redirect when it gets to the last option (local auth).
Also, if LTI creates your users then they'll need to change their passwords in webwork before they can access webwork outside of the LMS. LTI just makes the passwords random since it can't know their university passwords.
(Come to think of it, you might be able to have LTI failover to LDAP which fails over to local auth if you want, but I'm guessing you want LTI failover to local auth.)
If on the other hand you create the users first, make sure that their userid that you create matches the userid that the LTI auth wants (probably email address unless you specifically change it in the conf file).
Jason
You can have it both ways. Just change
$external_auth =1;
which forces external auth, to
$external_auth = 0;
LTI will still be in the loop, but it won't redirect when it gets to the last option (local auth).
Also, if LTI creates your users then they'll need to change their passwords in webwork before they can access webwork outside of the LMS. LTI just makes the passwords random since it can't know their university passwords.
(Come to think of it, you might be able to have LTI failover to LDAP which fails over to local auth if you want, but I'm guessing you want LTI failover to local auth.)
If on the other hand you create the users first, make sure that their userid that you create matches the userid that the LTI auth wants (probably email address unless you specifically change it in the conf file).
Jason
Re: " Is it just that this line needs to be added in only the course.conf files for those courses which will be managed through the LMS?"
I believe the answer is yes. See http://webwork.maa.org/moodle/mod/forum/discuss.php?d=3860&parent=10934
Arnie
You can actually approach this either way.
You can set up LTI authentication on a per-course basis by transferring the settings from authen_LTI.conf into course.conf (or just including the file).
It is also possible to have a course accessible both via LTI and direct login, with a couple of caveats:
- If a student logs in through your course management system (in your case Brightspace), and there is not an existing WeBWorK account to connect them to, then WeBWorK will create a new user for them, but this user will not have a local password, so they won't have any way to log in using the standard login screen unless an instructor resets the password for them.
- If you plan to use the grade passback feature, then students will need to log in at least once via LTI for each course/assignment which has a grade item attached. Doing so gives WeBWorK the information it needs to sends the grade back to the LMS.
If you are okay with these restrictions, then there are a couple of lines to look at in authen_LTI.conf. First set
$external_auth=0;
If you are using internal WeBWorK passwords, then this is all you need to change, noting 1. above (you need some other process to create passwords for users). If you are using an external authentication system (e.g. LDAP, Active Directory), then you will need to change the following section of authen_LTI.conf as well:
$authen{user_module} = [
{ "*" => "WeBWorK::Authen::LTIAdvanced", }, #preferred authorization method
{ "*" => "WeBWorK::Authen::Basic_TheLastOption",} #fallback authorization method
];
You will have to replace the second entry with whatever authentication module you are using.
A couple of notes specific to Brightspace/D2L:
- I have added D2L-specific instructions for setting up LTI links at http://webwork.maa.org/wiki/LTI-Advanced_Authentication_for_D2L. Feel free to edit these if you have anything to add/change.
- Currently there is a problem with grade passback that should be fixed by PR 726. In my case I have it working with the on-submit grade passback, but have been running into trouble with the scheduled grade passback.
Thanks everyone, today I met with our Brightspace team leader and it appears we have single sign-on working. It's not live here for a little while because it needs to go through standard security and accessibility evaluations. But we hope to have it live by the time our Fall term starts (Sep 29). I'm going to wait on grade pass back until Winter term.
I have one issue to report, which may be of use to others, or may be a symptom of me mismanaging git over the years. I pulled master this morning which has PR#726 in it now at its head. This pull resulted in a conflict in
lib/WeBWorK/Authen/LTIAdvanced.pm
around line 366 where I had formerly had these lines:
- # append the path the the server url
- $path = $path.$r->urlpath()->path;
and the pull wanted these lines to got there instead:
+ if ( $ce->{debug_lti_parameters} ) {
+ warn("The following path was reconstructed by WeBWorK. It should match the path in the LMS:");
+ warn($path);
+ }
The additions are clearly from #726. The two deletions do not exist in master, but do exist in develop. So I guess I pulled develop into my repo at some point earlier this summer, then pulled master with #726 leading to this conflict.
After I addressed the conflict and deleted these lines, single sign-on was not working. Following the LMS to a WeBWorK link took me to the login screen with a message about failed authentication. Once I added these two lines back in (right above the #726 added content) then it all works. If anyone finds themselves in a similar situation (where you have been sometimes cherry picking develop commits on top of master) then maybe you will want to check for these lines.
Danny, thanks for the D2L specific instructions. I think there will be some minor differences from one version of D2L to the next. For instance I had no "Send system role to tool provider" option to check. I had "Send system Org Defined ID to tool provider" which I checked, although I'm not sure if it mattered. And when my colleague was working in our D2L testing environment which is an even newer version, there were even fewer of these options to check. His guess was that many of them are now passed no matter what.
I have one issue to report, which may be of use to others, or may be a symptom of me mismanaging git over the years. I pulled master this morning which has PR#726 in it now at its head. This pull resulted in a conflict in
lib/WeBWorK/Authen/LTIAdvanced.pm
around line 366 where I had formerly had these lines:
- # append the path the the server url
- $path = $path.$r->urlpath()->path;
and the pull wanted these lines to got there instead:
+ if ( $ce->{debug_lti_parameters} ) {
+ warn("The following path was reconstructed by WeBWorK. It should match the path in the LMS:");
+ warn($path);
+ }
The additions are clearly from #726. The two deletions do not exist in master, but do exist in develop. So I guess I pulled develop into my repo at some point earlier this summer, then pulled master with #726 leading to this conflict.
After I addressed the conflict and deleted these lines, single sign-on was not working. Following the LMS to a WeBWorK link took me to the login screen with a message about failed authentication. Once I added these two lines back in (right above the #726 added content) then it all works. If anyone finds themselves in a similar situation (where you have been sometimes cherry picking develop commits on top of master) then maybe you will want to check for these lines.
Danny, thanks for the D2L specific instructions. I think there will be some minor differences from one version of D2L to the next. For instance I had no "Send system role to tool provider" option to check. I had "Send system Org Defined ID to tool provider" which I checked, although I'm not sure if it mattered. And when my colleague was working in our D2L testing environment which is an even newer version, there were even fewer of these options to check. His guess was that many of them are now passed no matter what.