SSO using OpenID Connect

[Timshel]

This is based on previous PR (#2787, #2449 and #3154) with work done by @pinpox, @m4w0lf, @Sheap, @bmunro-peralex, @tribut and others I probably missed sorry.

This PR add support for OpenId Connect to handle authentication to an external SSO.
This introduce another way to control who can use the vault without having to use invitation or an LDAP.

A master password is still required and not controlled by the SSO (depending of your point of view this might be a feature ;). A key connector to remove this could be added but is not planned in this PR.

Usage

This should be agnostic to the SSO used as long as it support client secret authentication and expose an OpenID Connect Discovery endpoint. (I'm testing it with Keycloak at the moment, a demo test stack is avaible README.md)

Added some documentation at the root of the project SSO.md that could be later moved to the wiki.

I made some additionnal modification in my main branch to allow for easier testing (modified Docker image to use prebuilt patched front-end).

On front-end modification, I made patched versions available at Timshel/oidc_web_builds. Two versions are available :

• One only restore the SSO login button
• Other one additionally :
  • set #sso as the default redirect url and remove some unnecessary logic
  • allow organization invitation to survive sso redirection

Only the first one is expected to be merged since only change compatible with the non-sso version will be accepted.

Issues

As mentioned in the previous PR one of the main issue is the inability for the organization invitation to work with the SSO redirection. To fix it a patch to the front-end is needed.

⚠️⚠️ ⚠️ If you have issues or need help testing the PR ⚠️ ⚠️ ⚠️

Please open issues in Timshel/vaultwarden in order to keep the discussion here focused on merging this work.
Of course if you believe your issue is important mention this PR so a reference will be visible.

But please try to keep commenting in this PR to a minimum to keep it legible, the previous one has over 200 comments ...

[derfabianpeter]

Super happy to see this PR being worked on. We (ayedo.de) would be willing to offer a sponsoring to prioritize this PR if that helps! Just reach out.

[Timshel]

Just added a configuration example for Gitlab which might be one of easiest way to test this PR :).

[AkechiShiro]

Hi @Timshel, thanks for your amazing and prolonged work on this feature, is this PR close to be in a ready merge-able state or is there a lot of work left?
I see the latest commit is about documentation, so, all issues mentioned at the beginning were fixed in some way or another ? Or there are still issue to fix ?

[Timshel]

Mainly waiting for maintainer review/feedback now :).

[ruben-herold]

@Timshel thx for your work!!! Hope this will be integrated soon

[pellux-network]

Hoping this gets merged soon!

[AkechiShiro]

Tagging some maintainers for review on this PR, if they have the available time resource to do so @BlackDex @dani-garcia

EDIT: I don't understand the thumbs-down, because tagging maintainers doesn't mean they have time to handle the PR or review it, it's just a way to mention them, if they don't answer/go MIA, or whatever, feel free to fork on this PR and maintain your own forks, no one is entitled to do any work, they don't want to.

[BlackDex]

I do not have much time actually.

Also, I'm a bit puzzled with all the different SSO PR's.
And I am a bit hesitant to merge one if that for some reason could break the other or has a totally different way of working.
I'm not sure what to do here because i see people want something like this, but there are multiple ways of getting this working it looks like.

One way would be to create a semi-supported release branch which contains SSO support, but that could get messy keeping it up-to-date. What do you think @dani-garcia ?

[Timshel]

? As mentioned this is the continuation of the previous PRs, it all rely on openidconnect. All of those PR are based on the previous ones when the previous PR owner stopped maintaining it.

I can´t speak for the owner of previous PRs but I believe this make all the others redundant. You could probably close the previous one referencing this one and encourage their owner to reopen if something is missing.

Thanks @bmunro-peralex for closing his PR to make things more legible and of course for his work which is present in this PR :).

[xoxys]

Why not finally add at least one way to support OIDC? You can also flag it as preview feature or something like this to get feedback from the community, but not getting this feature into Vaultwarden after multiple PRs were provided by the community without a review or without getting merged for months until the authors then gave up feels wrong to me for an open source project.

[BlackDex]

Why not finally add at least one way to support OIDC? You can also flag it as preview feature or something like this to get feedback from the community, but not getting this feature into Vaultwarden after multiple PRs were provided by the community without a review or without getting merged for months until the authors then gave up feels wrong to me for an open source project.

Well, because One way could be a different way then the others, or could cause a lot of other changes needed to be done if they do not match, or maybe even could overlap and do something totally different. 49 FIles are changed, so I'm not going to be happy if there needs to be major rework done because of adding this feature which is not fully working/supported.

You have to keep in mind that this could break other code in some way. But as said before, i do not have much time to check and validate this. And this is a huge PR and a lot of testing needs to be done, and i this is not specifically on my prio list for now actually. That is why i mentioned a special branch, which builds this version with a different tag and not fully supported in terms of issues with the login from my side.

