Learning Tools Interoperability

What is?

Interoperability of learning tools is an initiative managed by the IMS Global Learning Consortium that seamlessly integrates the learning applications used by instructors in courses. It includes a standard protocol to establish a trusting relationship between the tool provider and the Learning Management System, so that students and teachers have a seamless and integrated experience when using the tool in the context of the course. To learn more, see the IMS Global Learning LTI article..

HUB.Educational - Integration with the LTI 1.1 Standard

Integration with HUB.Educational allows users from different schools to access their partner educational tools from a centralized platform, with a single access - Single Sign On (SSO). The HUB.Educational achieves this functionality through the implementation of the LTI Launching functionality (LTI Launch). The tool must implement a secure POST endpoint by OAuth1 to receive initialization requests. When a system user requests an application to start, the HUB builds, and signs an LTI message, which is sent to the application's start endpoint. After the necessary validations, the tool should display the resources to the user.

This document will serve as a presentation of the integration pattern and an implementation guide.

For the writing of this document and implementation of the LTI standard, the HUB.Educational team used the official Specification and Implementation Guide LTI 1 documentation made available by the IMS Global Learning Consortium.

In addition, the LTI Best Practices guide and also the LTI Basic Initialization: POST Parameters page can assist in the implementation process.

Contents

Integration of the Tool to the HUB.Educational

Application data

After confirming the registration of EdTech, the responsible person must register his tool in the HUB.Educational in an area reserved for approval. EdTech may add one or more tools. To have its tool integrated, EdTech must share some minimum basic information about the application. The minimum information is as follows:nformações mínimas são as seguintes:

  • Título: Title / Name of the tool displayed on the gallery card.
  • Descrição Curta: Short description of the tool displayed on the gallery card.
  • Logo: Image displayed on the gallery card.
  • Descrição Longa: Text presented in the detailing of the tool.
  • Site: URL for Edtech website or tool.

LTI initialization data

LTI uses OAuth1 as a security framework to validate startup requests. Edtech must register the HUB.Educational as an OAuth1 client in its application and inform the HUB.Educational of the OAuth credentials necessary for the LTI communication. The information is as follows:

  • Client id (client id/oauth_consumer_key): OAuth Client identification generated by the tool (OAuth1 server) and used by the HUB.Educational to identify messages.
  • Shared Secret (shared_secret): A secret key, informed by the tool (OAuth server) used to sign the LTI message.
  • LTI Launch Endpoint: The address of the LTI launch interface. It must meet the basic specifications of LTI v1.1, presented in this document in the section LTI startup endpoint - POST / launch (Implementation).

LTI Standard 1.0

LTI is a standard created by IMS Global Learning Consortium to meet the demand for integrating third party applications or functionality into systems, usually school management systems. The most widely used feature of LTI, and perhaps the main one, is the LTI or LTI Launch startup, which allows a tool to be safely launched from another platform. This is the standard used for the HUB.Educational to initialize the integrated educational tools.

For security of communication between the platform and the tool, LTI uses the OAuth1 standard. An LTI tool must make one available.

Terminologies

  • Tool Consumer or Platform: It is usually a School Management System, however it can be any system that consumes a tool or a functionality of a third party application. Ex .: HUB.Educational .
  • Tool Provider: Application or tool that provides functionality, usually an educational tool. Ex: Edtech's teaching tool.
  • Consumer key: Key used to identify the customer in the OAuth1 request.
  • Shared secret: In LTI communication, the HUB.Educational uses the shared secret to sign the initialization message, on the other hand, the tool uses the secret to validate the signature of the message.
  • Context: An educational application can consist of various resources such as classes, classes, assessments, for example, which the user (student, teacher, manager, etc.) can access. When one of these resources is instantiated, or presented to the user, it is understood that this is the context in which the tool's resource is being used. In other words, the context indicates in which resource the tool should be started.
  • Resource identifier (resource link id): It is the link or identification of the context of the initialization of the application's resource, in other words, it is the field that identifies the initialization. For each resource in the application, there can be multiple resource identifiers associated, however, each identifier must be treated in a unique way, for example, if a tool provides a chat resource, each resource identifier would be a different room.

LTI Startup Request

