LTI 1.1 misaligned auth after 22.10 upgrade

[Ghada El-Zoghbi]

Mahara: 22.10.0
OS: Linux 20.04
DB: Postgres
Browser: n/a

Post an upgrade from 21.10 to 22.10, the LTI auth for an institution is misaligned and users can no longer log in.

Scenario with LTI integrated Blackboard LMS:
- In 21.10, create an institution1 with 1 LIT auth "Web services"

- Created 2 enabled registered external apps:
1. "Blackboard LTI" <- owner was deleted but still exists (i.e. create app then delete user)
2. "Blackboard LTI Mahara" <- genuine LTI and owner still exists

- Crete users in instintution1 with "webservice" auth

- Upgrde to 22.10

- All users should be converted to "Blackboard LTI Mahara" as that is the valid instance.

What happens: the users are still linked to the "webservice" auth which doesn't have any valid registered apps.

An additional SQL during the upgrade should:
* update all auth_remote_user records from the old auth to the new auth
* update all usr records from the old auth to the new auth
* the old "webservice" auth in the institution should be deleted

[Kristina Hoeppner (kris-hoeppner)]

The problem I see is when there are two or more LTI auth that exist before the upgrade. Which one should Mahara choose automatically? I don't think we can make the decision there and will need to discuss.

[Kristina Hoeppner (kris-hoeppner)]

Suggestion from Ghada: I think one option is to do a sanity check before the upgrade. If more than one LTI app is found for an institution, stop the upgrade and request a mapping is added to the config file or in a local upgrade file.

[Robert Lyon (robertl-9)]

An issue with the 'webservice' auth methods and LTI is that we can have a a valid 'webservice' auth method on a site even if LTI is not being used.

The generic 'webservice' instance name can also exist if the site has webservice tokens generated on the webservice/admin/index.php page under 'Manage service access tokens' section.

Here the 'webservice' auth instance is for checking that the owner of the token is in an institution that allows webservice access (checked by there being at least 1 'webservice' auth method for that institution).

So it's not easy / obvious what users need to be switch from one webservice auth method to another if they are using the generic 'webservice' one.

[Ghada El-Zoghbi (ghada-z)]

hi Robert,

What about the idea of a sanity check before the upgrade and a mapping?

Thank you.
Ghada

[Kristina Hoeppner (kris-hoeppner)]

There is no easy automatic fix. We suggest to fix the auth methods manually for the time being or provide a patch for the mapping.