[Timshel]

Well, because One way could be a different way then the others, or could cause a lot of other changes needed to be done if they do not match, or maybe even could overlap and do something totally different.

@BlackDex I'll insist but there is no other way (At least not in the currently opened PRs). All those PR are based on the previous ones. They got more refined each time as someone picked-it up.

[tschuyebuhl]

is there any way one can help with testing? or anything that can be done to help get this merged?

[isaiah-v]

I've been watching the progress of this feature. I can't wait for it, but out of curiosity, how does decryption work with this feature? Is it still client side? How do you now decrypt without knowing the password?

[Timshel]

@isaiah-v as mentioned a master password is still required. There is no change on this point.

[Timshel]

@BlackDex thinking on it I don´t think the semi-supported branch is a good idea.

Main issue for people running this branch is that there might be some change in the migrations that might force to correct DB state manually. Even if it's not difficult (cf Timshel/vaultwarden#db-migration), integrating in a separate branch would not help with this.

Additionally unless you grant me commit rights it means that this would make it more complicated for me to support it and if you have no time for review I can't see how you would semi-support it.

It's important to note that the SSO_ENABLED config act as feature flag, the impact on the non sso version is quite low so merging this should have a low risk for the non sso users.

In the end if people are not running it at the moment it might be because they are waiting for an easier way to run this (but I made updates on main@Timshel/vaultwarden to make it easier) but I would expect it's mainly because they are waiting for it to be reviewed, a solution without any review would not be worth much ...

Since I'm running this myself I will maintain this branch/PR, and will continue to update main@Timshel/vaultwarden with anything I can think of to help people running it. As mentioned before if you have any question don't hesitate but please open it on Timshel/vaultwarden to prevent spamming here (of course mention this PR if you think your issue is important).

In my opinion the next step is for it to be reviewed and then integrated (maybe without being promoted at first).

[AkechiShiro]

I will definitely try to host the branch of your fork that contains sso-support and see if I run into any issues, I will report them on your repo @Timshel

[dandanthedev]

+1, please merge!

[griefie]

It seems that there is a lot of hesitation on investing time into reviewing this and i can understand this. However - the longer the delay the bigger the diff guys. The branch clearly works and simply needs a bit more love. Besides it already looks like a lot of work went into this and the older preceding branches. Why not make it a beta build? Even 2.0.0-beta? The closer it is to the main stream, the quicker will be the feedback and the improvement. Let's not forget this is open source, where ideas thrive and not corporate where ideas die ;)

[derfabianpeter]

We're still happy to sponsor this PR if it helps

[Timshel]

Rebased and added the @BlackDex suggestion in #3154 (comment) to make the SSO button visible when running the docker-compose.

[BlackDex]

I think we have tackled the sync issues with the clients 🤞🏻 which makes it more likely to have this merged soon.

It also depends on @Timshel if he thinks it's fine as-is currently and able to act upon issues linked to this.
Then we can have this in testing for a while.

[Timshel]

It also depends on @Timshel if he thinks it's fine as-is currently and able to act upon issues linked to this.

@BlackDex It is and I will.

[Talkabout]

Hi guys,

I am also very interested in getting this feature. Hope you can progress with it soon! I assume that it will take some time for the tests to complete before we will see it in a release? Any time frame for that?

Edit:

I am using Vaultwarden in Docker. If possible, I'd love to help you testing it!

Thanks!

[BlackDex]

@Timshel could see if you can use the new Dynamic CSS feature for this PR?
Also, if i'm correct, you need some additional changes on the web-vault side too? If so, there is no PR for that yet.
If you do not need any additional changes, you can use dani-garcia/bw_web_builds#180 to test/verify the Dynamic CSS.

[Timshel]

@BlackDex Yes I intend to switch to it, had a quick look but was waiting for dani-garcia/bw_web_builds#180 to be released.

[BlackDex]

Well, if it is up to me, it's either i try to fix v2024.10.5 to work and have the dynamic-css in there.
If that takes too long or seems rather more difficult, then i tend to go to merge the v2024.6.2 update.

Also, not sure if v2024.10.5 is workable for SSO without too much changes?

[Timshel]

Also, not sure if v2024.10.5 is workable for SSO without too much changes?

I have a build based on v2024.10.2 so it should be ok. Had to change the Playwright tests for v2024.8 but not much issue with 10 if I remember correctly.

[Timshel]

Hey,

Just wanted to mention that discussion for some funding fell through.
As I commented recently I will continue to maintain the PR, but it does mean this will not be a priority (docker distribution might lag behind unless the Vaultwarden release includes some CVE fixes).

Lastly thank you for those who choose to support my work ;).

[sandervandegeijn]

A PR is not meant to be maintained, just to get something done and then merged. What would you need to get this merged?

