Canvas and latest TSUGI: LTI 1.1 Transition error: Missing oauth_consumer_key

[Tom Reijnders]

Hi Dr Chuck,

I have a client using Canvas, and the LTI link stopped working (probably after an update of Canvas). They are using an LTI 1.3 launch, and although they are using latest TSUGI (on PHP 8.1), the LTI 1.3 issuer is set up in an older version of TSUGI, so still uses a separate LTI 1.3 issuer and a key that refers to the issuer.

We're setting up a new launch, to a new Xerte project, and this is the error we get:

Looking in the logs, I do see where the error originates from, and there is a check about an LTI 1.1 transition if there is a lti11_legacy_user_id claim. And sure enough there is one:

"https://purl.imsglobal.org/spec/lti/claim/lti11_legacy_user_id": "041ff0e73aeb6e7cb11d7d77473acdcc97d94cd0",
  "https://purl.imsglobal.org/spec/lti/claim/lti1p1": {
    "user_id": "041ff0e73aeb6e7cb11d7d77473acdcc97d94cd0",
    "validation_context": null,
    "errors": {
      "errors": {}
    },
    "resource_link_id": "4e0ee425c67ab2b0e3bbe1aa2909448120a357de",
    "oauth_consumer_key": "MyKey",
    "oauth_consumer_key_sign": "redacted"
  },

The key MyKey does not exist in TSUGI. Is that the reason why we get this error. And do you have any idea in what cases Canvas should include a lti11_legacy_user_id? If the launch used to be an LTI 1.1 link? If the App used to be LTI 1.1? As far as we know LTI 1.1 was never used in conjunction with Xerte in this install? 

I've seen this error in another Canvas install as well and in the end we managed to get it working, but I don't remember exactly how we did that. Probably by reinstalling the issuer, but that doesn't seem like the correct solution.

So, the next question is, how do we get this working again? 

Cheers,

Tom Reijnders

[Charles Severance]

Tom,

I (and maybe we) have so little experience with an LTI 1.1 -> 1.3 transition so each time something comes up we learn something new.

This is my educated guess.

I think someone mistakenly configured an LTI 1.3 placement in Canvas and said “Yes we had a LTI 1.1 key” and then put in bogus data that they plucked from air. The “MyKey” suggests to me it was made up.

Canvas dutifully added the claim with the transition data it was handed and Tsugi checked its signature and freaked out because the key did not exist and the signature was incorrect.

So there are two ways to fix this and we should do both.

1. Check with the client and ask if they just plucked the LTI 1.1 key form the air as if it were “required” and they filled it in because they don't like blanks on forms.  If the client can’ have them just delete the LTI 1.1 stuff from their 1.1 key.

2.  Tsugi should not fail when it sees bad LTI 1.1 data it - just ignore and add a log.error - but don’t blow up.  The transition is 100% optional and Tsugi functions perfectly well without it on an otherwise correct launch.  Its only goal is to save a row in the user table.  But for a bogus key - that “old” row is not there to be saved.

Could you work on (1) and I will work on (2).  Given how little we know about Canvas LTI 1.1 -> LTI 1.3 transition - any verified data is precious.

Thoughts welcome.

/Chuck

--
You received this message because you are subscribed to the Google Groups "Tsugi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsugi-dev+...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/1989b2cd-3ac4-472f-903d-89981d7780ebn%40apereo.org.

[Tom Reijnders]

Hi Dr. Chuck,

Yes, I will ask again, and also ask whether I can set up an online meeting to have a look at what is in the Placement. I did ask whether they new anything about the key, and it was totally unfamiliar. I've been told it was a new placement and they did not use the deeplinking functionality (store) but just entered the launch_url from Xerte. 

Cheers,

Tom

[Tom Reijnders]

Hi Dr. Chuck,

I did get a response back of the Canvas user. This was a new LTI link to a new Xerte project. Also the key is unknown to them, and I cannot find a location where this would have been entered in Canvas. What they do:

There is a LTI 1.3 connection set up on a (sub) site of Canvas.

