Problem with LTI Dynamic Registration on beta

[ColinMurtaugh]

Hi --

We've noticed that LTI Dynamic Registration in our beta instance seems broken. The `openid_configuration` that we're receiving back from Canvas contains a `registration_endpoint` of "https://sso.beta.canvaslms.com/api/lti/registrations" instead of the expected "https://canvas.instructure.com/api/lti/registrations".  The sso.beta.canvaslms.com URL doesn't work. 

We're only seeing this in the beta environment so far, but I'm concerned that this bug will get pushed to production.

cc: @xmoffatt 

--Colin

[xmoffatt]

Well that is super concerning - do you have more info about what doesn't work? like repro steps or an example response or dev tool screenshot?

We _do_ want the correct url that points to beta so that your registrations get created there, but it looks like there is something we are missing

[ColinMurtaugh]

The openid_config that we're getting from Canvas is: 

{'issuer': 'https://canvas.beta.instructure.com', 'authorization_endpoint': 'https://sso.beta.canvaslms.com/api/lti/authorize_redirect', 'registration_endpoint': 'https://sso.beta.canvaslms.com/api/lti/registrations', 'jwks_uri': 'https://sso.beta.canvaslms.com/api/lti/security/jwks', 'token_endpoint': 'https://sso.beta.canvaslms.com/login/oauth2/token', 'token_endpoint_auth_methods_supported': ['private_key_jwt'], 'token_endpoint_auth_signing_alg_values_supported': ['RS256'], 'scopes_supported': ['openid', 'https://purl.imsglobal.org/spec/lti-ags/scope/lineitem', 'https://purl.imsglobal.org/spec/lti-ags/scope/lineitem.readonly', 'https://purl.imsglobal.org/spec/lti-ags/scope/result.readonly', 'https://purl.imsglobal.org/spec/lti-ags/scope/score', 'https://purl.imsglobal.org/spec/lti-nrps/scope/contextmembership.readonly', 'https://purl.imsglobal.org/spec/lti/scope/noticehandlers', 'https://canvas.instructure.com/lti/public_jwk/scope/update', 'https://canvas.instructure.com/lti/account_lookup/scope/show', 'https://canvas.instructure.com/lti-ags/progress/scope/show', 'https://canvas.instructure.com/lti/page_content/show'], 'response_types_supported': ['id_token'], 'id_token_signing_alg_values_supported': ['RS256'], 'claims_supported': ['sub', 'picture', 'email', 'name', 'given_name', 'family_name', 'locale'], 'subject_types_supported': ['public'], 'authorization_server': 'sso.beta.canvaslms.com', 'https://purl.imsglobal.org/spec/lti-platform-configuration': {'product_family_code': 'canvas', 'version': 'vCloud', 'messages_supported': [...], 'notice_types_supported': [...], 'variables': [...], 'https://canvas.instructure.com/lti/account_name': 'Harvard University', 'https://canvas.instructure.com/lti/account_lti_guid': '7db438071375c02373713c12c73869ff2f470b68.harvard.instructure.com'}}

Then, when we POST our registration data to https://sso.beta.canvaslms.com/api/lti/registrations we get a 404 response with the content:

{
  "errors": [
    {
      "message": "The specified resource does not exist."
    }
  ]
}

 If we change the registration URL to https://canvas.beta.instructure.com/api/lti/registrations and POST the exact same data, the registration is created successfully. 

I'm doing some more testing here to see what else I can learn. 

--Colin

[xmoffatt]

Thanks, that was enough to go poke around and identify the root cause. Our team will work on fixing and deploying that in the next day or two and I will report back once it's fixed

[adityaranjan321]

Hi @xmoffatt 
Just want to mention that we are facing this issue in Production.
Our instance is on https://mentimeter.instructure.com 
In out open_id response we are getting registration_endpoint = "https://sso.canvaslms.com/api/lti/registrations" instead of "https://canvas.instructure.com/api/lti/registrations"

[ColinMurtaugh]

Yeah -- I'm actually seeing the issue in Test and Production now too. We were not seeing it in Test at least as of a couple of days ago.

[xmoffatt · Accepted solution]

@ColinMurtaugh @adityaranjan321 

Yes, this bug made it to production just yesterday, and we deployed a fix this morning! 

the registration endpoint is going to keep pointing to "sso.canvaslms.com", that is the right place for a few reasons: it's properly regionalized for Canvas, it conforms to spec better, and also behaves properly in non-prod environments. the underlying bug wasn't actually related to the URL switch, but was exposed by it.

Let me know if it's working or not for you, I fully expect it to work moving forward!

[ColinMurtaugh]

Dynamic registration is working again for me now in beta! (Will test in test and prod shortly). Thanks to Instructure for taking care of this so quickly -- much appreciated! 

--Colin

[xmoffatt]

And thanks to you for reporting it! 

[Paul_G]

Hello, thanks for the report! 

I just tested this in my beta instance, and it seems to be working for me. Can you include some more details? What is the status and body that you receive from the https://sso.beta.canvaslms.com/api/lti/registrations endpoint?