We’ve been using it experimentally for over a year now on campus at MIT, and it’s time to make it production-ready.
We have one challenge: our users already have accounts on the production system, and it’s really confusing for user with an account to find themselves logged into the same system, in a different account, over LTI. This seems like an unusual edge case for LTI, but I’m wondering if anyone has ever used it to authenticate to an existing account, instead of an anonymous one.
We serve contents from our Open edX instance to a few Moodle instances on campus through LTI.
To be honest, it has been described as experimental in the documentation for years. I wish the old documentation from previous releases was still accessible so that I could point out the “warning” in the LTI Provider section.
I have been asking for years what is the state of LTI Provider for Open edX. Especially since there was only development for an LTI Consumer XBlock through GitHub - openedx/xblock-lti-consumer
Thanks @sambapete. It’s reassuring to know that we’re not the only ones using this feature.
Do you know if any core contributors or contractors have experience with the code involved, who might be able to help answer our questions about authentication?
It appears that the LTIUser doesn’t exist the first time and therefore this create_lti_user gets called.
Seems like if the TPA > LTI Provider Configuration authentication worked that the request.user would be the TPA LTI user. This logic below switches the to the LTI User if it notices that the lti_user is not the request.user. I only see the lti_user being created during the lti_launch method and nowhere else.
You’d think that somewhere in this authentication logic for LTIAuthBackend that it would create that lti_user if it didn’t exist to avoid switching the logged in user if they authenticated over this third-party LTIAuthBackend.
I even pushed up the common.djangoapps.third_party_auth.lti.LTIAuthBackend to the top of the AUTHENTICATION_BACKENDS list to see if that authentication would run first. This Django documentation mentions that the order of these authentication backends matters because it tries the first one on the list, then if that doesn’t work it goes to the second one until a successful authentication or not is achieved.
# We have this setting enabled.
>>> settings.FEATURES['ENABLE_THIRD_PARTY_AUTH']
True
# Here is our settings for authentication backends. LTIAuthBackend is at the front of the list.
>>> settings.AUTHENTICATION_BACKENDS
['common.djangoapps.third_party_auth.lti.LTIAuthBackend', 'social_auth_backend_bigcommerce.backend.BigCommerceCustomerTrustworksAuth', 'social_auth_backend_bigcommerce.backend.BigCommerceCustomerDefaultAuth', 'social_core.backends.google.GoogleOAuth2', 'social_core.backends.linkedin.LinkedinOAuth2', 'social_core.backends.facebook.FacebookOAuth2', 'social_core.backends.azuread.AzureADOAuth2', 'common.djangoapps.third_party_auth.appleid.AppleIdAuth', 'common.djangoapps.third_party_auth.identityserver3.IdentityServer3', 'common.djangoapps.third_party_auth.saml.SAMLAuthBackend', 'rules.permissions.ObjectPermissionBackend', 'openedx.core.djangoapps.oauth_dispatch.dot_overrides.backends.EdxRateLimitedAllowAllUsersModelBackend', 'bridgekeeper.backends.RulePermissionBackend', 'lms.djangoapps.lti_provider.users.LtiBackend']
It appears the edX Authentication may have been removed in favor of the anonymous authentication. I cannot be for certain about that but I’m looking into what was removed with this commit as this one made it anonymous authentication.
Yes, we have been able to use open edX as an LTI provider for Canvas. It’s worked for over a year across multiple updates, including Palm.
However, we are still stuck with a new account being created whenever someone accesses open edX over LTI. We have started working with OpenCraft to come up with a solution to this. When they have implemented one, they will submit a PR(s) to open edX.
Maybe this answers your question. If not, let me know what you’re trying to do at this time, and I can try to get some more details.
@Zachary_Trabookis We discovered the same things when @pdpinch asked us to look into getting the user linking to work between Canvas and Open edX. I recently opened a PR that implements auto-linking of the LTI User and edX User accounts using the lis_person_contact_primary_email that is available in the LTI Launches from Canvas.
Yes. We encountered the same thing. So the PR skips the fixing of the LTI Authentication altogether, as it seems unnecessary for the linkage to happen. Moreover, I suspect that the LTI Authentication was tested to work with Blackboard only (or at least tested explicitly) due to 2 reasons:
This blog post about the LTI Auth provider mentions Blackboard only
Derek White, of University of British Columbia (UBC), a key partner in validating our integration with Blackboard, whose team contributed “edX as an LTI Authentication Provider” functionality to Open edX, describes why it’s important for learners to establish their identity in Open edX:
The LTI Provider TPA code parses the field email when populating the details in the registration form. But the LTI Spec reference email only using the field lis_person_contact_primary_email. Which leads me so believe, Blackboard might have used the email field directly instead of using the lis_ convention.
So, in our PR, we settled for a simple configuration flag, that can be turned on which will auto-link any existing user to the LTI user as long as the emails match.
@arunmozhi Thanks for showing your PR. So how do we ensure that the ‘ lis_person_contact_email_primary’ is set? Are you testing with Blackboard or other external LMS systems to see if your new logic will persist? I feel like I would want to use this update now. Is it production ready?
I have tested this with Canvas LMS (as mentioned in the PR testing instructions) and know it works for a regular user added with email into Canvas. For
I think for other systems, the quickest way would be to look at the network tab of the LTI launch request (a POST call) and see if it is a part of the request. In Canvas, I have tested that setting the Privacy level to “Email only” shares the email during the LTI Launch. There might be a similar option in other LMSes.
The PR itself is tested with both unit tests and with Canvas. I would like to think it is production ready, but would suggest waiting until the PR gets merged.
@arunmozhi
I made a comment here about having the same email at two separate LTI Consumers and the unique key UNIQUE KEY edx_user_id (edx_user_id), failing because it tries to insert and another record in in the lti_provider_ltiuser table with same edx_user_id due to the finding the user by email.
I don’t think there would ever be a scenario where you’d have the same email at two separate LTI Consumer external LMSs.
@Zachary_Trabookis Thanks for catching this. You are absolutely right to be worried about this UNIQUE constraint. If an org is used LTI Consumer per course, this constraint will completely break the LTI integration with the auto-linking is enabled. I have updated the model to allow linking multiple lti_users to the same edx_user and commented on the PR as well.
