LTI 1.3 Allowed login to unmapped course

[mdavensmith]

I’m testing a WeBWorK 2.20 server with LTI 1.3 (Canvas as the LMS) and ran into a possible FERPA issue.
I tried to secure the admin course by creating an LTI link for instructors. While testing, I noticed that using the wrong link for another course, I am able to log into that course instead.
Example:

Admin course context ID: 123
Another course (Math_Course) context ID: 456

If I place the admin-course LTI link in Canvas, clicking it sends me to the correct admin course page, but if I use the wrong course link, for Math_Course, I am instead logged into that course from Canvas.
Our concern: instructors may copy/paste the wrong WeBWorK link into Canvas. Canvas course 1234 should map to a WeBWorK course with context ID 1234, but if the link points to a course expecting context ID 5678, WeBWorK still logs the user into that other course.
This behavior could unintentionally grant access to the wrong course and expose student information.

[drgrice1]

The context id does not matter for LTI 1.3 authentication in general. The context id is only used for content selection. The context id mapping that WeBWorK maintains is not for what you are thinking.

The external tool in the LMS will work for any course in WeBWorK, and the only determination as to which course you will be sent to is the external tool link. This is always the way that LTI authentication has been with WeBWorK, and we aren't going to change that (at least not for WeBWorK 2).

This should not be a FERPA issue though. Even if one instructor created a link to another instructor's course, they will not be able to login to the course unless they are already a user in the course.

I do not recommend allowing LTI authentication for the admin course. This is why we have set the default for the $authen{admin_module} to include only the WeBWorK::Authen::Basic_TheLastOption module. If you do use LTI authentication with the admin course, then you should make certain that the only users in the admin course are those that you want to allow access to it. Generally, instructors should not have access to the admin course.

[mdavensmith]

The issue I'm having is that LTI authentication from Canvas is creating the user in the course if they don't exist.

I just tested and after removing myself from the course I am mistakenly accessed via Canvas and my account was re-created when using that link to access the course.
If this is the case, then anyone accessing the course through the provided link would have their account created in the course despite not being in the course already.
With that said, if that's just a side effect of LTI authentication then I'll leave that off for the admin course and stick with local logins only. Unless there's a way to lock down account creation, but we would like to have it for instructors.

[drgrice1]

Have you changed the $LTIAccountCreationCutoff? By default that is set to ta. That means that accounts are only automatically created for those users that have an LMS role that corresponds to a permission level lower than ta in the $LTI{v1p3}{LMSrolesToWeBWorKroles} mapping. Or maybe you have changed that mapping?

[mdavensmith]

Yes I changed that mapping to professor so TAs could also be created through Canvas. (professors should be created locally on the server if I read that correctly)

That said, that means students using an incorrect link will have their accounts created for a course they should not be enrolled in, which I was told would be an issue.

[drgrice1]

Actually, reading the documentation for the $LTIAccountCreationCuttoff, I see that I was mistaken. ta means that those with roles corresponding to ta or less will be created. So if you have it set to professor, then professor accounts will be automatically created.

[drgrice1]

Students should never be presented with a link to the wrong course. If they are, that means that an instructor is creating an link to an incorrect WeBWorK course and publishing for students. That should never happen. Although, I also don't see why that is a problem, at least in terms of FERPA requirements. Student's would gain access to a course they are not enrolled in, but they still will not be able to see any data for any other students in the course.

[mdavensmith]

I agree with that part, I left out this part from my team:

that would be a FERPA violation in the case of new instructor having access to grade information from previous instructor's course.

Which I interpreted as "if an instructor takes over from a past instructor and copies an existing Canvas course, but doesn't change the WebWork URLs they're linking to a course they shouldn't, and if they access the page by mistake they're accessing grade information they should not have access to.
Which is why I wanted to see if this was a bug, or if there are any safety rails we can implement to prevent unauthorized course access. They want a 1:1 mapping of a canvas course to a webwork course.

[drgrice1]

The new instructor should not have a user in the previous instructor's WeBWorK course. Then the instructor will not have access even if the Canvas course copy has the old links. If the new instructor has a valid user in the WeBWorK course, then WeBWorK will allow access because you told it to by creating that user.

This is not a bug. The safety rail you can implement is simply don't create users in the WeBWorK courses for instructors that are not instructors in that course or that should not have access, and make sure the account creation cutoff is set right.

[mdavensmith]

I just realized the answer to this, at least for the instructor acceess part.
Changing to the default cutoff (ta) gives an error when an instructor tries to access the webwork URL through the LTI tool on a course. So that part should be resolved now.

[mdavensmith]

The new instructor should not have a user in the previous instructor's WeBWorK course. Then the instructor will not have access even if the Canvas course copy has the old links. If the new instructor has a valid user in the WeBWorK course, then WeBWorK will allow access because you told it to by creating that user.

This is not a bug. The safety rail you can implement is simply don't create users in the WeBWorK courses for instructors that are not instructors in that course or that should not have access, and make sure the account creation cutoff is set right.

Thank you, I realized this was staring me in the face earlier. Apologies for the fuss!

Thank you again for your insight and time.

[Alex-Jordan]

On top of all that's been discussed, I recommend routinely closing WeBWorK courses once a term/semester ends. Otherwise a new LMS course can be created, copying everything from an old LMS course, including LTI links to an old WW course. The new LMS instructor should update the LTI link URLs, but might not get to it (or might overlook this) before a student uses such a link, and gets an account created in the old WW course. That is not a FERPA issue, but creates a headache if the student starts doing work in the old WW course.

So closing old WW courses as soon as is reasonable protects against this. You could also do more fine-grained management like setting $LTIAccountCreationCuttoff to even lower than a student within the old WW course's course.conf file.