Upgrade to LTI 1.3

[joncameron]

Description

Avalon is currently using the LTI 1.1 spec for auth with Learning Management Systems, which is no longer supported and officially deprecated.

LTI 1.3 and LTI Advantage are the current specs, and Avalon should be updated to use at least LTI 1.3 to stay current and avoid potentially breaking changes that could come at any time. LTI Advantage may not be necessary or at least out of scope for this particular upgrade.

LTI Spec Page: https://www.1edtech.org/standards/lti

Done Looks Like

• [x] Investigate what is necessary to upgrade LTI auth in Avalon to LTI 1.3
• [x] Determine what code and dependencies need to be updated to accommodate for LTI 1.3
• [x] Message campus to verify that LTI 1.3 is available for integration and whether anyone is using it on campus
• [x] When does Canvas plan to deprecate LTI 1.1?

[masaball]

Currently we use a fork of the omniauth-lti gem to handle authentication. The gem is set up for an OAuth1 workflow. It does not look like there is currently a replacement for this gem. Potentially easiest approach would be to update our fork to handle OAuth2/OpenID workflows? Though changes will probably be significant, so reworking the existing fork may not be that much less work than creating a new omniauth strategy from scratch. We would also need to update parameter names to reflect the new designations in LTI 1.3 (e.x. "lis_person_content_email_primary" becomes "email") There is a list of omniauth strategy gems that include examples of OAuth2/OpenID workflows: https://github.com/omniauth/omniauth/wiki/List-of-Strategies

Migration guide with param changes: https://www.imsglobal.org/spec/lti/v1p3/migr

The omniauth-lti gem relies on the ims-lti gem created/maintained by instructure. The ims-lti gem appears to be getting used for the actual OAuth/LTI request validation? It does not say anything in the README about LTI 1.3 support and there has been no response to this issue, but there is logic in lib/ims/lti/services/message_authenticator.rb that checks JWT and there is a service for an OAuth2 client. So the most recent version of ims-lti may support minimal processing of LTI 1.3, or they may be working on it.

We will need to update config/lti.yml to reflect the new configuration expectations for parameter names and auth flow. We will need to update the Devise initializer, /config/initializer/devise.rb. We may need to change lib/avalon/authentication.rb. We will likely need to update how LTI auth is configured in config/settings.yml to match the OAuth2 changes necessary in omniauth-lti.

I think that is what will be required for basic 1.3 authorization/launch. I am unsure at this point if we will need to have any of the functionality from LTI Advantage. If so, that will add more in depth work on handling Resource messages. If anything, we may need to support Deep Linking. Instructure has an internal gem for lti-advantage for Canvas that we could potentially take inspiration from when it comes to that, or use if they eventually spin it into its own repo: https://github.com/instructure/canvas-lms/tree/master/gems/lti-advantage/lib/lti_advantage.

[joncameron]

Investigation pretty much done; can be reviewed by @cjcolvar for a sanity check about Avalon's current implementation.

[elynema]

Response from edshelp@iu.edu:

• Does Canvas as implemented at IU support LTI 1.3? YES!
• If so, is there a process we need to follow on the Canvas side to make these updates? Are there new endpoints we’ll need to use? Our recommendation with LTI 1.3 tools depends on the complexity of the tool itself.
• Are there other applications at IU using LTI 1.3? Yes, several. As the LTI v1.3 standard becomes more widely accepted, vendors are working to develop LTI v1.3 tools (timelines vary greatly by vendor)
• Is there a date for when Canvas might deprecate support for LTI 1.1? Instructure (Canvas has not released an 'official' date on when they'll stop supporting LTI v1.1, but given the number of vendors still using LTI v1.1, we don't expect this to be anytime soon.

[cjcolvar]

I think it might make sense to make a new omniauth gem with a new strategy that way it can be configured alongside the existing :lti strategy and wouldn't need to be a forced migration in the Avalon code but an opt-in to upgrade. This might mean more branching in Avalon code to handle both strategies/gems but I think it will make for easier migration instead of having to deal with it at the same time as upgrading Avalon.

[joncameron]

New issue:

• new omniauth gem with a new strategy that way it can be configured alongside the existing :lti strategy
• documentation on swapping this out or using it

[elynema]

This is probably not a requirement for implementation in 8.0. It's great that campus is excited to support us in the upgrade, and it would be great to leverage that. However, with support for 1.1 remaining indefinitely, this could be delayed if needed.

[joncameron]

Created #6031 to represent the implementation work.