Add a option to prevent drupal login when not logged through idP

Created on 16 July 2025, 6 months ago

Problem/Motivation

When I add a new account, the account can log in by id/pass from drupal login form,
However, once an account has logged in from idP, it cannot log in.

It's not better to add a option to prevent drupal login to let the account only could login through idP.

✨ Feature request
Status

Active

Version

4.0

Component

Code

Created by

πŸ‡―πŸ‡΅Japan liuyuanchao

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

Comments & Activities

  • Issue created by @liuyuanchao
  • πŸ‡ΊπŸ‡ΈUnited States jfurnas

    There is already an option for this. In the path `/admin/config/people/saml` there is a toggle for 'Auto redirect Drupal login screen to SAML'. With this enabled, if somebody tries to access /user/login it will redirect them to the /saml/login route instead, bypassing the /user/login link.

  • πŸ‡―πŸ‡΅Japan liuyuanchao

    Hi @ jfurnas

    Thank you for your advise.

    I tried as what you said that access /user/login will redirect to the /saml/login route.

    But I do not want to block the /user/login because I also use the drupal log in in some cases.

    I update the issue description to be more detailed in what I want.

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

    Hi @liuyuanchao,

    I am hesitant to implement this, because

    1) This change would affect other parts of Drupal, outside 'external login'. I see the potential for confusion about "why can this specific user (who has nothing to do with SAML) not log in", situations where the 'per role' setting is not good for people, ...

    2) It is possible to "associate [new accounts] with a SAML login", even before they actually logged in. Then the current setting gives the behavior that you want.

    I will assume that:

    • you are an administrator of the Drupal site, who pre-creates Drupal users that can log in, because the "Create users upon SAML login" is somehow is not good for your case.
    • at this moment, you (can) also know the "unique ID" that this user has in the IdP.

    At the same time you create the user, you should insert a record in the authmap table: uid = Drupal userid, authname = [ that unique ID ], provider = 'samlauth'.

    There is no code or documented practice for this yet, and there should be. I will change this to a "task", for the community to create some code and/or examples how you did this. We'll then refer to the comments in this issue from (or copy it into) the samlauth README.md.

    What I know is:

    • The externalauth module has a 'migration destination' for the authmap table. So if you create a lot of users at the same time, maybe it is easy to import a mapping of [authname / unique ID] -> [name of the new Drupal user] using Migrate Tools. (I have no personal experience with this.)
    • If you create single new Drupal accounts one by one, maybe there needs to be a new drush command e.g. drush externalauth:add-map <drupal-username> <authname> <provider>. It should be easy enough to create. I believe this is a good addition for the externalauth module. (A note: my current opinion is that it should NOT be possible to edit auth-mappings through the Drupal UI; there only is an already-existing UI to view and delete them. So I believe that just this drush command without any UI equivalent, is good.)
  • πŸ‡―πŸ‡΅Japan liuyuanchao

    Hi @roderik

    Thank you for the detailed explanation.

    At the same time you create the user, you should insert a record in the authmap table: uid = Drupal userid, authname = [ that unique ID ], provider = 'samlauth'.

    We prepare to create a custom drush command to do this.
    And I am very agreed with you that this should be documented.
    Thank you.

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

    If this drush command can be contributed back (IMHO it's best done to the externalauth module)... I'll be happy to review it and make a case to the externalauth maintainer about why it should be included there.

    (And if he doesn't want it: I'll add it to this module.)

Production build 0.71.5 2024