Basic LTI Portlet - Architecture

Owned by Steve Swinsburg
Last updated: Nov 08, 2011Version comment
3 min read

Basic LTI

This portlet uses Basic LTI to integrate external applications into uPortal. Basic LTI is a subset of the Learning Tools Interoperability (LTI) specification from the IMS Global Learning Consortium and allows simple (or Basic) integrations between systems. In essence, it is just a POST request, with standardised parameter names, which is then signed by OAuth. OAuth inserts a few extra parameters into the request which are then used on the receiving end to verify that the.

If you have ever worked on an integration between learning systems, you probably had to conform to some web API imposed by vendors and add parameters like a timestamp and a hash of the parameters, as well as a shared secret key on each end. Basic LTI is exactly the same concept except the bulk of the parameter names are standardised, and the security is handled for you when you ask OAuth to sign the message. Because it is a simple integration, the only data that is really required is the context_id, user_id and optionally some name information, like first name, last name and email.

The receiving end (the provider) is then responsible for ensuring the request hasn't been tampered with or replayed. The security is made up of a nonce, signature, timestamp and a shared secret key. The provider validates the message, again by OAuth, to check the signatures match, the nonce hasn't been used before, and the timestamp is within the allowed limits. If all is ok, the provider does whatever is necessary to construct a URL to the requested resource, and performs a HTTP redirect to that URL. The consumer is then able to render the response directly in an iframe.

The receiving end can also identify the request by the oauth_consumer_key parameter.The shared secret will be tied to that consumer so you can potentially have multiple consumers making requests to the same provider, each with their own shared secret. This also makes it easy to revoke privileges or change the secret as required, for individual consumers.

Individual providers can also be setup to accept additional parameters in the request. This is common place so creating a generic interface that is able to fully cater for the different data that providers can receive sounds difficult.

Adapters

This portlet uses the concept of adapters which pre-process the launch data before making the request.  This allows for the injection of special parameters, or for special massaging of the existing parameters, ie to make them upper/lowercase . This solves the issue mentioned above when a single interface is dealing with multiple providers which can potentially all accept vastly different data.

The portlet ships with three adapters out of the box.

  • standard - lets the parameters pass through untouched,
  • sakai -  performs some logic if the site requested is a user's My Workspace and adds an extra parameter so the Sakai Basic LTI Provider can find the correct site id.
  • peoplesoft - simply uppercases the user id. This is still in development and may change as we are rolling out our own Basic LTI provider for Peoplesoft.

Additional adapters are trivial to create. There is a simple interface that needs to be implemented, added to the list in the BasicLTIPortlet.java and then wired up in portlet.xml. The second step will be removed in a future release so that all adapters configured in portlet.xml are automatically registered with the portlet.