Block inactive accounts and unblock on login via SAML

Created on 5 May 2022, about 2 years ago
Updated 28 December 2023, 6 months ago

Problem/Motivation

When a user is removed at the IdP, there is no call to the SP to deactivate the user.

Though it's not possible to log in as that user anymore once it is removed in the IdP, it would be good hygiene to block (or remove) the user in Drupal.

I thought I could do this by checking accounts for activity and blocking them after a period of inactivity in Drupal (I'm open for other suggestions).

I assumed that when a user that was "wrongly" blocked logs in the next time via SAML it'll just reactivate the user and all is good.

But there is a line in SamlService.php that check whether the Drupal account is blocked and gives an error

Requested account is blocked.

Steps to reproduce

  • Block account in Drupal
  • Try to login using SAML
  • Account is still blocked

Proposed resolution

I suggest to add configuration options

  • to block accounts after a period of inactivity
  • if that is set ignore the check in SamlService.php
✨ Feature request
Status

Active

Version

3.0

Component

Code

Created by

miiimooo Europe

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States cgmonroe

    Semi old request but in case anyone has a need like this there is a module that will do what the requestor asks for:

    https://www.drupal.org/project/user_expire β†’

    No need to add code to this module.

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

    Option to block accounts after a period of inactivity is indeed not something this module should do.

    Then there's the "unblocking blocked users upon SAML login" part.

    I can see some logic in the reasoning "the IdP is the source of all user data, including blocked-ness, Drupal shouldn't stand in the way of this" -- but it still feels like a can of worms to me. I'd have to see other people arguing for it too.

    If you want this specific thing, for now I regard it as a custom-code scenario where you can have your own class extend SamlService and register that as 'samlauth.saml' service. Code to be something like:

      protected function doLogin($unique_id, AccountInterface $account = NULL) {
        try {
          parent::doLogin($unique_id, $account);
        }
        catch (UserVisibleException $e) {
          if ($account && $e->getOriginalMessage() === 'Requested account is blocked.') {
            $account->activate();
            parent::doLogin($unique_id, $account);
            $account->save(); // possibly duplicate save if synchronizeUserAttributes() saved it too
          }
        }
      }
    

    While I was drafting up this code, I already saw the can of worms appearing. I assume you really want to do the $account && part here... because I assume you only want to unblock blocked users that were already previously linked to a SAML login.

Production build 0.69.0 2024