Fork from dani-garcia/vaultwarden
Goal is to help testing code for the SSO PR. Based on Timshel/sso-support
This branch now contain features not added to the SSO PR since it would slow even more it's review.
Allow to map roles from the Access token to users to grant access to VaultWarden
admin
console.
Support two roles: admin
or user
.
This feature is controlled by the following conf:
SSO_ROLES_ENABLED
: control if the mapping is done, default isfalse
SSO_ROLES_DEFAULT_TO_USER
: do not block login in case of missing or invalid roles, default istrue
.SSO_ROLES_TOKEN_PATH=/resource_access/${SSO_CLIENT_ID}/roles
: path to read roles in the Access token
Allow to invite user to existing Oganization if they are listed in the Access token. If activated it will check if the token contain a list of potential Orgnaization. If an Oganization with a matching name (case sensitive) is found it will the start the invitation process for this user. It will use the email associated with the Organization to send further notifications (admin side).
The flow look like this:
- Decode the JWT Access token and check if a list of organization is present (default path is
/groups
). - Check if an Organization with a matching name exist and the user is not part of it.
- Depending on
SSO_ACCEPTALL_INVITES
: false
- Invite the user to the Orgnization- The user will need to click on the link in the mail he received
- A notification is sent tto he
email
associated with the Organization that a new user is ready to join - An admin will have to validate the user to finalize the user joining the org.
true
- Add the user to the Organization- A notification is sent to the user to inform of the enrollment in the org
- A notification is sent to the
email
associated with the Organization that a new user is ready to join - An admin will have to validate the user to confirm the user joining the org.
If email are disabled then the user will silently be enrolled and the admin will need to check the org to finish the process.
One of the bonus of invitation is that if an organization define a specific password policy then it will apply to new user when they set their new master password.
If a user is part of two organizations then it will order them using the role of the user (Owner
, Admin
, User
or Manager
for now manager is last :() and return the password policy of the first one.
This feature is controlled with the following conf:
SSO_SCOPES
: Optional scope override if additionnal scopes are needed, default is"email profile"
SSO_ORGANIZATIONS_INVITE
: control if the mapping is done, default isfalse
SSO_ORGANIZATIONS_TOKEN_PATH
: path to read groups/organization in the Access token, default is/groups
This branch now contain additionnal features not added to the SSO PR since it would slow even more it's review.
Allow to map roles from the Access token to users to grant access to VaultWarden
admin
console.
Support two roles: admin
or user
.
This feature is controlled by the following conf:
SSO_ROLES_ENABLED
: control if the mapping is done, default isfalse
SSO_ROLES_DEFAULT_TO_USER
: do not block login in case of missing or invalid roles, default istrue
.SSO_ROLES_TOKEN_PATH=/resource_access/${SSO_CLIENT_ID}/roles
: path to read roles in the Access token
Change the docker files to package both front-end from Timshel/oidc_web_builds.
By default it will use the release which only make the sso
button visible.
If you want to use the version with the additional features mentionned, default redirection to /sso
and fix organization invitation.
You need to pass an env variable: -e SSO_FRONTEND='override'
(cf start.sh).
Docker images available at:
- Docker hub hub.docker.com/r/oidcwarden/vaultwarden-oidc
- Github container registry ghcr.io/timshel/vaultwarden
By default front-end version is fixed to prevent regression (check CHANGELOG.md).
When building the docker image it can be overrided by passing the OIDC_WEB_RELEASE
arg.
Ex to build with latest: --build-arg OIDC_WEB_RELEASE="https://github.com/Timshel/oidc_web_builds/releases/latest/download"
This allow to stop storing the Master password in the server database. This is a work in progress and released for testing. Once activated newly created account will no longer store a master password hash, making reverting to a standard VaultWarden instance troublesome.
SSO_EXPERIMENTAL_NO_MASTER_PWD
: Control the activation of the feature. Defaultfalse
.
Additionnaly a new web build is available which stop sending the hash cf experimental
in Timshel/oidc_web_builds
You'll need to pass an env variable: -e SSO_FRONTEND='experimental'
(cf start.sh).
You'll first need to run the server without the experimental
front-end.
You can then go to Account settings \ Security \ Keys
and trigger the Change KDF
.
This endpoint is not modified and will save the new master password hash, every user will need to do this to restore a Master password in db.
ATM The migrations add an independant table sso_nonce
and a column invited_by_email
to users_organizations
.
Reverting to the default VW DB state can easily be done manually (Make a backup :) :
>BEGIN;
BEGIN
>DELETE FROM __diesel_schema_migrations WHERE version in ('20230910133000', '20230914133000');
DELETE 2
>DROP TABLE sso_nonce;
DROP TABLE
>ALTER TABLE users_organizations DROP COLUMN invited_by_email;
ALTER TABLE
> COMMIT / ROLLBACK;
sso_nonce
table in a recent commit.:warning:
If you already deployed the previous version you'll need to do some manual cleanup :
>BEGIN;
BEGIN
>DELETE FROM __diesel_schema_migrations WHERE version = '20230201133000';
DELETE 1
>DROP TABLE sso_nonce;
DROP TABLE
> COMMIT / ROLLBACK;
Then the new migration will play without issue.