PADV-1394: Improve LTI profile user

[kuipumu]

Tickets

• https://agile-jira.pearson.com/browse/PADV-1394

Description

This PR improves the generation of the LtiProfile user, more specifically the LtiProfile user username and email structure, additionally the LtiProfile name property was modified and the name used on the user profile was truncated to 255 characters in case a very large name is used to avoid error with the field max_length.

Type of Change

• Added shortuuid base requirement.
• Added LtiProfile short_uuid property.
• Added LtiProfile given_name property.
• Added LtiProfile middle_name property.
• Added LtiProfile family_name property.
• Added LtiProfile user_collision method.
• Added LtiProfile configure_user method.
• Modify LtiProfile name property.
• Modify LtiProfile save method.
• Add or modify any unit test for all related code.

Testing:

1. Run the LMS: make dev.up.lms.
2. Run the learning MFE on the host machine: npm run start.
3. Install openedx_lti_tool_plugin on the LMS.
4. Run ngrok or any other similar service on LMS: ngrok http 18000
5. Run ngrok or any other similar service on learning MFE: ngrok http 2000
6. Add required settings to LMS.

# Enable LTI Tool Provider Plugin.
OLTITP_ENABLE_LTI_TOOL = True

# Cookies settings.
SHARED_COOKIE_DOMAIN = ".ngrok.io"  # Replace .ngrok.io with the domain of the service used to expose the LMS and learning MFE if using another service other than ngrok.
# MFE config API settings.
ENABLE_MFE_CONFIG_API = True
MFE_CONFIG_API_CACHE_TIMEOUT = 0

7. Create a site for your external LMS address: http://localhost:18000/admin/sites/site/add/.
8. Create a site configuration for your site: http://localhost:18000/admin/site_configuration/siteconfiguration/add/

  {
      "SESSION_COOKIE_DOMAIN": ".ngrok.io", # This should be the same value has SHARED_COOKIE_DOMAIN setting.
      "LEARNING_MICROFRONTEND_URL": "https://learning-mfe.ngrok.io",
      "MFE_CONFIG": {
          "LMS_BASE_URL": "https://lms.ngrok.io",
          "LOGIN_URL": "https://lms.ngrok.io/login",
          "LOGOUT_URL": "https://lms.ngrok.io/logout",
          "MARKETING_SITE_BASE_URL": "https://lms.ngrok.io",
          "BASE_URL": "lms.ngrok.io",
          "LEARNING_BASE_URL": "https://learning-mfe.ngrok.io,
          "REFRESH_ACCESS_TOKEN_ENDPOINT": "https://lms.ngrok.io/login_refresh"
      }
  }

9. Restart the LMS: make dev.restart-container.lms.
10. Modify the learning MFE webpack.dev.config.js file (create one if not file exists.):

const path = require('path');
const { createConfig } = require('@edx/frontend-build');
const config = createConfig('webpack-dev', {
    devServer: {
      allowedHosts: 'all',
    },
});
config.resolve.modules = [
  path.resolve(__dirname, './src'),
  'node_modules',
];
module.exports = config;

11. Modify the learning MFE .env.development file and add these variables:

APP_ID='learning'
MFE_CONFIG_API_URL='https://lms.ngrok.io/api/mfe_config/v1'

12. Create a new LTI 1.3 tool key config: http://localhost:18000/admin/lti1p3_tool_config/ltitoolkey/add/ (You can use IMS RI to create a key pair: https://lti-ri.imsglobal.org/keygen/index)
13. Create a new LTI 1.3 tool config: http://localhost:18000/admin/lti1p3_tool_config/ltitool/add/

Issuer: https://saltire.lti.app/platform
Client id: saltire.lti.app
Auth login: url: https://saltire.lti.app/platform/auth
Auth token url: https://saltire.lti.app/platform/token/sda42bb0cf2352259a367a404d48d54e8
Key set url: https://saltire.lti.app/platform/jwks/sda42bb0cf2352259a367a404d48d54e8
Deployment ids: ["cLWwj9cbmkSrCNsckEFBmA"]

14. Go to the saLTIre platform https://saltire.lti.app/platform
15. Go to "Security Model" on the left sidebar and set these settings:

Message URL: https://lms.ngrok.io/openedx_lti_tool_plugin/1.3/launch/{course_id}
Initiate login URL: https://lms.ngrok.io/openedx_lti_tool_plugin/1.3/login
Redirection URI(s): https://lms.ngrok.io/openedx_lti_tool_plugin/1.3/launch/{course_id}
Public keyset URL: https://lms.ngrok.io/openedx_lti_tool_plugin/1.3/pub/jwks

16. Go to "User" on the left sidebar and set these settings:
17. Check the checkbox on "Given name", and "Family name" fields.
18. Click on the "Save" button on the top navbar.
19. Click on the dropdown next to the "Connect" button on the top navbar.
20. Click on "Open in iframe" or "Open in new window".
21. The launch should redirect you to the requested course on the learning MFE.
22. Go to https://lms.ngrok.io/account/settings
23. The username should show like "givennamefamilynameinitial.short_uuid"
24. The email should show like "uuid@openedx_lti_tool_plugin"
25. Repeat steps 16 - 22.
26. The username should show like "short_uuid"
27. The email should show like "uuid@openedx_lti_tool_plugin"

[alexjmpb]

What do you think of searching if there is already an LTI profile with the same uuid? I would say it's very unlikely for a regular user, that is not associated with an LTI profile, to have that specific username and email.

[kuipumu]

@alexjmpb There is already a unique=True parameter set on the LtiProfile uuid field, and the short uuid is derived from such value so there is no way the uuids are duplicated.

The need for the user_collision method is for the even more unlikely scenario that the username (which contains a short uuid with a bigger collision chance than a regular uuid) already exists, if this verification wasn't added the user could just simply retry the launch.

I would think making sure there will be no issues is better, and the performance impact will be minimal since this will only be executed when the LtiProfile has no user assigned.

What do you think?, I'm missing something?, do you think there could be another alternative apart from just letting it fail on the rare occurrence of a username collision?

[alexjmpb]

I agree.

[alexjmpb]

If the preferred_username PII data is specified, wouldn't we want to use it?

[kuipumu]

@alexjmpb For various reasons:

1. The OpenID Connect Core specification states that the preferred_username claim is not a stable claim and should not be used has an unique identifier for the End-User.
2. The preferred_username claim could be exploited by the LTI platform user, if they create another account with a username that matches a privileged account on our LMS, they could execute a LTI launch and escalate privilege on our LMS. Also they could use it to access to an user with grades that should not be accessible on the context of the LTI launch.

There are some other points I'm might be missing, this was analyzed previously on a discovery related to using the preffered_username or email claim to reuse existing accounts. A solution to this could be to create some mechanism to make the LTI platform user authenticate on the LMS with a known account once the LTI launch is executed, however it's still not clear how this could be achieved

Here is the URL to the discovery document:
https://docs.google.com/document/d/18CPyVm8MBqAhROCghjZMV3gOwK-chguKCFpfxX0zmjE/edit

[alexjmpb]

Are you planning to perform a migration of the users currently existing? With this new property wouldn't be a discrepancy between the existing user models username and the username generated by this property?

[kuipumu]

@alexjmpb There will be a discrepancy with the structure of the username of the older LtiProfiles with the new LtiProfiles.

Right now there is no requirement to update the username of the older LtiProfiles, if this is required in the future we could execute a backfill to fix this discrepancy.

[alexjmpb]

What if the username property returns the username of the platform user model if exists?