mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-10 01:10:09 +03:00
Add support for X-Forwarded-User header for external authentication #1820
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 @shift on GitHub.
Subject of the issue
To enable the external authentication (enabling OpenID/SSO) adding the support for a X-Forwarded-User header, would enable this.
Your environment
N/A
Steps to reproduce
ExternalAuth or ForwardAuth added headers (X-Forwarded-User) should allow the application to look up or create the user and log them in. Currently doesn't.
Expected behaviour
ExternalAuth or ForwardAuth added headers (X-Forwarded-User) should allow the application to look up or create the user and log them in.
Actual behaviour
Presented with the login screen.
Relevant logs
N/A
@rperpe commented on GitHub:
I don't publish any service directly to the internet and therefore users need to authenticate against the reverse proxy in front first.
Therefore I'd like to forward authenticated user's e-mail address as a HTTP header to vaultwarden and skip e-mail prompt.
@mprasil commented on GitHub:
I think @mqus is correct. The password sent to the server is derived from your master password, so you can't really use some form of SSO without somehow compromising the client side encryption. (essentially the same issue as there is with implementing built-in LDAP auth support #677)
@PrivatePuffin commented on GitHub:
@dani-garcia You can close this, this is basically impossible with Bitwarden.
It would require that the server could login the user without actually having the password, which (even with the current mockup LDAP code) would never be possible with Bitwarden.
@mqus commented on GitHub:
If i understand bitwarden right, then the password is not only used for authentication, but also for decryption of the passwords, so using a third-party-authentication doesn't make much sense if you don't also get the password. Could you clarify what exactly you expect,how it would work from a users perspective and at least specify the client you are expecting this to work on? Afaik, upstream clients don't support this, but please correct me if I'm wrong.
@PrivatePuffin commented on GitHub:
@rperpe The email prompt is part of the webgui source, which is copied mostly from the official repository.
It's not developered by vaultwarden itself.
Also: reverse proxies are inherently incompatible with the vaultwarden App as well.
@GoodiesHQ commented on GitHub:
I know this is old, but I just want to point out the distinction between authentication and authorization. The authentication portion can be done with SSO to Vaultwarden so your account is provisioned once an SSO claim/token is provided, but you still won't have the option to view passwords or anything until you enter your vaultwarden-specific password. This has the added benefit of the fact that once you get to the Vaultwarden password entry field, your account is already specific to you. This means that you cannot brute force anyone else's account by username/password, since you would have to authenticate as their username via SSO before you can submit the password.
@BlackDex commented on GitHub:
@rperpe commenting on a close ticket isn't that useful mostly.
Also, it isn't possible, since any other auth could cause conflicts with the auth of the server it self.
And, users need to enter there password to decrypt there vault, so there is no SSO at all, not even on the offical Bitwarden app.
There seems to be some way for most clients with some quirks using authelia: https://www.reddit.com/r/selfhosted/comments/kvesf3/authelia_and_bitwarden_via_traefik/
But, we will not support those kind of solutions.