Mapping of Given Name not working with Azure and OpenID Connect

[Tigger996]

When an account gets created in Moodle, Given Name is mapped to the first name field in OpenID Conenct. This is not bringing in the first name anymore. In azure, I believe it shouljd be First Name which is not an option. So all new users coming in do not get a first name. This is a huge issue at this point. Anyone else have this problem or a way to fix it?

Thanks

[Tigger996]

Additional Info: It does work as expected on these versions: Microsoft 365 Integration 3.11.3 (2021051723) and OpenID Connect 3.11.3 2021051720

Versions it is not working on:
Microsoft 365 Integration 3.11.4 (2021051725) and OpenID Connect 3.11.4 (2021051725)

Moodle Version is 3.11.6

[weilai-irl]

Hi @Tigger996,

I'll try to reproduce the issue in the named version and get back to you.

Regards, Lai

[weilai-irl]

Hi @Tigger996,

I have tested in the latest release of both 3.11 and 4.0, with new and existing users, and can't reproduce the issue - the first name fields were synced correctly in all cases.

Could you confirm your field mapping setting in auth_oidc plugin, and your user sync options in local_o365 plugin please, as they may be most relevant to the issue.

Regards, Lai

[Tigger996]

I think I figured it out where it is messing up. When I select Update Local on creation it does not work. If the setting is On Creation, every login, and every user sync task run it does come in. It does this on both versions.
I only want the first name set on creation as students have preferred names that they want to use in Moodle and I don't want to override every time they login.

[Tigger996]

It's been a week, any chance this could be fixed as school startup will start soon. Thanks.

[weilai-irl]

Hi @Tigger996,

Could you describe the issue again please. Information in https://github.com/microsoft/o365-moodle/issues/2087#issuecomment-1190452595 and https://github.com/microsoft/o365-moodle/issues/2087#issue-1309797181 are a bit confusing. Once it's clarified, I'll try to find out what happens.

Just FYI, in case this is confirmed a bug, the earlier possible time this is fixed is in the next release, which is expected to be before end of September. Pull request containing the fix will be linked to the issue as soon as they are developed, but (1) all PR are provisional and subject to change until release, and (2) you will need to merge them yourself.

Regards, Lai

[Tigger996]

When on creation is selected for the first name field, the first name does not come in at all when the account is created. If the setting is On Creation, every login, and every user sync task run, the first name does come in. So there seems to be a bug when On creation is selected. I have not tested on other fields, but first name for sure. Is this clearer?

[weilai-irl]

Hi @Tigger996,

Could you clarify how your accounts are created please? Effectively there are two ways to create accounts:

• In the user sync task: If you have the user sync task enabled, running the task will pick up any Microsoft 365 account that doesn't have a matching Moodle account and create them.
• On user's first login: In case the user sync task is not enabled, or it hasn't run since the Microsoft 365 account is created, user's first login attempt will create the Moodle account.

Please specify which scenario best describes your use case.

Regards, Lai

[weilai-irl]

Hi @Tigger996,

After some more investigation, I think I found the root of the issue. It applies to the second scenario in my last note.

I'll provide a solution and link the pull request when ready.

Regards, Lai

[Tigger996]

I applied the patch to my test instance and the first name still does fill in when the setting is set to on creation on the first name attribute.

[weilai-irl]

Hi @Tigger996,

Could you clarify in what event the first name field was filled in when you set it to on creation please? It wasn't clear from the message.

Regards, Lai

[weilai-irl]

Hi @Tigger996,

I reran tests on all possible scenarios and I confirm the sync of the field works according to the setting.

Maybe you confusion is what action is categories as "On creation"? As I explained in comment https://github.com/microsoft/o365-moodle/issues/2087#issuecomment-1195932854, a Moodle account can be created on either (1) first user sync task run, or (2) first user login. If you set the sync option to be "On creation", sync will take place when the Moodle account is created, regardless either it's from route (1) or (2). But sync will not run on future logins or user sync task run.

Regards, Lai

[Tigger996]

Our accounts are not synced. They are just created on first login.
My settings are:

Here is my process: I log in with one of my student test accounts

Then Moodle takes me to the profile screen:

