We are continuing to implement WebWork v2.19 integration with Canvas via LTI 1.3. The latest challenge relates to sorting out roles between the 2 systems.
When users first attempt to access WW using a link properly configured in Canvas (which for a student can create their WW course account) the LTI integration supplies a list of several roles derived from Canvas roles. In terms of the LTI role vocabularies (see https://www.imsglobal.org/spec/lti/v1p3#roles-claim), these lists are a mix of institution roles, context roles, and system roles. It is my impression that the LTI spec encourages this behavior of supplying all of the user's roles as best practice. We see a mix of 3 institution roles: institution/person#Administrator, institution/person#Instructor, and institution/person#Student; 2 context roles: membership#Instructor and membership#Learner; and 1 system role: system/person#User. For most students this claim lists: institution/person#Student, membership#Learner, and system/person#User; and for most instructors the claims lists: institution/person#Instructor, membership#Instructor, and system/person#User. At present we have no TA users, and WW access by Canvas admin users is not a distinct concern.
Our problem occurs for a number of Math students who also serve as peer mentors, tutors, or TAs for courses in other departments. These students have additional roles in Canvas for those other courses, typically institution/person#Instructor. An example claim received from Canvas for one such student includes:
"https://purl.imsglobal.org/spec/lti/claim/roles" => [
"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Instructor",
"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Student",
"http://purl.imsglobal.org/vocab/lis/v2/membership#Learner",
"http://purl.imsglobal.org/vocab/lis/v2/system/person#User"
],
When one of these students accesses WW for the first time from their Canvas Math course, the LTI 1.3 authentication process in /opt/webwork/webwork2/lib/WeBWorK/Authen/LTIAdvantage.pm attempts to create their account in the WW course. This code, in sub create_user, ignores any listed role from the LTI system vocabulary (system/person#User in the above case) and makes no distinction between listed roles from the context and institution vocabularies (the other three items shown). Sub create_user will create an account for the user's highest WW permission level role, as long as it is not above the WW role "student". This means that an account cannot be created for a student with context role membership#Learner (in the Math course) who also has an institution role institution/person#Instructor (as TA in another department), as shown above.
This is a problem since we want both to have LMS/LTI 1.3 integration with WW (so the privacy and security issues are handled in the University-wide context), and to have routine access to WW for all of our Math students. While our colleagues managing the new Canvas install and buildout for the entire campus have been most supportive, we cannot and should not expect them to make changes to their LTI implementation to handle our specific WW needs.
For our environment, it appears that we are only interested in context roles from Canvas (e.g. membership#Learner), because those will be specific to the Canvas course connecting to a given WW course. A student's role as a TA, or even as an instructor, in a different Canvas course is not relevant for the student's access to WW for the Math course. I assume that the present WW authentication behavior is useful for other environments, however, and conclude that we will need to use a modified version of create_user locally until a new version enabling this option is implemented.
Unless I'm mistaken. Has this issue been addressed, and even better solved, by someone else somewhere? If so, please post about your experience. I can't find a previous mention of this issue in the WW forum, the Canvas forum, or elsewhere.