Verifying Signature in LTI launch when there are query parameters

[justinball]

We recently had a situation where we added query parameters to an LTI launch URL. Doing so caused our signature verification to fail. It appears that Canvas generates a signature using the only the domain and path and doesn't include the URL query parameters. We're using the IMS-LTI gem which generates the signature using the entire URL including the query parameters. That means that the signatures don't match and the LTI launch fails.

I'm not sure whether the spec requires that the query params be included or not. Just posting here so that others building LTI tools are aware of how the process works in case they run into issues.

Thanks!

Justin

[pklove]

Our test tool includes query parameters in its signature verification and it launches fine from Canvas when I add query parameters to the LTI Launch URL.

So maybe its a problem with something in IMS-LTI gem or something in Canvas.  Perhaps there is a bug somewhere that shows up with your particular parameters.

What does your query string look like?

[justinball]

That's interesting.

The query string we added was really simple, something like ?id=3. We have tried it with a number of different query parameters with the same result each time.

I would guess the tool that you are using also excludes the query string when generating the signature. I haven't dug into the spec so it's entirely possible that the query string is meant to be excluded from the generation of the signature. 

We debugged down into the code in the ims-lti gem and found that removing all query params resulting in matching signatures which is why we concluded that Canvas generates the signature without the query while the ims-lti uses the query.

Thanks!

Justin

[pklove]

We definitely include the query parameters as part of the signature verification process -- I just deleted them and it failed.  They need to be part of the normalised parameters in the base string.

See, for example http://lti.tools/oauth/ :

" The parameters are collected from three locations: the URL query element (as defined by RFC 3986 section 3), the OAuth 'Authorization' header (excluding the 'realm' parameter), and parameters included in a single-part 'application/x-www-form-urlencoded' POST body (as defined by HTML4). "

May be IMS-LTI gem is getting it from the URL anyway and it was adding it twice or something?

[pklove]

Also note that when you have a query string on your URL, Canvas also put the query parameters into the post parameters, so you can end up with it twice in the verification code unless you are expecting this.

I'm guessing this might be the case here.  You can remove the query parameters because they are also in the body parameters.

[justinball]

I found a bit more information in the documentation here:

Importing Extended Tool Configurations - Canvas LMS REST API Documentation 

By default, Canvas handles LTI launch URLs with query parameters by including the query parameters in the URL and the post body. This can result in a signature mismatch if not accounted for. The oauth_compliant parameter allows an external tool provider to specify how it wants Canvas to handle launch URLs with query parameters: if set to true LTI query parameters will not be copied to the POST body.

So it looks like Canvas is flexible in how it generates the signature and setting the "oauth_compliant" parameter to true will fix the issue we saw.

Here's an example xml config from the docs:

<?xml version="1.0" encoding="UTF-8"?>
<cartridge_basiclti_link xmlns="http://www.imsglobal.org/xsd/imslticc_v1p0"
    xmlns:blti = "http://www.imsglobal.org/xsd/imsbasiclti_v1p0"
    xmlns:lticm ="http://www.imsglobal.org/xsd/imslticm_v1p0"
    xmlns:lticp ="http://www.imsglobal.org/xsd/imslticp_v1p0"
    xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation = "http://www.imsglobal.org/xsd/imslticc_v1p0 http://www.imsglobal.org/xsd/lti/ltiv1p0/imslticc_v1p0.xsd
    http://www.imsglobal.org/xsd/imsbasiclti_v1p0 http://www.imsglobal.org/xsd/lti/ltiv1p0/imsbasiclti_v1p0.xsd
    http://www.imsglobal.org/xsd/imslticm_v1p0 http://www.imsglobal.org/xsd/lti/ltiv1p0/imslticm_v1p0.xsd
    http://www.imsglobal.org/xsd/imslticp_v1p0 http://www.imsglobal.org/xsd/lti/ltiv1p0/imslticp_v1p0.xsd">
    <blti:title>Protractor Tool</blti:title>
    <blti:description>This tool provides an online, interactive protractor for students to use</blti:description>
    <blti:launch_url>https://example.com/tool_redirect?query_param=some_value</blti:launch_url>
    <blti:extensions platform="canvas.instructure.com">
      <lticm:property name="oauth_compliant">true</lticm:property>
      <lticm:property name="privacy_level">public</lticm:property>
    </blti:extensions>
</cartridge_basiclti_link>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Thanks for your help!

Justin

[pklove]

Thanks for posting this.  I actually thought it might be a bug that we'd just had to workaround so our tools would work with Canvas as well as other LMSs.  But its clearly intended.  Good to know about the oauth_compliant parameter.

I wonder why the default is to put the query parameters are into the post body.  There must be some reason/history around this.

[norihisa_ando]

Hi

i try to integrate ims global lit sample with my open source canvas as well as sass version.

first of all I need to increase value volume of table called lti2_nonce from varchar(32) to vachar(64) as Canvas returned value length is too long.

however I still got signature error.

canvas send signature which is different from lti ims lit library expected. Then it always result of invalid signature.

basicaly moodle integration is ok and signature moodle send and lit library expect is always matched.

i also set oauth_ compliant  true in xml configuration. But the result is the same. 

Canvas as always send wrong signature to lit provider.

what do I miss?

anybody make canvas integrate with IMSGlobal lit sample ?  

[johnweisz]

I know this is several years later, but I noticed that while Canvas does add the query parameters to the request body and as previously stated this must be included in the OAuth signature validation, it seems to not include the query parameters in the request uri for validation; therefore, in my case if I included the parameters in the request uri for signature validation it failed.  When I removed the parameters and verified the OAuth signature with just the base launch uri it worked.  Hope this helps someone, kind of unexpected behavior.