Sharebar?

Learning Tools Interoperability as a SSO Mechanism

Printer-friendly version

Learning Tools Interoperability® as a SSO Mechanism

A single sign-on (SSO) system allows users to enter their credentials (typically a username and password) once to gain access to multiple systems.  This allows organizations to provide seamless environments for their users across all their platforms as well as, in some cases, services provided by third parties.  For these to work, each system needs to have access to the same identity provider server; this can make it complicated to implement especially when external systems are involved.

Whilst LTI® is not primarily designed as a SSO mechanism, some of the data it passes in a launch request are about the user. Moreover, LTI works on the basis of a trust relationship between the systems which is established by means of a key and a secret - much simpler than providing access to a common identity server.  In LTI a user is authenticated by a primary system (such as an LMS) and then can be passed to another system (internal or external) by way of a signed launch message.  The system receiving this message can verify its authenticity by inspecting the signature and then implicitly trust the data it carries; there is no need for the user to be authenticated a second time or for their identity to be checked against another system.  This approach can make LTI a low cost alternative to implementing SSO between systems.

Tool Consumers

The tool consumer is the source of the LTI launch request.  For SSO-purposes it must know who the user is, but little else.  The tool consumer could be a traditional LMS or portal which users have logged into, or it could just be a script protected by an SSO mechanism which is not shared by the tool provider (the destination of the launch request).

SSO from a web-based application

The assumption here is that the user has already authenticated to the web-based application which will act as the tool consumer.  The method of authentication does not matter (it could be a direct login or using an SSO method, for example), what is important is that the application knows who the user is and has a unique reference by which to identify them.  The process of launching a user into a tool provider application would adopt the following steps:

  • the tool provider application issues the application with a consumer key and secret and provides the URL to which launch requests should be sent;
  • the tool consumer application writes a script which generates an LTI launch request;
  • a link to the script is made available to users within the tool consumer application;
  • when a user follows the link the script returns the LTI launch form which causes them to be redirected to the tool provider;
  • the tool provider application verifies the authenticity of the launch message received and extracts the user-related parameters it needs;
  • the tool provider application now knows who the user is and can establish a session for them.

An LTI launch message is simply a hidden web form inserted into a web page returned from the tool consumer which is then submitted by the user's browser to the tool provider as an HTTP POST request. There are no other systems involved in the connection and the URL, key and secret are all that are required to establish the trust relationship between the systems so the tool consumer can safely pass on the user details based on the authentication already performed.  At a minimum the tool consumer should be able to pass on a unique user ID, but will quite likely have access to additional data about the user which it could also forward if it is of interest to the tool provider; for example:

  • name
  • email
  • address
  • telephone number

The LTI specification includes a number of standard parameters for user-related data, as well as defining a set of custom parameter substitution variables which can allow the tool provider to request specific data items (provided the variable is supported by the tool consumer).  For example, to pass a the username and country for a user, the following custom parameters could be defined:

username=$User.username
user_country=$Person.address.country

This would cause two additional parameters (named custom_username and custom_user_country) to be included in the launch.

Such launch messages are no different from standard LTI launches, so if the tool consumer already supports LTI then it will, by definition, be able to support the use case described here.  It should not matter if the launch message includes other parameters (e.g. about the tool consumer or context); these can merely be ignored by the tool provider if they are of no interest.

SSO from a web-based script

Since an SSO mechanism is essentially only used to provide an application with the identity of the user, there is no requirement for the LTI launch message to be generated from within an application.  Any script which has access to the user's identity could be used to generate an LTI launch message.  By definition this means any script which is itself protected by an SSO mechanism is a candidate.  There is no need for the tool provider to support this SSO mechanism or have access to the same identity provider; the tool provider will receive its data via a simple HTTP POST request.  A sample SSO-LTI script is available from OSCELOT to illustrate this approach which involves the following steps:

  • the organization acting as the tool consumer needs to set up a web server with a script area protected by their SSO mechanism;
  • a script is placed in the script area which generates an LTI launch form for submission to the tool provider (any web scripting language can be used);
  • a link to the script is made available on a web page (or circulated to relevant users) so that they can follow the LTI connection to the tool provider.

The script has four main tasks to perform:

  1. Obtain the ID for the user (typically this is available from the REMOTE_USER environment variable).
  2. Collate the parameters for the LTI launch message; at a minimum these would be:
    • lti_message_type
    • lti_version
    • resource_link_id (this may be a static ID to represent launches from this script)
    • user_id
  3. Sign the launch message parameters using OAuth 1.
  4. Return an HTML page containing a hidden web form comprising all the of the launch parameters (including those added by OAuth) and a Javascript statement to automatically submit the form.

Thereby, such a script can be used to translate an SSO authentication into an LTI launch, passing the same user ID as employed by the SSO mechanism.

Tool Providers

A launch request from a tool consumer is received by a tool provider.  This can be any web application capable of handling HTTP requests.  For the purposes of SSO, all a tool provider needs to do is verify the incoming message and extract the parameters regarding the user.  The process of verifying a message is relatively straightforward and requires only code on the tool provider server; it does not require access to any other servers or changes to firewalls for it to work.  More details can be found in the section on verifying LTI launch messages.

None of the parameters about a user are required to be passed by the LTI specification, but certified tool consumers should be expected to be able to pass the following parameters:

  • user_id - a unique ID for the user (within the scope of the consumer key) which is only used as an identifier by the tool consumer system;
  • lis_person_contact_email_primary - the email address of the user;
  • lis_person_name_family - the user's lastname;
  • lis_person_name_full - the user's full name;
  • lis_person_name_given - the user's firstname;
  • lis_person_sourcedid - a unique ID for the user (within the scope of the consumer key) which is used for provisioning systems (e.g. originates from a Student Information System).