mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-07 03:09:44 +03:00
SSO Acccount re-creation improvement, matched user re-connects to previously "deleted" user #3337
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @BloodyIron on GitHub (Nov 9, 2022).
Describe the feature you'd like
In our scenario we are using SSO-only for authentication, via SAML, and users typically don't even enter their creds if they use a browser with the SSO session already active, but otherwise if they are prompted they would enter the same credentials every time. That may seem a bit redundant to state, but also keep in mind that the credentials are unique to the human, namely the E-Mail address to identify them (through SAML SSO), in our case Google Workspace.
In our testing environment, I've deleted accounts repeatedly to have me (or others) log back in to test some slight changes (recently fixing how full names are properly defined for users). However, as a result of this, any previous content or whatnot tied to the account before deletion is now completely orphaned. Some of which cannot be re-assigned, such as comments.
What I would like to see is a setting for SSO/SAML or somewhere, whereby if the system re-creates the user with the identical Central Authentication identity (in this case SSO SAML entity) that the human/user re-attaches to the previous user (shell user) and not a new user created (incremental user identity number). This way that user regains all the content they were authors for, and such, transparently.
I don't yet know if there are scenarios in production where deleting and remaking the user is preferable, but if we were to have to do it, it would lead to bigger and bigger problems over time as more content is in Bookstack. It would be great to retain those associations in such a scenario. Or at least have a way to "enable" such behaviour within the Bookstack ecosystem.
Describe the benefits this would bring to existing BookStack users
This would reduce friction when administrative (IT) staff need to rebuild a user's profile for any reason, by having previous ownership reliably transition.
Can the goal of this request already be achieved via other means?
Not that I can see at this time.
Have you searched for an existing open/closed issue?
How long have you been using BookStack?
0 to 6 months
Additional context
Not sure the best way to reliably do this from a technical perspective, apart from unique identity mapping, or maybe if there's also an option for admins to manually override if it fails.
@ssddanbrown commented on GitHub (Nov 9, 2022):
Hi @BloodyIron, Not sure I understand the scenario here. Why are you deleting users if they're likely to login again?
The user deletion is intended to be destructive and records are deleted. There is no shell user to connect back up to, apart from some potential lingering ids on related tables.
@BloodyIron commented on GitHub (Nov 9, 2022):
In this particular case I was deleting users to re-test provisioning, specifically because the FirstName and LastName was not being correctly updated (my own configuration mistake), so deleting the user with the intent the re-provisioning would happen next login. I don't really intend for user deletion to be a regular occurrence, but if there is ever a scenario where it happens, it seems like having a way to connect the same user entity to the previous userID# (within Bookstack) is worthwhile to regain content ownership (also consider you cannot change ownership for comments, like you can for pages).
I guess I'm more speaking to the linkering id's and such ;)
@ssddanbrown commented on GitHub (Nov 9, 2022):
Okay. to be honest I really intend the delete operation to be a delete. Attempting to re-join with old lingering IDs would just be messy and there'd be questions around expectations since there'd be things we can't restore for that user.
I think something like #3564 would be a better underlying approach to meet the core desire here. If that was implemented then you can take an approach of disabling user accounts instead of deleting then, so user account details can be retained and re-enabled later on.
@ssddanbrown commented on GitHub (Dec 12, 2022):
I'm going to go ahead and close this off since this specific logic is not something I'd look to support in the core project as per my comments above.