OIDC SSO #2449
OIDC SSO #2449
Conversation
| struct SsoOrganizationData { | ||
| // authority: Option<String>, | ||
| // clientId: Option<String>, | ||
| // clientSecret: Option<String>, |
There was a problem hiding this comment.
Commented out properties. Can probably be removed, can't it?
There was a problem hiding this comment.
Depends, if those items are sent by the web-client or other clients then having those as an Option would be a better choice.
If they are not needed at all, then removing them is the better option.
There was a problem hiding this comment.
They were added in newer versions of the web-client. They are not used/needed anywhere, I assume they are for other kinds of SSO configuration. The older web-client had a lot less options and inputs than the current version.
|
@pinpox is this PR ready for review? |
I'm sure there is still stuff to do, but it would be great if you could could give me a first review, so I know where to continue on working. |
|
Does this implementation include support for key-connector or would that be a separate feature request / PR? |
The key-connector is not part of this PR.
Yes, the password is used to encrypt the vault and still required. |
|
First, sorry for not checking this earlier. I did some quick checking. And i probably missed some important stuff to nag about 😉 The patch which is currently in this PR is probably also out-of-date. What I would also like, is some small howto on how i can test this my self? |
|
About LDAP servers, I am building a LDAP server with a test suite in full docker. Feel free to steal anything you may need: https://github.com/sudo-bot/docker-openldap |
|
Hey, thanks for looking into it!
The PR is still marked as
Here are the basic steps to test this, keep in mind it's not all working yet. Start a gitea (e.g. with the docker instructions from their site) and add an application under `https://mygitea.tld/user/settings/applications/oauth2/1` like this
Login to vaultwarden (the normal way) and create a organization, set the identifier to the organization name you set before
Then, in the web-vault go to `Enterprise single sign-on" and login with the identifier you created
|
|
In case someone can help out or knows how to fix it, this is the current blocker: EDIT: |
|
Might be easier to use something made for SSO authentication - https://keycloak.org. Bit clunky but it works |
I have tried keycloak but it is quite complex for the very few options we need to test this. It is for sure "the right tool" but I recommend testing with gitea just because it's simpler to set up in a minute. |
Is this https://your.domain.com/sso/oidc-signin. I got it from https://bitwarden.com/help/oidc-azure/ https://bitwarden.com/help/oidc-okta/ |
|
I have got OIDC login working now! 🥳 I still need to look in to an issue with the front-end (Currently configuring it by setting the values in the DB manually) and some other minor issues.
The current implementation indeed uses |
|
Ah this the only thing left to make sure my mom can use it without her forgetting her password. Just curious how far are you? |
This will not prevent forgetting a password, since you still need a master password which can be the same as the linked sso of course, but that will not be secure of course. |
|
Wait it will be an extra layer. So you will need oidc then login with master password then you will access your vault |
|
That's what key-connector is for. |
This branch is already functional in the backend, you can login with SSO already. What is missing is fixing the front-end part, currently you have to configure it on the DB itself by just setting the values in
That is correct. The master password is used to derive the encryption key for your vault, so it needs to be provided either by you or by the key-connector.
The connector isn't part of this PR and I have not looked into it yet. Is that something we can even support? Is that a separate piece of software or is it part of the backend? |
The key connector is described here: https://bitwarden.com/help/about-key-connector/ |
A quick look at the code (without having it compiled etc..) i think that the response for the It should look like this, not sure if that is what you currently get, or that it is wrapped into another layer. {
"enabled": true,
"data":
{
"configType": 2,
"keyConnectorEnabled": false,
"keyConnectorUrl": "",
"...CUT...": "...CUT..."
},
"urls":
{
"callbackPath": "https://vw.domain.tld/sso/oidc-signin",
"signedOutCallbackPath": "https://vw.domain.tld/sso/oidc-signedout",
"spEntityId": "https://vw.domain.tld/sso/saml2",
"spMetadataUrl": "https://vw.domain.tld/sso/saml2/{org_uuid}",
"spAcsUrl": "https://vw.domain.tld/sso/saml2/{org_uuid}Acs"
},
"object": "organizationSso"
} |
|
Thank you to everyone working on this. Currently, Is there something we can do to help with this? Can we test something? Thanks and cheers! |
|
Bump |
|
Hey, sorry have been a bit busy lately.
If anyone with rust experience wants to help, I'm happy to integrate pull requests on my branch and consolidate the work in some form we can get merged. |
|
I'm trying to understand what's still necessary. Do I understand right that basically on the backend the |
I've had a look at this and it looks like that Backend-wise, from what I've seen there also seem to be some open ends:
|
|
Thanks for taking a look too and I agree. Unfortunately, as far as I can tell, this entire branch is rather behind the main branch now, since this has been dragging on for so long. At this point, I'm wondering if it might be more efficient to make a new branch off of main and try and port Pinpox' work into that and at the same time prepare the changes necessary to the web-vault. Unfortunately, as I'm not experienced with Rust, it seems that the work required here is above my level. Pinpox has prepared and given me a state of the code that runs and looked relatively clean (if based on old VW code), so I'm sure that they're willing to help anyone else getting a running state to work off of. |
|
Bump, would also be interested in this to work. |
|
+1 for authentik. Although I think that SSO should definitely not be implemented in a way that requires a specific SSO provider |
|
Another +1 for Authentik. Moved from FreeIPA + Keycloak/Authelia for this as they just don't keep up anymore and Authentik will be big eventually as it just evolved into a proper company with staff a few months back. However I don't believe that by implementing OIDC or SAML we will be locking anyone into a specific platform |
|
The problem isn't the SSO instance. Keycloak, Authentik, it's all the same in the end. If you find it easier to work with, that's nice and if that lets you help with the code, awesome! But the issue is really just that currently the code of Pinpox' branch has diverged from main, and someone who understands Rust well enough needs to take Pinpox' work and rebase or port it onto main. On top of that, someone would need to untangle the webvault and add all the necessary changes into that to both allow logging in with SSO as well as to allow configuring all of this without having to manually edit the database. |
|
I would love to test this out, I use JumpCloud + AWS Identity Center for SSO. Is there a ready made docker image or do I need to burn my own? |
Well, this current PR isn't up-to-date with the present code, and it seems to have some conflicts. |
|
Would be up to sponsor this feature, if someone needs incentive to implement |
|
I would also be happy to contribute in the area of sponsorship. ;-) |
|
I would also provide some sponsorship :) |
Yes, of course it is. OIDC is a standard. The discussion originally was just how to test this easily. Stop recommending auth providers, this is completely off topic for this. |
|
I find it extremely strange that a password manager for teams does not support SSO. |
|
@pinpox do you still work on this MR? I'd like to help, but as my knowledge of Rust is very limited, I'm afraid I could only help financially or by testing. |
|
@pinpox Maybe close this PR then? |
@BlackDex Since @pinpox itself has pointed to another PR which again has been superseeded by #3899 maybe close this PR if @pinpox doesn't do it? Would certainly help to clean up the confusion about too many SSO merge requests that are basically just building off of one another :) |
|
Closing this PR in favor of #3899 to keep overview of it all. |
Continuing the PR by @Sheap #1955. Work in progress.