nextcloud / nextcloud/user_saml

[BUG] RememberLocalGroupsForPotentialMigrations silently activates destructive group sync on upgrade with no opt-in

Open
#1,106 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

0. Needs triage bug needs info
Dominant language
PHP
Stars
104
Forks
85
Avg merge
1d 15h
Merged PRs (30d)
16

Description

How to use GitHub
  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Issue

SAML-authenticated users are silently and automatically removed from locally-managed groups upon login after upgrading user_saml, without any admin knowledge or consent. There is no warning, no configuration option to skip it, and no relevant documentation on the portal.

Subsequently, when IdP users login after an update, they find themselves removed from all local groups.

The RememberLocalGroupsForPotentialMigrations repair step should:

  • Be opt-in rather than auto-executing on upgrade
  • OR require explicit admin confirmation before populating the candidate pool
  • OR only populate groups that meet specific criteria (not all Database groups)
Repro
  1. Upgrade from user_saml v7.1.4 to v8.0.0 with group attribute mapping configured.
  2. As admin, add a SAML user to a local Database group
  3. SAML user logs in via IdP

Expected: Local Database group membership persists across SAML login
Actual: SAML user is removed from local Database group on login (and loose access to all group-managed resources).

Version: user_saml v8.0.1, Nextcloud server v32.0.9
Env: Production (Podman container)

Root Cause

The RememberLocalGroupsForPotentialMigrations repair step (registered in appinfo/info.xml as <post-migration>) automatically executes during upgrade. It populates the localGroupsCheckForMigration config key with ALL Database backend groups (except admin) and sets a 60-day expiration window.

This causes GroupManager::mayModifyGroup() to return true for Database groups in the candidate pool that contain only SAML users, which in turn causes GroupManager::getGroupsToRemove() to remove these local groups from SAML users on login.

Verification
# Directly upon upgrade, check if migration candidate pool is populated:
php occ config:app:get user_saml localGroupsCheckForMigration
# Output confirms auto-enrollment of our local DB groups:
{"dropAfter":1783195325,"groups":["groupA","groupB",...]}
Immediate fix

Immediately after an update:

php occ config:app:delete user_saml localGroupsCheckForMigration

Removing group attributes mapping entirely also fixes the issue but this is not acceptable in production if IdP groups are also provisioned.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the post-migration registration in appinfo/info.xml and the RememberLocalGroupsForPotentialMigrations repair step. Trace how localGroupsCheckForMigration affects GroupManager::mayModifyGroup() and GroupManager::getGroupsToRemove() during SAML login. Done means upgrades no longer silently enroll all Database groups without an approved opt-in or confirmation path, with regression coverage for preserving local group membership.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
authentication, authorization
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.