mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-18 09:52:56 -05:00
[GH-ISSUE #7112] [Regression 1.35.5+] New SSO user without org membership: 401 on placeholder org policy redirects to /#/login instead of /#/set-initial-password #15406
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 @loldark22 on GitHub (Apr 20, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7112
Prerequisites
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
Vaultwarden Build Version
v1.35.7 (regression) / v1.35.4 (last known good)
Deployment method
Official Container Image
Custom deployment method
No response
Reverse Proxy
Caddy 2.10
Host/Server Operating System
Linux
Operating System Version
Ubuntu 24
Clients
Web Vault, Desktop
Client Version
Web-Vault 2026.2.0 (broken) / 2026.1.1 (last known good) — bundled in the respective server images
Steps To Reproduce
vaultwarden/server:1.35.7(Web-Vault 2026.2.0) with SSO enabled against a Keycloak realm. Relevant env:SSO_ENABLED=true
SSO_ONLY=true
SSO_AUTHORITY=https://auth.example.local/realms/test
SSO_AUTHORITY_DISCOVERY=http://keycloak:8080/realms/test
SSO_ORGANIZATIONS_ENABLED=true
SSO_ORGANIZATIONS_INVITE_ENABLED=true
ORGANIZATION_INVITE_AUTO_ACCEPT=true
SIGNUPS_ALLOWED=false
SSO_SIGNUPS_MATCH_EMAIL=true
/#/loginafter a brief redirect sequence.vaultwarden/server:1.35.4(Web-Vault 2026.1.1), delete theusers+sso_usersrows for the test user, and repeat steps 3-4. The browser now correctly lands on/#/set-initial-password?identifier=VW_DUMMY_IDENTIFIER_FOR_OIDC— master password registration screen, as expected.Expected Result
After successful Keycloak authentication, a new SSO user with no pre-existing organization membership should land on
/#/set-initial-password?identifier=VW_DUMMY_IDENTIFIER_FOR_OIDCso they can register their master password and enter their empty vault. This is the behavior on 1.35.4 (Web-Vault 2026.1.1). An admin can then assign them to organizations afterward.Actual Result
On 1.35.7 (Web-Vault 2026.2.0), after Keycloak auth the web client performs an unauthenticated-like redirect sequence and ends up back at
/#/login, making first-time SSO signup impossible. Theusersrow is created in the DB but the user cannot complete master-password setup or enter the vault.Server-side
get_auto_enroll_statusreturns a random placeholder UUID (viaget_uuid()) when the user has no org — unchanged between 1.35.4 and 1.35.7. The subsequentGET /api/organizations/<random-uuid>/policies/master-passwordreturns 401 because the user isn't a member of that (nonexistent) org. The 1.35.4 web-vault client tolerated this and proceeded to/#/set-initial-password; the 2026.2.0 client appears to treat the 401 as a session failure and redirects to login.The random UUID changes every request (e.g.
0eb7714a-237b-4ce1-bd5f-20bed4137a55on one attempt,f3abcc31-02fd-4934-9ed5-f1e4136e2281on the next), confirming it's a placeholder rather than a real-but-inaccessible org.Logs
Screenshots or Videos
No response
Additional Context
Since the server returns a random placeholder UUID, the client's subsequent
GET /api/organizations/<id>/policies/master-passwordis guaranteed to 401. The 2026.1.1 web-vault evidently treated this as "no policy applicable, continue to master-password setup," but 2026.2.0 treats it as a session failure and logs the user out.Suspected fix direction: either
get_master_password_policyshould return a default (disabled) policy with 200 OK when the caller is an authenticated session but not a member of the target org, specifically for the pre-signup placeholder UUID case; OR/api/organizations/<id>/policies/master-passwordas "no policy to apply, continue" rather than a terminal session failure; ORidinget_auto_enroll_statuswhen no org is found, so the client doesn't attempt the doomed policy lookup.Related but distinct: #7072 (invited-user stuck in status=0 on 1.35.4). #7072 affects users who ARE invited; this one affects users who are NOT invited to any org. Both are in the broader SSO first-time signup area.
No timshel fork variables (
SSO_FRONTEND=override, etc.) are used; pure upstream config.@BlackDex commented on GitHub (Apr 20, 2026):
Already fixed via #7097 currently in
:testing@loldark22 commented on GitHub (Apr 20, 2026):
Thank you for your quick confirmation.
If it is released later, we will test it additionally.
Thank you.