cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ttiole
Community Participant

Canvas LTI 1.3 Error: Unknown Key Type

Jump to solution

Hello,

I'm attempting to implement LTI 1.3 as a tool provider and I'm developing against canvas. I've stumbled upon an issue that I've been trying to resolve for a while now, and I can't find any solutions. The issue I have has been mentioned in both of these threads 1 2; however, neither thread provides a solution.

For brevity, I'm only showing a partial part of the error in the error report

Category: JSON::JWK::UnknownAlgorithm

Unknown Key Type

        /opt/bitnami/apps/canvaslms/htdocs/vendor/bundle/ruby/2.5.0/gems/json-jwt-1.11.0/lib/json/jwk.rb:49:in `to_key'
/opt/bitnami/apps/canvaslms/htdocs/vendor/bundle/ruby/2.5.0/gems/json-jwt-1.11.0/lib/json/jose.rb:25:in `with_jwk_support'
/opt/bitnami/apps/canvaslms/htdocs/vendor/bundle/ruby/2.5.0/gems/json-jwt-1.11.0/lib/json/jws.rb:106:in `sign'
/opt/bitnami/apps/canvaslms/htdocs/vendor/bundle/ruby/2.5.0/gems/json-jwt-1.11.0/lib/json/jws.rb:17:in `sign!'
/opt/bitnami/apps/canvaslms/htdocs/vendor/bundle/ruby/2.5.0/gems/json-jwt-1.11.0/lib/json/jwt.rb:35:in `sign'
/opt/bitnami/apps/canvaslms/htdocs/gems/lti-advantage/lib/lti_advantage/messages/jwt_message.rb:67:in `create_jws'
/opt/bitnami/apps/canvaslms/htdocs/lib/lti/messages/jwt_message.rb:36:in `generate_id_token'
/opt/bitnami/apps/canvaslms/htdocs/app/controllers/lti/ims/authentication_controller.rb:121:in `id_token'
/opt/bitnami/apps/canvaslms/htdocs/app/controllers/lti/ims/authentication_controller.rb:56:in `authorize'

I have triple checked to make sure that lti_message_hint and login_hint are being passed to canvas properly, and my JWK key is fine (though as far if I understand correctly the tool's JWK key is not necessary for this step).

I've got a self-hosted cloud instance of canvas. I can provide more information of the environment if necessary.

I really appreciate any help at all.

Labels (1)
0 Kudos
2 Solutions

Accepted Solutions
ttiole
Community Participant

After many days of frustration, I found the solution. Hope this helps someone, especially since large part of my frustration was seeing people with the same problem as me in this forum who never posted how they solved their problem.

Anyhow, the answer to this problem was incorrectly configured environments. For context, I tried this on four different environments. The quick-start development, the quick-start production, bitnami (cloud), and IONOS.

Here's a rundown of each one:

  • Quick-start development could've worked, but I believe I skipped this step, since I really didn't care that much about extra performance. As the production quick-start mentions (but not the development one for some reason???) "there are some features of Canvas that require redis to use, such as OAuth2," and if you're implementing LTI you'll know that you use OAuth2. So, if you don't install redis you will come across errors when developing your LTI tool.
  • IONOS doesn't work at all for LTI 1.3 since they are not using an updated version of canvas so LTI 1.3 is not supported.
  • Quick-start production and bitnami both face the same issue, not properly configured dynamic_settings.yml. In the case of bitnami, the example one wasn't even touched, dynamic_settings.yml didn't even exist (only dynamic_settings.yml.example). Quick-start production does have a section about it, but no indication that this is something that is required if you want LTI 1.3 to work. In fact, even if you copy the dynamic_settings example file like the production section suggests, it still won't work. You see, even though the example files often have a development property and a production property, dynamic_settings doesn't. It actually only has a development property! To fix it, I simply changed development to production, and assuming everything else is configured properly your LTI integrations should begin to work. Reason why this is necessary is because this file actually contains the JWK's necessary to sign the token in launch initiation or to respond to the /api/lti/security/jwks endpoint. There was 0 indication online at all that this was necessary, and I found this out by looking through the source code.

If any canvas developers see this, please do me a favor and update the quick-start guides to avoid this issue. On the development quick-start, please mention that redis is necessary for OAuth to work, since somebody who is developing will go straight to the development quick-start and will not have this information. And in the production quick-start, please note that LTI won't work without reconfiguring dynamic_settings.yml, and maybe add the production example so that it can work straight out of the box by copying dynamic_settings.yml.example.

At the very least, anybody with this issue will hopefully stumble upon this thread and I sincerely hope it helps.

View solution in original post

marcspringshare
Community Participant

FWIW, this solution worked for me as well.

If you are using Bitnami I suggest restarting services after making the change, or to be safe, just restart the whole box:

sudo /opt/bitnami/ctlscript.sh restart

View solution in original post

0 Kudos
8 Replies
ttiole
Community Participant

It seems my canvas environment has trouble with web tokens in general. If I try to access the /api/lti/security/jwks endpoint to get the canvas public keys I get another 500 (different error though).

ttiole
Community Participant

After many days of frustration, I found the solution. Hope this helps someone, especially since large part of my frustration was seeing people with the same problem as me in this forum who never posted how they solved their problem.

Anyhow, the answer to this problem was incorrectly configured environments. For context, I tried this on four different environments. The quick-start development, the quick-start production, bitnami (cloud), and IONOS.

Here's a rundown of each one:

  • Quick-start development could've worked, but I believe I skipped this step, since I really didn't care that much about extra performance. As the production quick-start mentions (but not the development one for some reason???) "there are some features of Canvas that require redis to use, such as OAuth2," and if you're implementing LTI you'll know that you use OAuth2. So, if you don't install redis you will come across errors when developing your LTI tool.
  • IONOS doesn't work at all for LTI 1.3 since they are not using an updated version of canvas so LTI 1.3 is not supported.
  • Quick-start production and bitnami both face the same issue, not properly configured dynamic_settings.yml. In the case of bitnami, the example one wasn't even touched, dynamic_settings.yml didn't even exist (only dynamic_settings.yml.example). Quick-start production does have a section about it, but no indication that this is something that is required if you want LTI 1.3 to work. In fact, even if you copy the dynamic_settings example file like the production section suggests, it still won't work. You see, even though the example files often have a development property and a production property, dynamic_settings doesn't. It actually only has a development property! To fix it, I simply changed development to production, and assuming everything else is configured properly your LTI integrations should begin to work. Reason why this is necessary is because this file actually contains the JWK's necessary to sign the token in launch initiation or to respond to the /api/lti/security/jwks endpoint. There was 0 indication online at all that this was necessary, and I found this out by looking through the source code.

If any canvas developers see this, please do me a favor and update the quick-start guides to avoid this issue. On the development quick-start, please mention that redis is necessary for OAuth to work, since somebody who is developing will go straight to the development quick-start and will not have this information. And in the production quick-start, please note that LTI won't work without reconfiguring dynamic_settings.yml, and maybe add the production example so that it can work straight out of the box by copying dynamic_settings.yml.example.

At the very least, anybody with this issue will hopefully stumble upon this thread and I sincerely hope it helps.

View solution in original post

GreenOn
Community Member

Thank you! You saved us a lot of time and trouble!

marcspringshare
Community Participant

FWIW, this solution worked for me as well.

If you are using Bitnami I suggest restarting services after making the change, or to be safe, just restart the whole box:

sudo /opt/bitnami/ctlscript.sh restart

View solution in original post

0 Kudos
olav
Community Participant

With a big chance of me missing something: How are the private keys used to generate jwt generate public keys in dynamic_settings.yml stored? I have extracted the private one and put in the jwt in the dynamic_settings file using rails console (mentioned here https://github.com/instructure/canvas-lms/blob/master/config/dynamic_settings.yml.example#L109) , but there is no hint of where to put the private part. Only mention of private key in code is a saml key, and that have to be the wrong one. 

yuling3086
Community Participant

Hi May I know where to find the dynamic_settings.yml file in the server?

svickers2
Community Participant

The dynamic_settings.yml file should be found in the config directory.

yuling3086
Community Participant

I had change the dynamic_settings.yml at this path "/opt/bitnami/apps/canvaslms/htdocs/config",but now my whole canvas have 504 Gateway error.

I just change the development section to production.

I had restart the server.