As you can see first name did not come in. If I change the Update local (First Name) to On creation, every login, and every user sync task run, the first name does populate.

I however just want the first name to come in on initial creation only. I need my users to be able to alter their first name and not have it change the next time they log in. I hope this helps clarify things.

[weilai-irl]

OK, let's try to add some more debugging code to see what's going on behind the scene.

In a test environment, could you replace https://github.com/microsoft/o365-moodle/blob/46861cfe86a0cedf2866246f3909faf50de4a3d3/auth/oidc/classes/loginflow/base.php#L128-L174 with the following lines and try to login as a new user please. The login will not work, but it will provide the debugging information required to point to root of the issue.

                if (\local_o365\feature\usersync\main::fieldmap_require_graph_api_call($eventtype)) {
                    echo '<pre>';
                    var_dump('1');
                    // If local_o365 is installed, and field mapping uses fields not covered by token,
                    // then call Graph API function to get user details.
                    $apiclient = \local_o365\utils::get_api($tokenrec->userid);
                    if ($apiclient) {
                        $fieldmappingfromtoken = false;
                        $userdata = $apiclient->get_user($tokenrec->oidcuniqid, true);
                    }
                    var_dump($userdata);die;
                } else {
                    echo '<pre>';
                    var_dump('2');

                    // If local_o365 is installed, but all field mapping fields are in token, then use token.
                    $fieldmappingfromtoken = false;
                    $idtoken = jwt::instance_from_encoded($tokenrec->idtoken);
                    var_dump($idtoken);
                    die;
                    $oid = $idtoken->claim('oid');
                    if (!empty($oid)) {
                        $userdata['objectId'] = $oid;
                    }

                    $upn = $idtoken->claim('upn');
                    if (!empty($upn)) {
                        $userdata['userPrincipalName'] = $upn;
                    } else if (isset($tokenrec->oidcusername) && $tokenrec->oidcusername) {
                        $userdata['userPrincipalName'] = $tokenrec->oidcusername;
                    }

                    $firstname = $idtoken->claim('given_name');
                    if (!empty($firstname)) {
                        $userdata['givenName'] = $firstname;
                    }

                    $lastname = $idtoken->claim('family_name');
                    if (!empty($lastname)) {
                        $userdata['surname'] = $lastname;
                    }

                    $email = $idtoken->claim('email');
                    if (!empty($email)) {
                        $userdata['mail'] = $email;
                    } else {
                        if (!empty($upn)) {
                            $aademailvalidateresult = filter_var($upn, FILTER_VALIDATE_EMAIL);
                            if (!empty($aademailvalidateresult)) {
                                $userdata['mail'] = $aademailvalidateresult;
                            }
                        }
                    }
                }

Please post back the information printed on the page. Feel free to hide any sensitive data if needed - I'm more interested in which route it went to (whether to get user profile details from Graph API or token), and what profile fields are available in the route.

Regards, Lai

[Tigger996]

Hi Lai, I will be able to do this on Tuesday next week. We have a long weekend and will not be able to change the code until then. I will send the results as soon as I can. Thanks for all your help on this. Lori

[weilai-irl]

Hi @Tigger996,

I found another issue in my previous attempt to fix the issue, which may have caused your last test failed. I have updated the pull request to reflect it. Please try to apply this and see if it works. Please do this before you adding the additional debugging script, as there's a big chance that this will fix the issue you are seeing.

Regards, Lai

[Tigger996]

Hi Lai, That did the trick! Thanks so much. Do you have a rough estimate on when this will get pushed out into the full release? Lori

[weilai-irl]

Hi @Tigger996,

Thank you for your confirmation.

The new release should be ready by the end of the month.

Regards, Lai

[weilai-irl]

Hi all,

The fix to the issue has been included to the release from today. Please upgrade your plugins to the latest version to see the fix.

I'm going to close the issue now.

Regards, Lai

[103191]

Hi @weilai-irl, I found the issue was solved for the field "Given Name" and it is not resolved for other field, e.g. "Display Name" and "Job Title". So when the Data mapping (First name) is mapped to "Display Name", and a new account is created, the field is showing empty. Can you please check again?