josef
November 5, 2024, 10:42am
1
Hello everyone! I would like to know how to configure this field that appears on the admin page of Vaultwarden. This version of Vaultwarden comes from Timshel’s repository, where it has SSO-enabled and SSO-support. I understand that the SSO_MASTER_PASSWORD_POLICY field configures the master password, but I’m not sure how it should be set up, or if it’s possible to configure it so that users don’t need to enter the master password, allowing access only through SSO.
Thank you very much; I look forward to your response!
I guess it’s not possible.
A master password is still required and not controlled by the SSO (depending on your point of view this might be a feature ;).
main ← Timshel:sso-support
opened 10:25AM - 18 Sep 23 UTC
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 on your point of view this might be a feature ;).
Bitwarden [key connector](https://bitwarden.com/help/about-key-connector) is not supported and due to the [license](https://github.com/bitwarden/key-connector/blob/main/LICENSE.txt) it's highly unlikely that it will ever be:
> 2.1 Commercial Module License. Subject to Your compliance with this Agreement, Bitwarden hereby grants to You a limited, non-exclusive, non-transferable, royalty-free license to use the Commercial Modules for the sole purposes of internal development and internal testing, and only in a non-production environment.
## Usage
This should be agnostic to the SSO used as long as it supports client secret authentication and expose an OpenID Connect Discovery endpoint. (I'm testing it with Keycloak at the moment, a demo test stack is available [README.md](https://github.com/Timshel/vaultwarden/blob/sso-support/test/oidc/README.md))
Added some documentation at the root of the project [SSO.md](https://github.com/Timshel/vaultwarden/blob/sso-support/SSO.md) that could be later moved to the wiki.
I made some additional modification in my [main branch](https://github.com/Timshel/vaultwarden/blob/main/README.md) 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](https://github.com/Timshel/oidc_web_builds). Two versions are available :
- One contains the change expected to be merged (named `button`); all change needs to be compatible with the non-sso version.
- Second one set `#sso` as the default redirect url.
## 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](https://github.com/Timshel/oidc_web_builds/blob/master/oidc_invite.patch) to the front-end is needed.
## **:warning::warning: :warning: If you have issues or need help testing the PR :warning: :warning: :warning:**
Please open issues in [Timshel/vaultwarden](https://github.com/Timshel/vaultwarden/issues) 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 ...
It seems that SSO_MASTER_PASSWORD_POLICYis a JSON to enforce things like complexity.
## Additionnal authorization url parameters (ex: to obtain a `refresh_token` with Google Auth).
# SSO_AUTHORIZE_EXTRA_PARAMS="access_type=offline&prompt=consent"
## Activate PKCE for the Auth Code flow.
# SSO_PKCE=true
## Regex to add additionnal trusted audience to Id Token (by default only the client_id is trusted).
# SSO_AUDIENCE_TRUSTED='^$'
## Set your Client ID and Client Key
# SSO_CLIENT_ID=11111
# SSO_CLIENT_SECRET=AAAAAAAAAAAAAAAAAAAAAAAA
## Optional Master password policy (minComplexity=[0-4]), `enforceOnLogin` is not supported at the moment.
# SSO_MASTER_PASSWORD_POLICY='{"enforceOnLogin":false,"minComplexity":3,"minLength":12,"requireLower":false,"requireNumbers":false,"requireSpecial":false,"requireUpper":false}'
## Use sso only for authentication not the session lifecycle
# SSO_AUTH_ONLY_NOT_SESSION=false
## Enable the mapping of roles (user/admin) from the access_token
# SSO_ROLES_ENABLED=false
## Missing/Invalid roles default to user
# SSO_ROLES_DEFAULT_TO_USER=true
## Id token path to read roles
# SSO_ROLES_TOKEN_PATH=/resource_access/${SSO_CLIENT_ID}/roles
## Enable the mapping of organization
# SSO_ORGANIZATIONS_ENABLED=false
A master password is still required and not controlled by the SSO (depending on your point of view this might be a feature ;).
Forgive me for my stupidity, but does this not defeat the whole purpose of SSO? My users will 100% complain and ask why they still need a second password.