Names and Roles Provisioning user_id
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greetings,
We're trying to develop a v1.3 LTI tool that utilizes the Names and Roles Provisioning Service. When we query the api URL, the result we get for user_id does not seem to be as expected...
We're getting a format like this: 6f9ee147-ed91-418e-aa38-0b3749c68e4b
But we're expecting a format like this: f30b6507e1ea6cc02a917ae9887e4f59197c428f
The above two IDs are from the same user - the first example is returned by the Names and Roles Provisioning Service when querying the roster and the second is the value used by a third party that received it during the v1.1 launch of their LTI tool.
In my mind, the unique user_id value for LTI purposes should be the same in all cases, regardless of whether it's retrieved from Names and Roles or if it's received during an LTI 1.1 launch...
Anyone else facing this issue?
William
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Edit:
Unfortunately, we're STILL at an impasse as the recommended custom variable $vnd.instructure.User.uuid still does not match the original LTI v1.1 user_id launch field. So, at this point, the issue seems unresolved until Canvas can add an additional field that contains the v1.1 user_id value. It might be appropriate then for Instructure to follow the migration documentation here and implement the lti11_legacy_user_id field in the Names and Roles output.
---------------------------------
Just another follow up. Thanks again to Jesse on the LTI Partner Support Team, there is what appears to be a valid work around. It requires a bit more json gymnastics, but basically provides the LTI 1.3 Names and Roles service with the old LTI 1.1 launch userID value.
You must specify the $vnd.instructure.User.uuid variable as a custom variable substitution in your LTI 1.3 developer key settings and also include the LTI 1.3 tools resource link ID (provided in the launch JWT) as an rlid parameter when making the Names and Roles query.
When the rlid parameter is provided, the Names and Roles json result will include the custom parameters that would be visible if the roster user object has requested the LTI to launch (including the custom parameters). So it's a round about way of getting the custom launch parameters (including the old uuid) for each person on the roster.
The values are returned in the "message" field, thus the need for more json gymnastics as you have to parse through that data.
See here for the REST docs on the rlid parameter and an example result object with the message field:
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.