In order for the tool to be launched from the HUB.Educational , it builds and signs an LTI message,

  • HUB.Educational creates, signs and sends the initialization package that is sent through the user's browser via HTTP POST.
  • Data is passed through the POST request parameters.
  • Parameters can include data on startup context, user identification, user role, among others.
  • Connection is ensured by the OAuth1 standard for nonce, timestamp and signature.

Security (OAuth1)

LTI 1.1 is built on the OAuth1 security standard to verify the authenticity of the LTI initialization message. As the definition follows, the OAuth1 communication at the startup endpoint requires the HUB.Educational to be identified as the tool's OAuth1 client, for this the tool must register the HUB.Educational on its OAuth1 server and inform the HUB.Educational of the generated data, client id and shared secret, the HUB.Educational uses this information to sign the LTI message. OAuth1 is a widely known and used security standard, as the focus of this document is not to go into details of the OAuth1 standard, visit https://oauth.net/1/ for more information. See also the LTI documentation.

LTI startup endpoint - POST / launch (Implementation)

Specifications

The LTI initialization endpoint must be implemented by the tool following the specifications of the LTI standard found in the documents of Specification and Implementation Guide LTI 1. The basic endpoint has the following configurations:

  • HTTP endpoint with POST method support
  • Endpoint must verify OAuth1 signature
  • Function must validate LTI parameters received via the form, Content-Type: application / x-www-form-urlencoded.

Mandatory basic parameters:

LTI The requisition is constructed, signed and sent by the HUB.Educational . The LTI standard provides the following attributes as mandatory for the basic message. These fields identify the type of the message, the protocol version and the requested resource, in addition to the identification of the requester through the OAuth attributes, however, many other attributes can be passed, such as user identification, user pepel in the system and others. Below is the list of basic parameters for the LTI 1.1 message, for a list containing recommended and optional parameters, see: https://www.eduappcenter.com/docs/basics/post_parameters

LTI

  • lti_message_type: value must be basic-lti-launch-request
  • lti_version: mandatory value LTI-1p0
  • resource_link_id: the resource identification configured by the institutions is sent in this field.

OAuth1

  • oauth_consumer_key: OAuth1 identifier of the HUB.Educational in the tool.
  • oauth_signature_method: Method used for the signature. HUB.Educational uses HMAC-SHA1 for subscription.
  • oauth_timestamp: The consumer's current Unix time (HUB.Educational Platform).
  • oauth_nonce: A unique value for the request.
  • oauth_version: Must have a value of 1.1.
  • oauth_signature: Signature of the message generated with the shared secret.
  • oauth_callback: Return address of the tool, which is the website to be accessed when exiting the tool. This field is not used in the LTI standard, however HUB.Educational will send your homepage address just to be in accordance with the OAuth1 standard.

Receiving an LTI Startup Request

  • lti_message_type: value must be basic-lti-launch-request
  • lti_version: mandatory value LTI-1p0
  • resource_link_id: the resource identification configured by the institutions is sent in this field.
  • user_id: User ID on HUB, unique on platform
  • roles: User role

HUB Custon Params

HUB.Edu sends some custom fields to help edtech search for user data or identification of the school where the user belongs or even the redirection to a specific activity that the user intends to access. Not all fields will be sent in requests. See below:

  • custom_school_hub_id: School ID on HUB.Edu
  • custom_school_user_id: user registration at school, can be repeated by different user roles
  • custom_url_redirect: URL to redirect user after login performed. It can be sent by edtech via parameter

On Demand Integration

In the edtech on demand integration mode, additional parameters will be sent. See below:

  • license_hash: MD5 hash for license activation. ex: 0b02bf62-a6ee-44e1-9a88-15945c67ea18

Resource display after valid LTI boot

After verification, if the initialization message is validated, the tool should return the requested resources to the user. The way in which resources are presented varies from application to application. It is very likely that your application has its own user management and authentication, in which case you must implement all the necessary steps for the final display of the resource to the student or user, for example:

  • User session survey
  • Instantiation of the class / exam / course
  • Etc

Usually, the resources are returned in the form of an HTML page with a class, course, or other resource, for the user to use.

Implementations

Flow

1645

User flow login SSO

We have a walkthrough showing how to do LTI validation using Python or NodeJS. HUB.Educational - Example of LTI Tool

Examples of implementations can be seen in our public repository on GitLab - https://gitlab.com/hub-educacional-public/lti-examples