Linking to External Tools from a VLE/LMS: IMS LTI, oAuth or Webauth (or any other web-based Single Sign-On)?

WebLearn (Sakai) offers a number of technologies for people wanting to interoperate with external tools and services. This post attempts to explain each option and then make a suggestion as to which one should use.

Thanks to Matthew Buckett for proving the initial commentary.

IMS Basic LTI

In essence IMS LTI (Learning Tools Interoperability) is a session migration mechanism It allows someone who is currently using WebLearn to click on a link to a remote website and for details about the current session to be securely sent to the remote website. The details that are sent can include:

current user details (ID, email, name, status)
current site details (ID, title)
current user role in site
source service information (service name, URL)

Chuck Severence’s ‘ring of LTI compliance’ tattoo

This allows the remote learning tool (or website) to create a session locally for that user and then return a page appropriate to them.

Typically a tool that supports LTI will use the site ID to provide data specific to that site and will use the role to decide what actions the user can perform.

All LTI tools must be set up by the central WebLearn team, we cannot yet provide a preconfigured LTI tool on the Site Info > Edit Tools page.

Medical Sciences make extensive use of IMS LTI to provide access to their iCases tool. (iCases give students the opportunity to interact with experimental data in a realistic context.) Each instance of an LTI tool maps to a single iCase – the mapping between the tool and the iCase is held in the iCases database. This means that before an LTI link in WebLearn will work, somebody with the maintain role must first configure and store the connection.

Medical Sciences have also used LTI to connect to their own installation of the testing engine QuestionMark Perception.

OAuth

OAuth allows extra credentials to be created to grant a 3rd-party application access to your account once the application has been authorised. These extra credentials will typically have restricted permissions on compared to regular access. Once set-up the 3rd party service can request data on behalf of the current user.

Mobile Oxford uses oAuth to communicate with WebLearn.

The first time you try to use WebLearn via Mobile Oxford you supply your Webauth credentials to say that you authorise Mobile Oxford to (use oAuth to) communicate with WebLearn on your behalf. This authorisation lasts a very long time and means that it is not necessary to re-login each time WebLearn is accessed.

Mobile Oxford acts as a broker between the user’s phone and WebLearn. The user’s phone makes requests to Mobile Oxford, Mobile Oxford then decodes the request and asks WebLearn for relevant data using oAuth as the authentication mechanism, WebLearn checks the credentials and permissions and then returns data to Mobile Oxford which the constructs a web pages and sends it to the user’s phone.

The Blavatnik School of Government’s iPad App also uses oAuth to authenticate with WebLearn.

The WebLearn team will need to set up the 3rd party application as a client before oAuth can be used.

Webauth

These technologies are web-based authentication mechanisms generally implemented as an Apache module. Obviously we use Webauth at Oxford which is used for authentication by people with Oxford SSO accounts. After authenticated with WebAuth web applications can only retrieve the SSO username; the user must also dismiss the ‘green tick’ page.

The username can then be used in conjunction with the Oak LDAP or Core User Directory to retrieve further details such as affiliation or status.

The above description applies to similar technologies such as CAS (Central Authentication Service, an Apereo project), Pubcookie and many others.

Shibboleth is also similar but has the potential to allow logging in by users from external institutions.

Which Technology To Use?

All the above sounds very good but how does one decide upon the most appropriate technology? It is this question that prompted me to post.

LTI is very useful when you have an external tool that you want to integrate into WebLearn, it allows the tool to be aware of the context (originating site) within WebLearn. If the tool is only accessible via LTI then it means that the user will always have to visit WebLearn first.

WebAuth is useful when you have an application that you want to make accessible to Oxford users but don’t require any integration with WebLearn.

OAuth is useful if you want to grant an application access to data in WebLearn but don’t want to have the user interact directly with the application. It is also useful if you want to perform operations against WebLearn from a 3rd party system on behalf of the user when the user isn’t actually logged in.

It is entirely possible and sometimes desirable, to use two or even all three approaches at the same time. As an illustrative example: you may have a quiz tool which you protect by Webauth. Once logged in, a student is faced with a list of tests and they are told to click on a particular link to take the test. The tool is also an LTI ‘end-point’, when students visit the tool via WebLearn, there is some logic that looks at the WebLearn site ID and automatically loads the correct test.

WebLearn Blog