SAML login must not be linked to an already-linked user

Created on 27 December 2024, about 1 year ago

Problem/Motivation

If 'linking a new login to an existing user' is enabled, the login code contains a check that should prevent SAML login data with unique ID X to be linked to a user that is already linked to another login with unique ID Y.

That check stopped working with externalauth module 2.0.3 (released Nov 2022).

Since then, if the IdP can log in multiple users containing the same value of a 'linkable field' (e.g. same name or email, if configured as such) then both those IdP users can log in to the same Drupal account. The unique ID is constantly overwritten to be the last login (and externalauth logs a debug message).

(I found this while adding tests in πŸ› Linking a local user account to a saml account may be incorrectly blocked Active .)

Proposed resolution

Restore the situation where only the first such IdP user can link to that yet-unlinked Drupal account once, and the other IdP user(s) get(s) denied access after that.

πŸ› Bug report
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @roderik
    • roderik β†’ committed 8e07c77f on 8.x-3.x
      Issue #3496176 by roderik: (Re)disallow linking to an already-linked...
  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

    See commit; the check just needed to happen before the linking, instead of after (and tweaked a tiny bit). Which makes sense, but I didn't see that beforehand.

    Anyway: happy that this is now tested, so we'll spot it if it breaks.

  • Automatically closed - issue fixed for 2 weeks with no activity.

  • Status changed to Fixed 6 months ago
  • πŸ‡ΊπŸ‡ΈUnited States scampbell1 New York

    I have a situation where I am switching IdPs and actually need someone with the same matching field to be able to log into the account. So, for anyone else who may be in the same boat, I have a patch for that attached.

    For other users, it may be best to provide an option in a later release that can turn this feature on and off (i.e. put in a simple checkbox and, based on the TRUE/FALSE value, change those ~5 lines to either the old version or the new one).

  • πŸ‡³πŸ‡±Netherlands roderik Amsterdam,NL / Budapest,HU

    @scampbell1 - That patch is not going to be applied, because it goes against the basic purpose of the authmap.

    So... it seems like your new IdP has a completely new set of 'unique IDs' for people. That's fine, of course. In other words, it has a completely different 'authmap' (mappings of IdP-ID to Drupal-user that must be registered).

    If your old IdP is out of service (as far as your Drupal site is concerned): you don't need the old mappings anymore. If you DELETE FROM authmap WHERE provider='samlauth', your issues are over. (And yes, I guess this needs documenting, but I'm not completely sure how, yet.)

    If your old IdP is not out of service, you would need two different authmaps. But in that case, you would also need to have two different IdPs registered - which this module can't do yet. When ✨ Multiple IDP Support Needs work gets integrated, it should get support for separate 'authmaps' per IdP. (In other words: the provider='samlauth' field would need to be not-hardcoded to a single value.)

    ---

    Only if someone gives a practical example of them having a need for two separate users from the same IdP needing to log in as the same Drupal user, will we start considering something like this patch. But I haven't heard of it yet, so I assume it won't come to that.

Production build 0.71.5 2024