nextcloud / nextcloud/user_saml
[BUG] RememberLocalGroupsForPotentialMigrations silently activates destructive group sync on upgrade with no opt-in
Nobody has claimed this yet.
- 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
- Upgrade from user_saml v7.1.4 to v8.0.0 with group attribute mapping configured.
- As admin, add a SAML user to a local Database group
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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