SimpleLTI - Developer Web Site

The basic idea is that the LMS has a proxy tool that provides an endpoint for an externally hosted tool and makes it appear if the externally hosted tool is running within the LMS. In a sense this is kind of like a smart “iFrame” tool that can host lots of different content.

The proxy tool provides the externally hosted with information about the individual, course, tool placement, and role within the course.

In a sense the Proxy Tool allows a single-sign-on behind the scenes using REST-style web services and allows an externally hosted tool to support many different LMS’s with a single instance of the tool.

For the rest of this document we will use the term “Proxy Tool” to indicate the tool in the LMS and “External Tool” to indicate the tool that is hosted externally and being presented within the context of the LMS.

Architecture

The architecture focuses on the launch phase of the LMS-to-tool interaction. The launch accomplishes several things in a single REST-style web service call

Establish the identity of the user (effectively like a single sign-on)
Provide directory information (First Name, Last Name, and E-Mail address) for the user
Indicate the role of the current user whether the user is an Administrator, Instructor, or Student
Provide information about the current course that the Proxy tool is being executed from such as Course ID and Course Title.
Provide a unique key for the particular placement of the Proxy Tool
Securely provide proof of the shared secret
Hints as to display size
An optional URL of a resource which is stored in the LMS – which is being provided to the external tool as part of a launch – for example – this might be a SCORM object which the external tool is supposed to download and play.

The steps of provisioning are quite simple. When the user selects the proxy tool in the LMS, the LMS makes a connection to the URL of the External tool. The Proxy tool sends an XML document with the above information as POST data to the URL. The shared secret is used to produce a time stamped has using the Nonce (http://en.wikipedia.org/wiki/Cryptographic_nonce) approach to shared secrets – the encoded material is sent as a Header on the HTTP request to the External Tool.

When the External Tool receives the request, it first validates the security using the header values. If the security passes, the External Tool does any any necessary creation of a user account, optionally stores/updates the course and user directory information. After the course context and user context are established the external tool does any necessary provisioning of a session and returns a URL to the Proxy Tool.

The Proxy Tool then places the URL in an iFrame (or perhaps starts a proxy operation on the URL) and the user sees the tool and uses the tool.

In effect this is very similar to a simple iFrame tool except for a single HTTP exchange to establish identity, course context, and session context.

Within this – the external tool has a great deal of latitude in how it interacts with the user – it can send any URL back – the URL which the External Tool sends back may not bear any resemblance to the URL used by the proxy tool to send the XML data to the External Tool.