LTI 1.3 mixing roles

Jump to solution
JavierHex
Community Explorer

I have the following scenario with Canvas and my LTI 1.3 tool. I have a course X and I assigned a Canvas teacher into the course as student .When the user open the tool, the LTI payload contain both roles in the LTI role claim ( teacher + student) but it also assigned the role to the other courses. Shouldn't Canvas assign the role per course instead of assign it globally for the user ?   and also Shouldn't Canvas assign one role instead of mixing them ? Asking because based on this scenario the tool is not able to determine when the user have an specific role for an specific course.

Labels (3)
2 Solutions
chriscas
Community Coach
Community Coach

Hi @JavierHex,

This is getting out of my comfort zone as a Canvas admin, but I think I might have the answer.  Assuming you're looking at "https://purl.imsglobal.org/spec/lti/claim/roles", make sure you're looking at the membership values first, not the institution or system values.  When I launch a tool with my user account (an admin, also enrolled in some courses as a student and teacher) from a course where I'm a teacher, I see the following:

"https://purl.imsglobal.org/spec/lti/claim/roles":[
0:"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Administrator"
1:"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Instructor"
2:"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Student"
3:"http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor"
4:"http://purl.imsglobal.org/vocab/lis/v2/system/person#User"
]

So institution wide, I do have roles as admin, teacher, and student...  But the membership is just Instructor.

Someone else may come along and provide way more details than this, but I wanted to perhaps point you in a possible direction here for now.

-Chris

View solution in original post

DecoyLex
Community Participant

Hi Chris,

I'll take up the mantle of being that "someone else." At my institution, we've had to deal with these sorts of duel-role considerations with LTI tools a few times. Unfortunately, from what I've found, there isn't one place where anyone has spelled out the precise difference between the system, institution, and context roles offered in the LTI spec (the spec only enumerates the roles, but I haven't found any resource that actually explains them or the categories of roles for developers or anyone else).

Canvas will typically send over every role that applies to a particular LTI launch. Generally, LTI roles fall into one of three categories (see the LTI 1.3 spec; the explanations of what each category represent is my own):

  1. System Roles: These roles define the highest level of access within the entire learning management system. They are typically assigned to administrators who have authority over the entire platform. In the context of the list of roles you see, the http://purl.imsglobal.org/vocab/lis/v2/system/person#User role is an example of a system role. In Canvas, you'll typically only see the http://purl.imsglobal.org/vocab/lis/v2/system/person#User role. Canvas does send over other system roles for Instructure employees or for the "Site Admin" users in self-hosted Canvas instances. For example, I've seen http://purl.imsglobal.org/vocab/lis/v2/system/person#SysAdmin show up when playing around with a self-hosted Canvas instance.

  2. Institution Roles: These roles pertain to users' roles within the entire institution. They are usually broad categories like "Administrator," "Instructor," and "Student." The http://purl.imsglobal.org/vocab/lis/v2/institution/person#Administrator, http://purl.imsglobal.org/vocab/lis/v2/institution/person#Instructor, and http://purl.imsglobal.org/vocab/lis/v2/institution/person#Student roles are institution roles. In Canvas, these roles are typically based on the highest every context role held by a user (e.g., if a student in an Education class is given a sandbox course in Canvas, they'll have the Instructor institution role). LTI tools usually rely on institution roles when the tool provides functionality that is relevant across the entire institution or system, such as administrative tasks or reporting. These are commonly tools that appear outside of a course (e.g., in the Admin menu, User menu, or global navigation) where asking about someone's course role doesn't make sense.

  3. Context (Course) Roles: These roles are specific to a particular course or context within the LMS. They define the user's role within a specific course, such as "Instructor" or "Student" for that course. The http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor role is an example of a context role. If you're developing a tool that's deployed to the course-level, the tool should really only be looking at these roles (except to check for admin users, for example).

It's not uncommon for a user's context role to contradict one or more of their institution roles. Consider, for example, a scenario where a graduate student named Alex is pursuing their Master's degree while also working as an instructor at the same institution. In this case, Alex's roles within the institution and within a particular course can be quite distinct.

Alex holds an institution role of "Instructor" due to their responsibilities as the instructor of a course. Simultaneously, Alex has a membership role of "Student" within the courses in their graduate program, as they are actively pursuing their own studies. In this capacity, they might participate in other courses where they're a student, submit assignments, take quizzes, and engage in the learning process like any other student. However, in the course(s) they teach, Alex has a membership role of "Instructor."

In Canvas, it is also possible for someone to hold multiple roles within the same course through section enrollments. For example, our institution lets faculty cross-list their courses without much oversight. This has led to some situations where a person has a TA and a Teacher role (e.g., they're a Teacher in a lab course and they've cross-listed the lab with the lecture course where they're a TA). Generally, sections are invisible to LTI tools, unless they are explicitly passed in the custom fields.

Canvas also allows admins to define custom roles, but these don't (currently) affect the roles sent over in the LTI launch. For example, if an institution has a special Librarian role (based on a DesignerEnrollment), Canvas won't send over the http://purl.imsglobal.org/vocab/lis/v2/membership/ContentDeveloper#Librarian LTI role; it'll just send it over the same role as a regular Designer: http://purl.imsglobal.org/vocab/lis/v2/membership#ContentDeveloper.

For LTI tool developers, consider a few questions when building out your access control functionality:

  1. Does the tool offer features specific to individual courses or broader functions relevant across the institution?
  2. Should access be controlled at the institution level, the course level, or both?
  3. Which institution or membership roles interact with the tool, and how should the tool respond to users in different roles?
  4. How can the tool be customized to provide tailored experiences for users with diverse roles and responsibilities?
  5. How do institution and membership roles interact, and how might users with multiple roles within a context experience the tool?
  6. How do we communicate the tool's functionality and limitations to users?

I hope this qualifies as "way more details" 🙂

View solution in original post