They add an External tool activity to Canvas, and instead of selecting a tool by choosing a deeplink, they just paste in the launch url of the tool (that picks up the LTI1.3 link automatically) and that is all they do. So, I don't know why Canvas thinks this is an upgraded LTI 1.1 link, and I don't know where the key is coming from.

Cheers,

Tom

[Charles Severance]

Tom,

Tsugi master now treats LTI 1.1 transition failures as “ignore” and continue rather than “freak out and abort”.   Error messages are still logged but the launch continues.

Let us know if this fixes your issues.

/Chuck

Begin forwarded message:

[Charles Severance]

On Aug 3, 2024, at 1:21 AM, Matthew Jones <matthe...@learnxp.com> wrote:

That lti11_legacy_user_id has been part of the spec and Canvas since at least 2019. That's not what was triggering this though.

This change feels suspicious from 3 weeks ago.

https://github.com/instructure/canvas-lms/commit/9b2f9876b7287e9c4c5101141002ec2c75f3b3e7

It looks like there was a feature flag but the flag was removed and it seems like for some tools that it considers associated to a 1.1 tool it adds oauth_consumer_key in the lti1p1 and for that weren't it doesn't. It seems like if this feature flag was off, this just returned nil so nothing was returned.

When enabled, LTI 1.3 launches that would be associated with LTI 1.1 tool if the LTI 1.3 tool wasn't present will include the oauth_consumer_key and oauth_consumer_key_sign properties as part of the LTI 1.1 claims section.

It seems like Canvas thinks there was an associated tool and sends this claim in the first place if you had an LTI 1.1 originally and were now using a 1.3 with the same launch URL? I'm not too sure how this migration process is working in Canvas.

The fix feels fine and it might not even have to log it as an error as the https://purl.imsglobal.org/spec/lti/claim/lti1p1 could be set with a user_id and nothing else now.

Matt, this tracks nicely with what Tom is seeing.  Thanks for the intel.  I may adjust the logging after a while because it is going to log every broken launch forever :)  We can get some experience and adjust the logging strategy.

By “a user_id and nothing else” - I assume you mean “user_id, key, and signature and nothing else”  because user_id alone is a broken claim that should be rejected / ignored by any tool - or has something changed in the spec or other practicethat I am not aware of?

When an LTI 1.1 transition claim is wrong - the correct action is to ignore.   All it means is that a user from Canvas will have two identities in the lti_user table.  If the LTI 1.1 transition is done properly it is an awesome feature - but if the claim is broken in one way or another - it is not really a concern.  Throwing up a fatal error when there is no real way to fix it for the teacher in Canvas is kind of foolish.

I am guessing that a less experienced person in Canvas kind of thought that they needed to put in that transition claim even if it means making up data.   If you came to LTI after 13 was long out, I could see this mistake easily happening :)  Or perhaps they are changing / improving their transition code in Canvas and version 0.9 was a little bumpy :)

In any case, Tsugi, Tom, and Tom’s customer can go back to cruise control and worry about teaching instead of plumbing :)

Thanks.

/Chuck

[Matthew Jones]

Yeah, not sure. It feels like Instructure has many newer devs and the one that made this commit has only been there since 2022. 

Some tools are just sending this claim

 "https://purl.imsglobal.org/spec/lti/claim/lti1p1":{

"user_id":"4869..."

"validation_context":

NULL

"errors":{

...

}

}

While others are sending 

"https://purl.imsglobal.org/spec/lti/claim/lti1p1":{

"user_id":

"4869..."

"validation_context":

NULL

"errors":{

...

}

"oauth_consumer_key":

"10.."

"oauth_consumer_key_sign":

"aa..."

}

The spec does say "The LTI 1.1 oauth_consumer_key MUST be added to the claim." where the oauth_consumer_key_sign is optional. It seems like there's a bug here in Canvas now, but as you said, you added the Tsugi fix!

[Tom Reijnders]

Hi Dr. Chuck,

Thank you for this. I'll update the TSUGI installation at the client and let you knwo how it goes.

Cheers,

Tom