SSO using OpenID Connect #3899
SSO using OpenID Connect #3899
Conversation
Timshel
force-pushed
the
sso-support
branch
2 times, most recently
from
e344cad
to
ecbe5e3
Compare
Timshel
force-pushed
the
sso-support
branch
from
ecbe5e3
to
77fe2b3
Compare
|
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
force-pushed
the
sso-support
branch
2 times, most recently
from
c86e481
to
d5f78b4
Compare
|
Just added a configuration example for Gitlab which might be one of easiest way to test this PR :). |
|
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? |
|
Mainly waiting for maintainer review/feedback now :). |
|
@Timshel thx for your work!!! Hope this will be integrated soon |
|
Hoping this gets merged soon! |
|
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. |
|
I do not have much time actually. Also, I'm a bit puzzled with all the different SSO PR's. 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 ? |
|
? 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 :). |
|
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. |
@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. |
|
is there any way one can help with testing? or anything that can be done to help get this merged? |
|
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? |
|
@isaiah-v as mentioned a master password is still required. There is no change on this point. |
|
@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 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). |
|
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 |
|
+1, please merge! |
|
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 ;) |
|
We're still happy to sponsor this PR if it helps |
|
Rebased and added the @BlackDex suggestion in #3154 (comment) to make the |
|
Since I'm using it after it's merged I'll still be around and able to help if needed. Anyway just rebased on lastest from |
Is there an accompanying docker build available to use to test it? |
Checkout this PR and follow the instructions in the docker directory. |
If you mean the |
|
@Timshel I'm willing to use my resources as a TrueCharts maintainer to offer your "beta" container as an option for testing to all our users if you like :) |
|
@Ornias1993 not sure what this would entail but if you want to discuss it please open an issue in timshel/vaultwarden. |
Nothing on your side at all, no worries... |
**Description** @Timshel is working hard on implementing SSO into vaultwarden in dani-garcia/vaultwarden#3899. This allows users of TrueCharts to select his BETA container on TrueNAS SCALE. Image previously was made available as an image selector using Helm already **⚙️ Type of change** - [x] ⚙️ Feature/App addition - [ ] 🪛 Bugfix - [ ]⚠️ Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] 🔃 Refactor of current code **🧪 How Has This Been Tested?** <!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration --> **📃 Notes:** Please be aware this is still BETA code. **✔️ Checklist:** - [ ] ⚖️ My code follows the style guidelines of this project - [ ] 👀 I have performed a self-review of my own code - [ ] #️⃣ I have commented my code, particularly in hard-to-understand areas - [ ] 📄 I have made corresponding changes to the documentation - [ ]⚠️ My changes generate no new warnings - [ ] 🧪 I have added tests to this description that prove my fix is effective or that my feature works - [ ] ⬆️ I increased versions for any altered app according to semantic versioning - [ ] I made sure the title starts with `feat(chart-name):`, `fix(chart-name):` or `chore(chart-name):` **➕ App addition** If this PR is an app addition please make sure you have done the following. - [ ] 🖼️ I have added an icon in the Chart's root directory called `icon.png` --- _Please don't blindly check all the boxes. Read them and only check those that apply. Those checkboxes are there for the reviewer to see what is this all about and the status of this PR with a quick glance._ --------- Signed-off-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
@Ornias1993 in general I tend not to respond when people ignore this but. Even if I have nothing to do I hope you will consider the following considerations :
Anyway once again if you want to discuss the subject further please as mentioned in the PR itself and my previous comment open an issue. I would like to try to keep the discussion here focused around merging this. |
I'm not opening an issue there, because there is nothing to write an issue about. Basically I was just trying to be polite and help you out by getting more test hours done. TBH, I expected more of a "thank you".
I've no idea what you're trying to say here. But thats how I decided to flag it for our users. If you've a problem with that you can reach out to our team. But that doesn't belong here.
Thats a good point, luckily we always advice users to report issues to use directly first
There is nothing to debug, no worries and we actively advice users to report issues with us first. That being said: if there is anything to debug, that is also quite important information, because that means the code build into your docker container has unexpected deviating behavior in things like permission and networking (the primary two causes of issues), which automatically makes it worthwhile. But I don't expect such a thing after code verification. TLDR: Sidenote: Kubernetes users are more likely to be needing/wanting SSO though, so I hope this can get some more testing hours in. |
|
I'm running vaultwarden in kubernetes with and without @Timshel additions just fine. No problem in the dockerization. Helm charts, on the other hand, can be a source of errors if the templating is incorrect or something else. e.g. It is not uncommon to find errors in bitnami's charts. I guess that helm here is completely off topic. |
Thank you Mathijs, Daniel and Timshel for this incredible project and PR. @Ornias1993 you are borderline advertising and being rude after a valid request to move the convo elsewhere. You then go on to make a similar point yourself (see quote below). Not sure how you can expect thanks with an attitude like that. Timshel is well within expected practices to have questions and concerns. Just answer them with the same politeness if you are genuinely interested in helping, no need for snark.
Exactly. |
Full agreement, thanks so much ❤️
Phew, why so rude? @Ornias1993 just communicated that they're going to provide a HelmChart based on this PR and that this will result in more testing of it. That's a great contribution in my opinion. I think the communication between him and Timshel was a bit led by missunderstanding. Everyone, please assume good faith 😉 |
On the face of this POV, sure - I agree. Expecting gratitude only without any further comments is concerning though, especially after disregarding a simple request to move the convo to a better location. Maintaining OSS is hard. Respecting an authors simple request for something that make their lives easier is kind of a basic decency. I tolerate a lot and almost always assume good faith, but will still call out unneeded disrespect. I think there is more nuance in the reply to Timshel that you may not see? It smells of entitlement (or worse, but this is me assuming good faith), which is a massive problem in OSS. Not the convo for here though, so let's move on. |
This should be the main takeaway here. If anyone has anything else to add or think they need to defend themselves or call out others: Don't. Do it privately if you must, but this here just isn't the place for that. I'm sure we'd much rather get notifications from this thread that are about the PR itself 💜 |
|
@binaryben to be clear: I did not expect or demand gratitude. I just tried to explain that I expected a more "supportive" response. kinda agree with @mejo- that this was most-likely mostly a complete communitation fbar between me and Timshel and there was no need to start accusations of advertising and being purposefully unfriendly, entitled and/or uncollaborative. I wanted to add some value and contribute to this effort, within my specific area of expertise. Which is: running helm-charts and kubernetes clusters. Edit: @mgundelfinger Agreed, shame our comments coincided. |
Cool, I'll work on throw the Timshel additions up on my cluster this week to test them out and document the process.
Agreed, thats why I look forward to testing how-well this runs as a "drop-in-replacement". |
|
@rizlas Found at least one issue where the container by @Timshel deviates from the source that is of-value to kubernetes users: Vaultwarden normally runs fine with "ReadOnlyRootFilesystem" enabled, however the Timshell container relies on being able to write to the root filesystem to create a webvault symlink. I assume this is not going to be an issue in the release, but is relevant for users trying to test this on kubernetes with full-security enabled. |
|
I have met with our penetration testing partner today. We will receive a quote to:
With the emphasis on the white box test. Rust is an odd one for them, but they are looking into it. We can't submit the whole report to the community but we can share the individual issues that they might find. If the quote is reasonable we will execute the test when the merge has been done. |
May I ask why? its great either though, I'm also looking at setting up a hosted environment for more users... |
|
Long story short: legal stuff. Can't do too much about that, but you can trust us to share all relevant details with the community. That's in everybody's best interest including ours :) Forgot to mention, there will be focus on the OIDC as well of course. |
|
Hello, Do you have any idea when this option will be available in the main project? I believe that all checks have been passed and it just needs a double check. This feature would help avoid some of my headaches. Thank you, |
How about you put some effort in and actually read the last dozen or two responses here? |
I've asked because I didn't fund a clear answer. (I'm very sorry in case it was present) |
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 :
#ssoas the default redirect url and remove some unnecessary logicOnly 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.
Related PR
In an effort to try to simplify the review of this PR some change were isolated in separate 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 ...