LTI Context Handoff

[thebradbain]

Hi all! As today is my last day as an intern 😭, I've done my best to give a quick overview of all the code around the LTI integration.

Overview

GitHub Classroom now integrates with LTI-capable LMSs (specifically versions 1.0 and 1.1). @philipbremer has previously provided a thorough overview and roadmap.

The code

Project-board tracking the creation of the integration

The code in Classroom can be split into two general spheres:

1. General LTI library code
To keep things clean, non-GitHub-Classroom-specific code for authorizing an LTI-launch, requesting information from an LMS, and signing/persisting/retrieving LTI messages is stored within lib/github_classroom/lti. This code makes no assumptions about GitHub classroom itself, so it could even easily repackaged into its own gem and used in other places, if there were ever a reason or desire to do that.

We've also created a custom LTI OmniAuth strategy to keep the authorization process much the same as how we already authenticate with GitHub. It's pretty short and straightforward and can be viewed at lib/omniauth/strategies/lti.rb.

Also of note is that this functionality itself is built on top of the MIT-licensed Instructure's IMS-LTI gem, which is a collection of robust models and utility classes for dealing with LTI functionality (Instructure is the company behind the ever-popular open-source Canvas LMS).

2. Integrating LTI functionality with GitHub Classroom
This is the code which uses the general LTI library code to integrate with GitHub Classroom, such as importing the rosters and creating a connection between an LMS and a classroom.

• LtiConfiguration is a model which belongs to a classroom and contains all information relevant to a connection between an LMS and a classroom organization, such as the consumer_key and shared_secret. This model also tracks the type of LMS being connected to, making determining LMS-specifc attributes more manageable, such as specifying a readable name of the platform (e.g. "Canvas", "Moodle", "Sakai"), platform logos, etc. These settings classes are available within app/models/lti_configuration (and all inherit from GenericSettings).

• SessionsController handles the authorization handoff from an LMS in controllers/sessions_controller/lti_dependency.rb. Nothing too complicated here, just tying together our OmniAuth strategy with how we manage sessions. In short, the handoff looks like:

  • An instructor launches GitHub Classroom from their LMS (this only needs to be done once)
  • GitHub Classroom will ensure the LMS request is valid
  • GitHub Classroom ties the LMS information from the launch to the classroom containing the same unique consumer_key from the LMS.
  • Handoff complete!

• RostersController handles the importation of students from an LMS in controllers/rosters_controller/lti_dependency.rb. Here we are simply relying upon GitHubClassroom::LTI::MembershipService to properly fetch and parse membership from an LMS, and then creating roster entries based on that information through the normal flow.

Next steps & stray thoughts

LTI Support
We currently support LTI 1.0 and 1.1. However, LTI 1.3 was just released this summer -- a lot of LMSs don't yet implement it, but it could be something we'll be interested in. There's more information re: LTI versions on the LTI Certification issue. We should also keep in mind that we must renew our certification annually.

AWS Provisioning
For any future development and testing, we will probably want to set up shared AWS instances on EC2 via AMI (Amazon Image Marketplace). It's a very simple process (should take less than an hour to setup all three of Blackboard, Moodle, and Canvas), but I've been encountering some delays figuring out the correct permissions/entitlements. More information of what this process looks like is available on the corresponding issue on security-iam.

Assignment Syncing
I have an (old) spike around what assignment-syncing could look like on the lms-assignment-sync-spike branch. My thought process here was that an educator could easily drop an assignment invite link in their LMS much the same way they might send out the assignment invite link via email, and that when students click it via their LMS it'll direct them to the relevant assignment in the exact same way as clicking the invite link. This would also enable us to immediately tie an LMS-student's github account to a roster entry (or create one if it doesn't exist), since we would now have both the authenticated github student and the LMS student information from launch -- which is exciting
because we could skip the manual "link to a github account" step and even autocreate roster entries in the case the LTI Membership Service is not available (e.g. Blackboard, at least in the way we expect, for now) or not enabled by an institution's ITS department. It may also be a solution to only restricting classroom invitations to a whitelisted set of users so not just anyone can join a teacher's classroom.

Goodbye (at least for now!)
Finally, I'd like to say THANK YOU for being such an awesome team this summer, and allowing me to grow not just as a developer but as a Hubber and a person 💖 ❤️ . I'm super proud of all the work I've accomplished both on and outside of this project, but the real highlight was getting to work with all of you! Super excited for the future of Classroom, Education, Ecosystems, and GitHub itself.