Add an option in auth_oidc to always use UPN

[OxyOCE]

It can be frustrating to have a user's Moodle username updated or not be able to log in at all depending on your local_o365 settings and what alias they use to login.

The frustration comes when trying to use Moodle's "upload users" facility and realising that the username field has changed to something unexpected, requiring a lot of manual fix-ups to continue.

The changes below add an option to auth_oidc which will always use UPN for login flow purposes when Microsoft is the IdP.

403: #2525 402: #2524 401: #2523

[weilai-irl]

Hi @OxyOCE

Thank you for making the PR.

Can I ask you specify the exact issue the changes try to fix please. Please list the current behaviour and the behaviour after the PR is applied for comparison. We will perform test according to verify it works.

My understanding of the PR is it mainly changes to use the upn token claim to find Moodle users, and the upn claim doesn't present by default in standard setup when using "Microsoft Identity platform (v2.0)" IdP type. So unless the tenant adds the upn as an optional claim, the changes in the PR won't take effect. Please let me know if this is not the case.

Regards, Lai

[OxyOCE]

Hi @weilai-irl thanks for your reply. Hopefully this articulates the problem we are trying to solve.

The situation we have:

• Users have a choice of at least 3 username aliases with which they might log in
• We create users in Moodle with OIDC auth set, and user name set to either just the username part e.g. smijo123 or the UPN e.g. [email protected]
• If we use just the username part, they cannot log in until the user sync job has run, and can log in with the UPN after that.
• If we use the UPN, they can log in with the UPN immediately.
• If local_o365_support_upn_change is not enabled, they are unable to log in with aliases.
• With local_o365_support_upn_change enabled, they are able to log in with any of the aliases, but the Moodle username is updated to match the preferred_name they used.
• If users' usernames change in Moodle, then admins are unable to reliably perform bulk actions using spreadsheets, as the spreadsheet must include the username (which might have changed).
• Even with local_o365_support_upn_change enabled, their first login must be with the UPN, or the login fails with auth_oidc's "authpreventaccountcreation is set" message.

So our goals are:

• To ensure that users are always able to log in successfully using any of their available aliases
• To ensure that the Moodle usernames are consistent and do not change
• To enable users to log in as soon as their account is created in Moodle, without having to wait for user sync to run

To enable this, we:

• Set the username in Moodle to the user's Entra UPN
• Enable local_o365_support_upn_change
• Apply the fix we are suggesting and enable the useupn option it adds

This results in the desired behaviour.

Note - if useupn is turned on when existing users have been logging in with aliases, they will no longer be able to log in, as the values in the Moodle user table, the oidc token table, and the o365 objects table will not match their UPN. We have a separate fixup script for this issue, but it might? be possible to cater for it in code here...

Also note that while UPN is documented as optional in the claim, the documentation at https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference does mention that "Although this claim is automatically included, you can specify it as an optional claim to attach other properties to modify its behavior in the guest user case" - and we have not had to make any changes to the app registrations in order to make UPN available.

[nwp90]

Looking at the above, we (@OxyOCE and I work in the same team) have had "local_o365_support_upn_change" enabled, which should not matter as we should be using UPN, which should never change. However over time we are seeing some users' Moodle usernames change. We're not yet sure why, but disabling "local_o365_support_upn_change" would probably fix it. We'll update when we have more information.