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.

Hello,

I also get this error: "Drupal\externalauth\Exception\ExternalAuthRegisterException : User could not be registered. There is already an account with username...."

In my website, I also have existing accounts, created before the implementation of external Auth. Here is my code to login and/or register user account :

        $this->externalAuth->loginRegister(
          $datas['email'],
          'my_service',
          $account = [
            'mail' => $datas['email'],
            'name' => $datas['email'],
            'status' => 1
          ]
        );

How to resolve this problem ? Do I use another method to create user from an external service?

Thanks.

This issue happens on Drupal 10.4.5 as well. It only happens in rare cases with accounts that still have an old email address that doesn’t match the IDP’s required address.

For example, if a user originally had nancy.smith@NONidpdomain.edu on their Drupal account, but the IDP now provides nancy.smith@idpdomain.edu, Drupal still sees the old email stored in the database. When the user logs in, instead of updating the existing account, Drupal creates a new one with the correct email but prepends simplesamlphp_auth_ to it (e.g., simplesamlphp_auth_nancy.smith@idpdomain.edu). The old account is left untouched, and now two accounts exist for the same user.

Ideally, when an email address changes, the original account should be updated and re-provisioned the next time the user logs in with their IDP credentials. Until then, here are two workarounds I’ve tested that fixed it:

1. Run a "user:information" query to check if the wrong email is still in the user table. If it is, you can update it directly, for example:

- UPDATE users SET mail = 'nancy.smith@idpdomain.edu' WHERE uid = ;

2. Account UI workaround: In the Drupal user account interface, change the email to a completely different one (e.g., nancy.smith@idpdomain2.edu), save it, then change it back to the correct IDP email (nancy.smith@idpdomain.edu). For some reason, the database doesn’t accept the first correction unless the email is changed to something entirely different first.