The LTI Tool Provider module (lti_tool_provider) allows a Drupal site to serve as a Learning Tools Interoperability (LTI) Tool in any Learning Management System (LMS) supporting the LTI standard. (http://developers.imsglobal.org/)
Example LTI compliant LMSs are Angel, Blackboard Learn, Moodle and Sakai.
Example Use Case
I am a course instructor and I want to have a FAQ facility where students can ask and answer questions like stack overflow. Someone tells me about a great drupal module that does just this, but my course is running in Bb.
I build a Drupal site using the module. It could be hosted at my uni or in the cloud. Before LTI I would put a link to this site in my course and students would have to register and get accounts set up or I would have to do some sort of authentication integration with my uni systems. But still the students would see that they are leaving Bb and going to a separate site.
With LTI I can install the LTI Tool Provider module, and make the link in my Bb course a LTI link. Then when students click the link, they do not leave Bb, but the FAQ is embedded in Bb and they are already authenticated.
Now some other instructors at my uni see what I've done and ask to use my tool. I don't want to have to run a separate drupal site for every course, so I install OG and turn on the LTI Tool Provider OG submodule. Now any instructor at my uni can put a FAQ link their course and they get their own FAQ separate from mine.
Word spreads and other Unis want to use my tool, so I register their LMS systems as additional Consumers and send them the key/secret so they can integrate with the tool.
Now I want to give my students some marks for participation, so I install Rules and LTI Tool Provider Outcomes, then create a rule that counts the number of Questions and answers a student has created weighted by the number of votes to compute a score. The rule calls the LTI set outcome action and my students now get this participation score sent back into the Bb gradebook. All the other users of the FAQ system can also get this function.
I could even add a pay wall and set my system up as a Tool as a Service.
Any functionality that you can build in Drupal that is useful within the context of a course, is a candidate for creating an LTI tool.
It is easy to publish a tool you create as a service or as a Drupal Feature, module or distribution. In the future you may also be able to package up your course as a common cartridge, with LTI tool links included, as another distribution mechanism.
First steps to integration
Consumers and Providers
LTI stands for Learning Tools Interoperability and deals with Learning Management Systems such as Learn, Moodle, Angel or Sakai, and Learning Tools which could be almost anything useful within a learning environment e.g. a blog, FAQ, peer review system, team management, quizzes, etc.
LTI defines two components which interoperate, the Tool Consumer which is usually a feature, building block or plugin inside a LMS, and the Tool Provider which is the integration component within the Tool. It is best to just think of the Consumer as the LMS and the Provider as the Tool.
LTI uses the OAuth 1.0 protocol to secure the communication between Consumer and Provider. This depends upon each Consumer/Provider pair sharing a key and a secret. When the Consumer launches the Tool it includes the key in the data communicated and signs the communication using the secret. The Provider uses the key from the communication to find the corresponding secret from its internal store and can then verify the signature. So the first task when integrating Consumer and Provider is to pick a key/secret and register them in both systems.
To register a key/secret in a Drupal Tool Provider, you create a Consumer entity in the admin/config/lti-tool-provider/lti-tool-consumers configuration page.
You can register multiple consumers if your tool is going to be accessed from different LMS systems, but each must have a unique key.
It is beyond the scope of this documentation to show how to register a Tool Provider in all the different LMS systems, but you may need to be an administrator in the LMS or you may be able to do it as an instructor depending on the LMS configuration. Either way you will need the key/secret. You will also need the launch url of the tool, which is of the form
Security Note: OAuth relies on the https protocol for security. Production sites should be configured to support https at least to the
https://drupalprovider.example.com/lti path used to launch the tool. http should only be used for testing. Consumers may enforce this requirement.
When the Tool is launched from a Consumer the LTI Tool Provider module will try to match the user identified in the LTI data with an existing Drupal user account using the User ID or the users email. Failing a match, a new Drupal user account will be provisioned automatically.
When you add a Consumer you can also specify a domain and opt to use a dummy account for unidentified users. The domain can be left blank if you are only supporting a single Consumer, but if you have multiple consumers and want to prevent user ID clashes between them, a non-null domain gets appended to the user ID.
If users with ID = 12345 come from both Consumer1 and Consumer2 they will be mapped to the same user account with name = 12345 in the tool.
If users with ID = 12345 come from both Consumer1 and Consumer2 they will be mapped to the different user accounts with name = 12345@c1 and 12345@c2 in the tool.
Some LMS systems might be configured to not identify users to your Tool and so the dummy account option is provided to map those users to the account with name = lti_user or lti_user@domain if domain is specified.
LTI Integration may provide your Tool with additional user attributes beyond the ID we discussed above. The possible LTI attributes for users are lis_person_contact_email_primary, lis_person_name_given, lis_person_name_family, and lis_person_name_full. The LTI Tool Provider will automatically map the
lis_person_contact_email_primary to the account mail field. If no value is present a unique email of the form firstname.lastname@example.org is constructed because Drupal requires there be a value for the account mail field. The other three name attributes can be mapped to any text field on the Drupal user entity on the configuration page admin/config/lti-tool-provider/user-attributes. Out of the box Drupal does not have any such fields, but you can easily add fields to the user entity at admin/config/people/accounts/fields.
The user ID that comes via LTI is often just a big number or string of random characters, it will be better for your users if they see themselves identified by name in your Tool. You can easily achieve this by adding a fullname field to the user entity, mapping lis_person_name_full to the fullname field and then installing the realname module, and setting the fullname field as the realname. Users then will only see their fullname and the LTI user ID will not appear in the user interface.
Most LMSs will provide roles for different users such as students and teachers. In the Consumer these LMS roles are mapped to LTI roles and the LTI roles a user has are communicated to the tool. In Drupal we have authenticated user and administrator roles pre-defined and you can add additional roles and set their permissions in the usual places. The LTI Tool Provider module has a Global Roles configuration page admin/config/lti-tool-provider/global-roles where you can map the LTI roles (Learner, Instructor, ContentDeveloper, Member, Manager, Mentor, Administrator, TeachingAssistant) to any of the defined Drupal roles.
Your LMS may not have roles that correspond to all of the LTI roles, so you really only have to map those that will be used.
If your tool is only going to deal with one type/brand of LMS, it is less confusing for users if you make the Drupal Roles the same as the LMS roles. E.g. If you have LMS Roles (Student and Teacher) that are mapped at the Consumer to LTI Roles (Learner and Instructor), you could define Drupal roles (Student and Teacher) and have LTI Tool Provider Global Roles mappings Learner -> Student and Instructor -> Teacher. The result is a Student in the LMS is a Student in the Tool and a Teacher in the LMS is a Teacher in the Tool.
Note: If you are going to support multiple courses in your tool, see the Groups section below, you should read that fully before you decide on Drupal roles and Global Roles mappings, because the roles in your Tool may be best configured as Group Roles rather than Drupal Global Roles.