I've created a test LTI Tool Provider and tested it successfully against the IMSGlobal test consumer at http://www.imsglobal.org/developers/LTI/test/v1p1/lms.php.
However, when I use my endpoint in our client's D2L test instance the oAuth signatures don't match. I suspect the signature base string generated by D2L is somehow different than mine. Is there a way to obtain the D2L tool consumer's base string for comparison?
The D2L Tool Consumer implementation has also been tested successfully against the IMS reference implementations. However, registering and configuring an external learning tool in the Learning Environment is a bit of a tricky process.
In the External Learning Tools management tool you can manage the specific list links (which, when embedded, create an LTI launch point in the LMS) as well as the list of tool provider configurations (if, for example, you have one tool provider, but want to embed a number of LTI launch links for that same tool provider). The exact UX in the Learning Environment for getting to manage these two lists of items depends on the version of your LE... in LE's that have early support for LTI, the tool provider list is hidden behind a settings gear on the External Learning Tools management page I think; on later LE's, the list of links and list of tool providers are more equally visible in the management page.
The Tool Provider list allows you to provide a key and secret for the tool provider, and to use that to sign LTI launches rather than the default key/secret configured for the Tool Consumer itself ("use custom tool consumer information instead of default").
The Link list allows you to (a) choose to sign LTI launches from a link, and (b) sign the launch with the tool consumer key/secret or one specific to the LTI link itself. Note that if you use a matching Tool Provider entry for an External Learning Tool link entry, and if that Tool Provider entry has a key/secret that's set to override the default tool consumer information, then it is this Tool Provider override key/secret that get used to sign the launch if in (b) above you choose to sign the launch with the tool consumer key/secret.
Yes, that's confusing.
So -- the launch is either signed or not signed, depending on the setting in the 'Edit Link' page for the link. If the launch is signed, then it can be signed with the 'Link key/secret', provided on the 'Edit Link' page, or it can be signed with the 'Tool Consumer key/secret'. If that last one, then it will first check for a matching tool provider entry override to provide a key/secret and if not finding one, it will use the key/secret set for the entire LE.
Once you have all that set up, from inside the 'Edit Link' page for a link, you can "preview request" to do a test-launch. You can also "preview request details" which will take you to a page that shows you what the LTI POST body form will look like -- from there you can verify if the oauth properties will show up in the launch form -- if they're not in that preview form, then your launches aren't getting signed. If the oauth properties are in the form, then you can see what will be sent and you can do debugging/testing with those values.
Thanks in part to Viktor's suggestion to preview the request, I was able to debug this.
In my Tool Provider, I am checking for certain non-required LTI parameters. When such a parameter did not exist in the consumer's request I was setting it to an empty string rather than throwing an exception.
Using the IMS test consumer I was able to discover that when I set a request parameter to an empty string, while the Tool Consumer omits the field entirely, our signatures will differ even though the two base_strings match. I still don't fully understand this; my understanding of oAuth was that two identical strings signed with the same key and secret will produce the same signature. In any case, better validation of the request parameters now ensures that our strings--and signatures--match.
