Module is auto-creating users prefixed with "simplesamlphp_auth_"

I wonder if this is somehow related to: https://www.drupal.org/project/externalauth/issues/2910506 →

I just had composer update External Auth to v 2.0.3. My system never complained that 8.x-1.4 was out of date but it appears that the version 2.x is more recently updated so I'm going to use that instead.

Note that updates to externalauth did not fix the issue. I have had 3 users auto-generated today. 2 were correctly saved as "username". One was incorrectly saved as "simplesamlphp_auth_username."
Current details:
simplesamlphp (library) 1.19.8
php 8.1.14
Drupal 9.5.4
External Auth 2.0.3
SimpleSAMLphp Authentication (module) 8.x-3.3

Any ideas? thanks.

Quick sanity check for you all, are there existing users on the site that already match the username/email/unique identifier of the account being provisioned?

I'm noticing this tends to happen when there's an existing user and the system can't understand that it needs to match the incoming user with the existing account.

I have one site where incoming users get matched properly and one site where they don't and this prefix thing happens. I thought checking "Automatically enable SAML authentication for existing users upon successful login" was supposed to fix this, but I'm not sure.

None of the newly provisioned "bad" accounts match an existing account (username or email address) so I haven't had the same experience. I had wondered something similar early on and searched for existing data in the users_field_data table.

Follow-up and resolution. Our hook_entity_insert from our custom module is causing an error in some cases and messing up the entity (in this case a new user). I say "some cases" because in our case we have a pool of servers that were not set up correctly. Namely, some recently added servers did not have access to an Oracle server that we hit at user creation time. When I take the entity_insert out of the equation, accounts are formed as normal. Interesting that an account is still created when hook_entity_insert encounters an error.

I'm seeing exactly the same problem too. It seems some users are randomly getting the simplesamlphp_auth_ prefix to their username - and also the User entity fields and roles are not set, while some other users get provisioned normally as before. There's no visible common denominator in these cases.

There's no custom hook_entity_insert that could be messing with this in my case though.

@jhuhta. Bummer. Any contrib modules thats might act on a user_insert? How about a hook_entity_create? Is the drupal log showing anything?

It seems that the attribute set as mail_attr is not always populated in the data, which I didn't know. A log entry, which I didn't immediately notice, states that clearly:

Drupal\simplesamlphp_auth\Exception\SimplesamlphpAttributeException: Error in simplesamlphp_auth.module: no valid "urn:oid:0.9.2342.19200300.100.1.3" attribute set

I'm assuming that this exception caused the user provisioning to fail in the middle of the process. Disabling the email syncing in the configuration should fix the problem, as we have anyway some custom attribute syncing code in place that can handle this - and tolerate better missing data.

I am also getting some users that cannot login. Noticed that the username is prefixed with simplesamlphp_auth_.
simplesamlphp 4.0.0
php 8.3
Drupal 10.3

Tried deleting the user and deleting from the authmap table, same problem when they login again.

My workaround is to Cancel the user. Create the user manually. Delete the user from the authmap table. Then they are able to login. However, I don't want to have to do this for every new user.

In simplesamlphp_auth/src/Service/SimplesamlphpDrupalAuth.php,
Fixed it by sending the email into 'name' rather than letting register use the prefix:
- $account = $this->externalauth->register($authname, 'simplesamlphp_auth');
+ $account = $this->externalauth->register($authname, 'simplesamlphp_auth', [
+ 'name' => $authname,
+ ]);

Seems to be working.