cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Community Member

Names and Roles Provisioning user_id

Jump to solution

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

1 Solution

Accepted Solutions
Highlighted
Community Member

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:

Names and Role - Canvas LMS REST API Documentation 

View solution in original post

7 Replies
Highlighted
Community Member

Here's the helpful response from Canvas Support:

Hello,

Thanks for contacting Canvas Support! Unfortunately the development of new tools is not a supported feature you will need to adjust what your program is expecting from Canvas as we do not make adjustments to our API output for the purpose of custom scripting. I also recommend taking a look at our Canvas Developers page to see if you can obtain some help and collaborate with other developers. 


Warm regards,

Megen G.
L1 Canvas Support

The API Documentation shows the expected output format (ie, f30b6507e1ea6cc02a917ae9887e4f59197c428f, Names and Role - Canvas LMS REST API Documentation) so just asking again if anyone might have run into this?

0 Kudos
Highlighted

Just a follow up on the Canvas support response. After escalating the ticket to tier 2, the team was very helpful in recognizing the issue (see the comments by Jesse below) and posing a possible future solution of adding an additional field to the Names and Roles Provisioning Service API that provides the old local Canvas instance unique user_id value. Hopefully that new field will be a reality in an upcoming release. Unfortunately, Jesse's excellent suggestion won't work for us, as we're trying to get the user_ids of the students on the course roster (and thus the need for Names and Roles Provisioning Service) and not the user_Id of the LTI Tool launcher.

0 Kudos
Highlighted
Community Member

Hi William

I have a very similar issue, I feel as if there are so many Id's for each user in canvas. However I hope to help you with something that I have found out. If you initiate the login through openid, and decode the id_token, the sub field should at least tell you what the name-and-roles-membership id of your user is.

See below:

323782_Screenshot from 2019-09-12 11-44-19.png

323963_Screenshot from 2019-09-12 11-45-14.png

The "sub" field for the id_token (decoded on jwt.io) and the user_id for the first member is the same id.

This is something I just found out, I know it might not fix your problem completely, but it could help Smiley Happy

Regards

Atli Gislason

0 Kudos
Highlighted

Thanks Atli! That's a great suggestion, but unfortunately in our case we're trying to use the Names and Roles Provisioning Service to pull the user_ids of each student on the course roster, not the user_id of the LTI Tool launcher.

It makes sense what Instructure is doing with their move to UUIDs instead of locally unique IDs, given the increase in instance interaction and course sharing between institutions, but unfortunately, without a way to remain backwards compatible with LTI 1.1 unique user_ids, LTI 1.3 Names and Roles just doesn't work with existing databases and thus breaks the promise of backwards compatibility Smiley Sad

Highlighted
Instructure
Instructure

Due to the global nature of LTI 1.3 in identifying users, Canvas had to add a new identifier for users. This id is the uuid format you are mentioning and is unique for a user globally, whereas the LTI 1.1 id was scoped to an account.

There is a way, using custom_fields, to retrieve the account-scoped user id that can then be used to map a user's new id in your database. These custom_fields would look something like `old_user_id: $vnd.instructure.User.current_uuid` in your custom fields declaration. If you need to map users who have been merged, you could also include something like `current_context_old_user_id: $vnd.instructure.User.uuid` in your custom fields declaration. The combination of these two fields should be sufficient to map a launched user to any given user in a context that may already exist in your database.

0 Kudos
Highlighted
Community Member

Thanks Jesse, that is a great idea, but unfortunately we're trying to get the user_ids of the students on the roster, not the user_id of the tool launcher... So we're still dependent upon the data returned by the Names and Roles Services API call and that only returns the new global UUID...

0 Kudos
Highlighted
Community Member

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:

Names and Role - Canvas LMS REST API Documentation 

View solution in original post

Labels