[External Tools] Developer Key ability to specify sub-accts included

[michelle_coots]

Problem statement:

With the transition to LTI 1.3 integrations, we are increasingly setting up developer keys to implement integrations with external products. When setting up developer keys and specifying data sharing we do not currently have an option to specify which sub-accounts to share. As a result access to our full instance is available to vendors. Example 1. While we currently have all campuses using a specified resource, we initially implemented it with only a few campuses. During our initial implementation, we were not able to use the Canvas integration since the full instance would be shared. Example 2: Within our instance we have manually-created courses in a dedicated sub-account along with other sub-accounts for training, course shares, etc. Within our manually-created sub-account there are courses used for student groups (like clubs & sports) where staff have added students and volunteers with the "teacher" role. Because our manually-created sub-account is included in the sharing with a vendor, users with these roles have access to that platform as teachers.

Proposed solution:

When creating developer keys there should be check boxes to specify from which sub-accounts to share course & enrollment data.

User role(s):

admin

[AlexisNast]

Thanks for this suggestion! I'm hoping to get a bit more information to make sure I fully understand the problem. Is the tool you are launching a course level tool or a global tool? What specific data are you concerned about sharing?

Generally tools are only given information about the specific context from which they are launched, even though the developer key is set up globally. The exceptions to this are:

• The global navigation placement only supports root level access, not sub-account specific information.
• The roles provided on launch include all roles, but we do indicate whether the role provided is a course or global role. An example of what gets sent to the tool is below

"https://purl.imsglobal.org/spec/lti/claim/roles": [
"http://purl.imsglobal.org/vocab/lis/v2/institution/person#Administrator",
"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#Instructor",
"http://purl.imsglobal.org/vocab/lis/v2/system/person#SysAdmin",
"http://purl.imsglobal.org/vocab/lis/v2/system/person#User"
],

The expectation is that the tool will select if they need the permissions that say "institution" which are the institution level roles, "membership" which are the course level roles, or "system" which indicate if the user is a system administrator. Thus the tool should be able to appropriately gate the user's access depending on what they need.

[AlexisNast]

Hi @michelle_coots ! Just wanted to check in and see if you're still having issues with this and if you can share more information about if this is a course level or global tool and what specific date you're concerned about. Thanks!

[AlexisNast]

Closing this idea. If there is more information to help us understand the need, please submit a new idea with further explanation.