[ARCHIVED] Trying to understand more about JIT provisioning, SIS CSV imports and "sticky" fields

univsys
Community Explorer

I thought I'd ask the community if you know the answers to these questions at the bottom of this post.

We use both JIT provisioning and a user SIS CSV upload. We're considering only doing an hourly user upload, as we're told below that running with both can cause issues.

Our biggest issue is with name changes. It doesn't seem like the JIT provisioning is updating existing user account information, but rather is creating a whole new user without an SIS ID. Since the SIS ID is the "key" I'd expect it to update the login, first name, last name, email, etc when the user logs in with their new account that has the same SIS I as an older one.

I had submitted a ticket to canvas asking if adding the SIS ID to our JIT provisioning would help with these name changes. For some reason when we set this up originally, they couldn't figure out the SIS ID field in the claims. From this previous ticket, a tech responded with the following:

I believe it may help this case to understand how the SIS Import process works with regards to Users, then compare this to how your other systems are provisioning Users in other cases.

 

To begin, your understanding of 'sticky' fields is correct. It is important to note that the login_id field is also sticky, so if it is ever modified in the UI or through the API, a normal SIS Import cannot affect it. You can send an import with 'Override UI changes' to override these, and can add 'Clear UI changed state' to those types of imports to also 'clear' that sticky status so normal SIS Imports can affect those fields again.

 

The SIS ID ('user_id' in the files) is the identifier we use to distinguish a User account. If this value ever changes, you should consider that an entirely new User. If a User (or a login set on a User) is deleted with a SIS ID, that SIS ID is still 'in use' by that deleted User. Any file that contains that SIS ID again with an 'active' state will attempt to return them to an active state (assuming the login_id is available). As long as it is set on any User (active or deleted) it cannot be set for a different account. It is globally unique.

 

Meanwhile the login_id field is only globally unique for active Users. A deleted User could still have a specific login_id set without causing conflict on any active users, as long as you are not trying to restore that deleted User. Similarly, you could not apply a login_id on a User that is already in use by another active User. This is why you have the 'An existing Canvas user [..] has already claimed [..]' error, indicating the login_id is already claimed.

 

As an addendum to the above, you can 'claim' User accounts with a SIS Import as long as the login_id matches and they have no SIS ID. If an import attempts to send data and the SIS ID is not in use, it will first look for an active User with the requested login_id. If one exists, and they do not already have a SIS ID, it will apply the SIS ID to that User and 'claim' them. You've likely seen this process in action, based on your descriptions.

 

When you mention your ADFS system generating Users, I'm assuming you're referring to Users created using Just in Time Provisioning. We would typically not recommend using this when data is being provisioned with another method. I'm not entirely certain if JIT provisioned Users count as an API generation, or if their fields end up being sticky. If files are being sent every hour, I think I would rather Users need to wait an hour for the imports to provision them, rather than needing to clean up conflicts between these two systems.

 

If the JIT provisioning can create the Users with the correct SIS ID, the next SIS Import should recognize that new User with the SIS ID and attempt to make any necessary changes. If the file has a different name or login_id than what was set by JIT provisioning, it would attempt to update those. If JIT provisioning fields are sticky, they would not be modified, and the login_id would remain as what was set through that system. If JIT provisioning does NOT create sticky fields, it would modify the login_id and name to be whatever was in the file.

 

JIT provisioning will create these types of conflicts. If we assume the User already exists ('asmith', SIS ID 12345) and JIT provisioning creates a new User with a new login_id ('ajohnson'), these are now distinct Users. It wouldn't matter if the original User was active or deleted. When the next SIS Import ran to also make that login_id change (eg 'ajohnson', SIS ID 12345) it would fail with the 'An existing Canvas user [..] has already claimed [..]' error. The login_id would already be in place.

 

I am not entirely certain what the JIT provisioning system would do if you send a 'new' login_id and an existing SIS ID, but I would suspect it should attach to that User. Depending on whether JIT provisioning changes are considered API changes (and thus sticky), you still may or may not want this to occur.

 

I hope this answers the questions you have concerning how the SIS Import system works and how it likely interacts with JIT provisioning. If you have any other questions I may have missed, let us know and we'll be glad to assist you further.

 

----

We fixed the ADFS provisioning so that it now includes the SIS ID. However, we're still experiencing issues.

Anyone know the answers to the following?

 

  • If a user account is JIT provisioned, are these considered API changes, and therefore "sticky"?

 

  • If a user account is created through the SIS CSV process, the"sticky" fields mentioned here (https://canvas.instructure.com/doc/api/file.sis_csv.html) do not become "sticky" unless they are edited via the UI, correct?

 

  • Lets say a user account is provisioned by the SIS CSV import, then - months later - their name changes, email address and username. If the user goes and logs into ADFS with their new login *before* a SIS CSV import comes in to update their information, the JIT provisioning will do which of the following?
    • It would recognize that the SIS ID (user_id) exists in the system already and update their user account with the updated ADFS properties (first name, last name, add a login, email, etc)
    • It would not find the login in the system, create a *new* user record, and then fail to associate the SIS ID (user_id) with the *new* account because it is already tied to another active login.

 

  • In the paragraphs above, James mentioned the "override state changes" and "clear UI changed state" parameters. I think he was referring to the API params override_sis_stickiness and clear_sis_stickiness. We don't want to clear the stickiness of certain fields, like the first name or display name of the student. If they changed that in canvas, we want that to remain. Can we send in these un-stickify parameters and clear the stickiness of certain fields? Or does this clear the stickiness for the whole user record?

 

  • I noticed that there is an integration_id secondary unique identifier for the user record in the CSV file format. Would throwing the SIS ID into that field in addition to the user_id help at all?

Thanks in advance!

Steve

Labels (2)