mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-23 03:09:40 +03:00
A user with the email ... already exists but with different credentials #3940
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 @antwacky on GitHub (Jul 27, 2023).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
I've found some similar issues but not quite the same.
Previously we used Microsoft Azure authentication to authenticate users. We are now moving to Keycloak, using OIDC login.
When I change the authentication method from Azure to OIDC and login, I get the error:
"A user with the email ... already exists but with different credentials"
I've seen other issues that mention updating the external ID, but I can see no such option. I can see 'Disconnect account'.
We have lots of users so the ideal solution will not involve editing via the UI.
Thanks in advance!
Exact BookStack Version
23.06.2
Log Content
A user with the email ... already exists but with different credentials
PHP Version
8.2.8
Hosting Environment
Docker image ghcr.io/linuxserver/bookstack:23.06.2 on Kubernetes.
@ssddanbrown commented on GitHub (Jul 27, 2023):
Hi @antwacky,
Please see my video linked below, particular the "External authentication ID field" part of the video starting at 9:16.
https://youtu.be/TJQ4NJrMvkw?t=556
@antwacky commented on GitHub (Jul 27, 2023):
Hi, thanks for this. When I select external_auth_id from the database the field is empty for all users (current auth method is Azure OIDC).
So I should prepopulate the external_auth_id field using the Keycloak ID for each user then switch Bookstack to OIDC method?
@ssddanbrown commented on GitHub (Jul 27, 2023):
Assuming that the Keycloak ID is the ID property being used (for the ID token
subclaim unless you're changing it with the BookStackOIDC_EXTERNAL_ID_CLAIMoption) then yes.Could just test it with one account first to make sure you're using the right ID property.
@antwacky commented on GitHub (Jul 27, 2023):
Great thanks, maybe I'll set the claim to be the email so I don't have to cross reference each user when updating.
Another quick question, the Azure method has the options:
AZURE_AUTO_REGISTER: "true"
AZURE_AUTO_CONFIRM_EMAIL: "true"
I couldn't see similar options for OIDC.
@ssddanbrown commented on GitHub (Jul 27, 2023):
When OIDC is active, there is no separate register page, auto-register is essentially active by default.
Again, this is usually redundant if using OIDC, you'd generally look to trust the incoming users from your identity platform, so you wouldn't use the domain restriction/email confirmation options.
@antwacky commented on GitHub (Jul 27, 2023):
Awesome thanks, closing the issue. Will reopen if I come across issues on the next attempt at moving to OIDC.