We can't run a fork of one developer as a production instance, too risky. I won't commit the resources for a pentest to a fork either, it's tax payers money, need at least some kind of certainty that the functionality will be merged before we can give the go ahead on the pentest.

[Timshel]

Just received an extremely generous one time sponsor (which I won't mention since I can't confirm with them that it's ok); Thank you :).

This means that:

• I'll build a web-vault based on Add dynamic CSS support bw_web_builds#180, test the new CSS templates and release it in testing.
• Test a web-vault based on top of Bitwarden v2024.11.2
• Start testing the integration of openidconnect-rs 4.0.0-rc.1

[fullstackdesign-xyz]

A PR is not meant to be maintained, just to get something done and then merged.

@sandervandegeijn I understand your point, and I agree that a PR isn't typically meant to be "maintained" indefinitely. However, I'd like to point out that @Timshel opened this PR on June 29, 2023, and the maintainers' detailed feedback or a thorough code review is still pending.

[BlackDex]

A PR is not meant to be maintained, just to get something done and then merged.

@sandervandegeijn I understand your point, and I agree that a PR isn't typically meant to be "maintained" indefinitely. However, I'd like to point out that @Timshel opened this PR on June 29, 2023, and the maintainers' detailed feedback or a thorough code review is still pending.

I think i have done some detailed testing and reviewing, but ok not here to debate this (again).

Also, I did asked here #3899 (comment) if he could check the web-vault part, since there is no PR at all linked to this PR, and without that merging this would be useless, that is not something you can blame on the maintainers of this project.

And, it's not the look for excuses, but i do hoop people see there are not a lot of maintainers for this project, so if someone wants to help us out during there free time, please fork, code and share!

And the past few months there were CVE's reported, and I do prioritize those over any PR.
Same goes for client issues like with the new native mobile clients (which seem to still be happening sometimes).

Merging this PR while those issues are still there doesn't make it easier to troubleshoot and debug those reported issues. As for some strange reason this PR could have caused some strange side-effect somewhere.

[fullstackdesign-xyz]

A PR is not meant to be maintained, just to get something done and then merged.

@sandervandegeijn I understand your point, and I agree that a PR isn't typically meant to be "maintained" indefinitely. However, I'd like to point out that @Timshel opened this PR on June 29, 2023, and the maintainers' detailed feedback or a thorough code review is still pending.

And the past few months there were CVE's reported, and I do prioritize those over any PR. Same goes for client issues like with the new native mobile clients (which seem to still be happening sometimes).

@BlackDex thank you for your dedication to keeping the project secure and stable. I understand that maintainers have limited time and that critical issues like CVEs and client bugs take priority.

[Timshel]

Just pushed the dynamic css change (conditionally hide Master password or SSO button) so testing release should take around 30min still.

@BlackDex for the web-vault part I never opened the PR due to the project structure which makes it a pain to maintain a PR. But all patches are available here: https://github.com/Timshel/oidc_web_builds.

The interesting patch are:

• oidc_invite.patch Needed for the org invitation to work with SSO if the account does not already exists.
• oidc_subpath.patch Fix the base url resolution during redirection.

Lastly I believe the oidc_sso_errors.patch would probably make sense to display the errors would just need to change the redirection path.

I'll update the button distribution (the one which reflect what I expect could be merged) to include the corrected error patch.

[rizlas]

@sandervandegeijn this pentesting thing, is now like politician saying they will reduce taxes during election time. 😅 Sorry but I don't believe it anymore.

Anyway, I think that both @Timshel and @BlackDex were very clear on how this PR will proceed in the previous comments. I was an early adopter of Timshel's fork and I'm still using it. In the first phases I mainly contributed with feedback and improving suggestions and, as of today, it is almost one year that my deploy is working flawlessly. During the all year I've never post a comment like "pls merge", that's useless, so why people keeps doing it? Use the fork if you really need this or pay BW (or others) if you can't. For example, as a non-profit we couldn't afford any paid solution and we took a gamble with Timshel fork, and it was worth it!

I'm grateful that someone is contributing with money, keeping the whole thing going. 🙏🏻

Thank you again @Timshel for your fork and @BlackDex for VW.

[rudiservo]

@rizlas pentesting is important, recently some stuff was found in vaultwarden, not very bad stuff but still something that improves the safety and security of all that use the software.
Let's not forget the XZ project fiasco that was or was not state sponsored.

I probably have more sleepiness nights with cybersecurity than having a newborn baby, I miss programming.

Nonetheless I know the issue of accepting a PR this big, Rust is a complex language, yes adding functionality should be easier in one hand but still be safe on the other, maybe the structure needs to be revised, but that is the thing with software development, stuff happens.

Having an OpenSource project like this is fantastic on it's own, having one with so many eyes on it is amazing.

So let's get together and keep communicating so we can get this thing merge.