This change cleans up the work in progress request at https://github.com/edx/edx-platform/pull/8176
This is an initial authentication implementation that allows LTI users to log in transparently to
edX. The behavior is driven by pilot users at Harvard; this was the most requested feature.
The patch creates a new database model that maps users' LTI identifiers to newly-created edX
accounts. If an LTI launch comes in with a user_id field that is not in the database, a new edX
account is created with a random user name and password. This account is then stored in the database,
so that it is permanently associated with the LTI user ID.
This patch takes a simplistic approach to session management. If a user is logged in with a
different account when they perform an LTI launch, they will be logged out and then re-logged
in using their LTI account.
In order to keep the patch simple, I have split out some refactoring that needs to be done into
a separate branch that I'll post once this has been merged. Since we no longer redirect to the
login page, we don't need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that requires. There are
also multiple fetches of the LtiConsumer object (one in the view, one in the signature
validation) that the later patch will consolidate into one.
The line below was left in during the refactoring shuffle from PR #8205, and causes
an issue in a corner case where an LTI launch provides an instance GUID where there
wasn't one already set for the consumer. This change fixes the bug, and adds a test
to prevent it from recurring.
This change allows the LTI provider to pass grades back to the campus LMS platform using the
LTI outcome service. For full details of the outcome service, see:
http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html
In brief, the LTI 1.1 spec defines an outcome service that can be offered by an LTI consumer.
The consumer determines whether a score should be returned (in Canvas, this means that the LTI
tool is used in an assignment, and the launch was performed by a student). If so, it sends
two additional parameters along with the LTI launch:
lis_outcome_service_url: the endpoint for the outcome service on the consumer;
lis_result_sourcedid: a unique identifier for the row in the gradebook (i.e. the tool/student/assignment combination).
The LTI Provider launch view detects the presence of these optional fields, and creates database
records for the specific Outcome Service and for the graded LTI launch. Later, when a score on
edX changes (identified using the signal mechanism from previous LTI Provider pull requests),
a Celery task is launched to pass the score back to the LTI consumer.
