Open OxyOCE opened 9 months ago
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
Hi @weilai-irl thanks for your reply. Hopefully this articulates the problem we are trying to solve.
The situation we have:
So our goals are:
To enable this, we:
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.
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.
Hi @OxyOCE and @nwp90,
The upcoming release of the plugin (hopefully in the coming days) will introduce a new feature to allow Moodle site admins to choose or set the access/ID token claim to be used in as Moodle username. I think this is closely related to the issue reported in this one, and the linked pull requests. As part of the changes, the function to determine Moodle username from token was rewritten, and if a binding username token claim is set, and if it exists in the token, it would always be used. I think this may solve the issue you are facing.
Please test this feature when it comes out, again I hope in the coming days, and see if it works.
Regards, Lai
Hi @OxyOCE and @nwp90,
The feature mentioned in my last comment has been released. Please check it out.
Regards, Lai
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