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
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.
# Here is our settings for authentication backends. LTIAuthBackend is at the front of the list.
['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.