Follow-up to the previous two commits, all four issues were introduced by them:
- The legacy `access_all`-group authority was accepted by
`caller_may_grant_collection_manage`, so a Custom member with manageGroups +
editAnyCollection could create an access_all group holding itself, use the
derived authority to persist `collections_groups.manage`, then leave the group
and keep collection deletion without ever holding deleteAnyCollection. The
clamp now takes only a real stored grant again, and the legacy exception is
limited to members holding none of the three collection permissions -- which
is the shape the migration leaves a group-derived Manager in, and never a
member who can create such a group in the first place.
- `Collection::to_json_details` reported `manage: false` for a member reaching
every collection even when a real grant existed, so the client rendered
controls that disagree with the guards. Both the cached and the uncached path
now read the effective grant.
- The SQLite rollback script continued after a failed statement, so a second run
dropped `users_organizations` and committed an empty replacement. It now sets
`.bail on`, refuses up front unless the permission columns are present, and
the README documents `-bail` instead of claiming the run is atomic regardless.
- The downgrade acknowledgement was never consumed, so one approval authorized
every later revert. It is now dropped by the revert it permits and cleared
again on re-upgrade.
Vaultwarden only ever applies pending migrations, so putting an older image
back leaves it facing a schema whose `access_all` column is gone -- and it
refuses to start. The downgrade guard did not help there either: it only ever
blocked `diesel migration revert`, which a self-hosted install cannot run.
- tools/custom_role_rollback/ holds a self-contained script per backend that
restores the pre-PR schema, folds Custom back onto Manager, and drops the
seven ledger rows, so the older version starts again. SQLite rebuilds the
table instead of using DROP COLUMN, for the same 3.35 reason as the forward
migration.
- The guard now states its terms instead of being a dead end: create
__vw_allow_custom_role_downgrade and the revert goes through, so the data
loss is acknowledged rather than merely prevented.
- README documents what the old schema cannot represent, including the two
values that cannot be reconstructed: Owner/Admin return with access_all set,
and a plain User's former access_all stays materialized as the per-collection
assignments the upgrade wrote.
- SQLite: the access_all drop used ALTER TABLE ... DROP COLUMN, which needs
SQLite 3.35 while a sqlite_system build links whatever the host provides and
libsqlite3-sys accepts 3.34.1. Use the portable table rebuild instead.
- Preflight: it returned Proceed for every database carrying the repair
migration. Both the access_all drop and the access-permission columns run
after that repair, so their interrupted MySQL/MariaDB states went undetected
and every restart failed with 1091/1060. Check schema and ledger after the
repair too, complete a recorded-drop-without-ledger in place, and refuse the
remaining states with a recovery path.
- Keep deriving a legacy Manager's collection edit/delete from the
organization-local access_all group it came from, rather than dropping the
authority when the repair removes its 0/1/1 copy. Stays revocable with the
group; collection creation remains the independent permission.
- post_org_import: Bitwarden does not require accessImportExport either, it
authorizes on that permission *or* per-collection create/import authority.
- Migrate legacy `access_all` Users losslessly into per-collection
assignments instead of refusing to start the server.
- Keep provisioning of Admin/Owner memberships Owner-only (invite,
confirm, delete); state changes stay as they were.
- Drop the new organization-import gate; the import stays authorized per
target collection, and now requires a confirmed membership.
- Scope `accessReports` to the caller's own collections instead of
handing out every cipher in the organization.
- Let `createNewCollections` read the collection list it needs.
- Reject group changes a caller may not make instead of silently
dropping them.
- Detect partially applied permission-column migrations on MySQL.
- Drop the migration bookkeeping table and remove dead code.
Implements the three remaining Bitwarden Custom-role permissions on top of the
existing set. Each is an independent, persisted flag on the membership, gated on
the Custom role in code (stale flags on other roles grant nothing); Owners/Admins
hold every permission implicitly. They are parsed from and emitted in the
`permissions` object (replacing the previously hard-coded `false`) so the
unmodified web-vault shows and round-trips them.
Server-side enforcement:
- accessEventLogs: the organization event-log endpoints (`GET .../events` and
`GET .../users/<id>/events`) now use a new `AccessEventLogsHeaders` guard
(Admin/Owner or the permission) instead of `AdminHeaders`.
- accessImportExport: `GET .../export` uses a new `AccessImportExportHeaders`
guard, and `post_org_import` gains an explicit permission check.
NOTE: this tightens org import, which previously accepted any confirmed member
(with per-collection gating). It now requires Admin/Owner or the permission,
matching Bitwarden and the web-vault, which only offers org import to permitted
members. Flagged here for maintainer review.
- accessReports has no server endpoint in Vaultwarden (reports are computed
client-side from vault data the member already has), so it is stored and
reported in the permissions object and enforced by the client UI, matching
Bitwarden's own model. No server route gates it.
New migration adds the three columns (down drops them). Unit tests cover
independence, type-gating, parsing and change-detection; a black-box probe over
HTTP confirms the event-log/export/import gating and the permission round-trip
(16/16), and the existing custom-role suite still passes (30/30).
The per-membership `access_all` flag was Vaultwarden's pre-permissions patch for
"this member reaches every collection". It is now fully represented by the role
model: Owners/Admins hold it implicitly, and a Custom member holds it via
`edit_any_collection`. Every authorization query that read
`users_organizations.access_all` now reads `edit_any_collection = true OR
atype <= Admin` instead, which is exactly the set the flag ever identified, so
admin/owner and edit-any access is preserved. The column is dropped via a new
migration (down-migration restores it from the role/permission model).
`groups.access_all` is a separate, still-supported group feature and is untouched.
The legacy Manager role (wire value 3) is folded into Custom: the
`MembershipType::Manager` variant is removed, all `>= Manager` rank checks become
`>= Custom` (identical authorization rank), the `LegacyManager` collection-access
path collapses into the Custom rules, and an incoming wire `type=3` is mapped onto
Custom for backward compatibility. Custom stays `type=4` because that is the only
role modern Bitwarden clients render with custom permissions. Existing type-3
members were already converted to Custom by the earlier migration.
Server-only change; verified against the unmodified web-vault. Unit tests, clippy
and rustfmt pass; migration up/down verified against SQLite.
`groups` is a reserved keyword in MySQL 8, so the unquoted `INNER JOIN groups`
in the second UPDATE of the MySQL variant of
2026-07-16-120000_add_custom_collection_permissions/up.sql fails with
ERROR 1064 (syntax error), aborting the migration and preventing the server
from starting on MySQL/MariaDB. Backtick the table references, matching the
existing 2022-07-27-110000_add_group_support migration. PostgreSQL and SQLite
do not reserve the word and are unchanged.
Before this PR every member created with the Custom role was stored as
Manager (3) and masqueraded as Custom (4) in API responses. With the
masquerade removed, those members would suddenly surface as type 3,
which current clients no longer support and the admin panel cannot
render. Convert them to the now-persisted Custom type; access_all is
preserved and the new manage_* flags stay false, matching the exact
capabilities and appearance these members had before.
The down migration converts Custom members back to Manager so older
server versions (which cannot load type 4) keep working after a
rollback.
* Add archiving
* Update Diesel macros and remove unnecessary SUPPORTED_FEATURE_FLAG
* Add IF EXISTS to down.sql migratinos
* Rename migration folders, separate logic based on PR threads
* Ensure SSO token is only usable on the same client
This commit adds an extra check via cookies to ensure the same browser/client is used to request and provide the SSO token.
Previously it would be able to provide a custom link which attackers could use to steal data.
While an attacker would still need the Master Password to be able to decrypt or execute specific actions, they were able to fetch encrypted data.
Solved with some help of Claude Code.
Signed-off-by: BlackDex <black.dex@gmail.com>
* Check email-verified on SSO login/create
This commit prevents possible account takeover via SSO which doesn't check/validate or provide validated status of the email.
It was checked at other locations, but was skipped here.
Signed-off-by: BlackDex <black.dex@gmail.com>
* Prevent data disclosure via SSO endpoints
This commit prevents some data disclosure and user enumeration by only returning the fake SSO identifier.
Since we do not check the identifier anywhere useful, returning the fake one is just fine.
During an invite to an org, that link contains the correct UUID and will be used for the master password requirements.
For anything else, server admins should set the `SSO_MASTER_PASSWORD_POLICY` env variable.
Signed-off-by: BlackDex <black.dex@gmail.com>
* Adjust admin layout to fix issues when SSO is enabled
Signed-off-by: BlackDex <black.dex@gmail.com>
---------
Signed-off-by: BlackDex <black.dex@gmail.com>
- Updated all the crates except for Diesel.
Diesel is pinned at v2.3.3 since newer versions break MySQL/MariaDB.
- Updated all the GHA workflows
- Fixed an issue with a migration breaking on an empty MySQL/MariaDB database.
Signed-off-by: BlackDex <black.dex@gmail.com>
* Add SSO functionality using OpenID Connect
Co-authored-by: Pablo Ovelleiro Corral <mail@pablo.tools>
Co-authored-by: Stuart Heap <sheap13@gmail.com>
Co-authored-by: Alex Moore <skiepp@my-dockerfarm.cloud>
Co-authored-by: Brian Munro <brian.alexander.munro@gmail.com>
Co-authored-by: Jacques B. <timshel@github.com>
* Improvements and error handling
* Stop rolling device token
* Add playwright tests
* Activate PKCE by default
* Ensure result order when searching for sso_user
* add SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION
* Toggle SSO button in scss
* Base64 encode state before sending it to providers
* Prevent disabled User from SSO login
* Review fixes
* Remove unused UserOrganization.invited_by_email
* Split SsoUser::find_by_identifier_or_email
* api::Accounts::verify_password add the policy even if it's ignored
* Disable signups if SSO_ONLY is activated
* Add verifiedDate to organizations::get_org_domain_sso_details
* Review fixes
* Remove OrganizationId guard from get_master_password_policy
* Add wrapper type OIDCCode OIDCState OIDCIdentifier
* Membership::confirm_user_invitations fix and tests
* Allow set-password only if account is unitialized
* Review fixes
* Prevent accepting another user invitation
* Log password change event on SSO account creation
* Unify master password policy resolution
* Upgrade openidconnect to 4.0.0
* Revert "Remove unused UserOrganization.invited_by_email"
This reverts commit 548e19995e141314af98a10d170ea7371f02fab4.
* Process org enrollment in accounts::post_set_password
* Improve tests
* Pass the claim invited_by_email in case it was not in db
* Add Slack configuration hints
* Fix playwright tests
* Skip broken tests
* Add sso identifier in admin user panel
* Remove duplicate expiration check, add a log
* Augment mobile refresh_token validity
* Rauthy configuration hints
* Fix playwright tests
* Playwright upgrade and conf improvement
* Playwright tests improvements
* 2FA email and device creation change
* Fix and improve Playwright tests
* Minor improvements
* Fix enforceOnLogin org policies
* Run playwright sso tests against correct db
* PKCE should now work with Zitadel
* Playwright upgrade maildev to use MailBuffer.expect
* Upgrades playwright tests deps
* Check email_verified in id_token and user_info
* Add sso verified endpoint for v2025.6.0
* Fix playwright tests
* Create a separate sso_client
* Upgrade openidconnect to 4.0.1
* Server settings for login fields toggle
* Use only css for login fields
* Fix playwright test
* Review fix
* More review fix
* Perform same checks when setting kdf
---------
Co-authored-by: Felix Eckhofer <felix@eckhofer.com>
Co-authored-by: Pablo Ovelleiro Corral <mail@pablo.tools>
Co-authored-by: Stuart Heap <sheap13@gmail.com>
Co-authored-by: Alex Moore <skiepp@my-dockerfarm.cloud>
Co-authored-by: Brian Munro <brian.alexander.munro@gmail.com>
Co-authored-by: Jacques B. <timshel@github.com>
Co-authored-by: Timshel <timshel@480s>
* Add manage role for collections and groups
This commit will add the manage role/column to collections and groups.
We need this to allow users part of a collection either directly or via groups to be able to delete ciphers.
Without this, they are only able to either edit or view them when using new clients, since these check the manage role.
Still trying to keep it compatible with previous versions and able to revert to an older Vaultwarden version and the `access_all` feature of the older installations.
In a future version we should really check and fix these rights and create some kind of migration step to also remove the `access_all` feature and convert that to a `manage` option.
But this commit at least creates the base for this already.
This should resolve#5367
Signed-off-by: BlackDex <black.dex@gmail.com>
* Fix an issue with access_all
If owners or admins do not have the `access_all` flag set, in case they do not want to see all collection on the password manager view, they didn't see any collections at all anymore.
This should fix that they are still able to view all the collections and have access to it.
Signed-off-by: BlackDex <black.dex@gmail.com>
---------
Signed-off-by: BlackDex <black.dex@gmail.com>
* Add initial working Duo Universal Prompt support.
* Add db schema and models for Duo 2FA state storage
* store duo states in the database and validate during authentication
* cleanup & comments
* bump state/nonce length
* replace stray use of TimeDelta
* more cleanup
* bind Duo oauth flow to device id, drop redundant device type handling
* drop redundant alphanum string generation code
* error handling cleanup
* directly use JWT_VALIDITY_SECS constant instead of copying it to DuoClient instances
* remove redundant explicit returns, rustfmt
* rearrange constants, update comments, error message
* override charset on duo state column to ascii for mysql
* Reduce twofactor_duo_ctx state/nonce column size in postgres and maria
* Add fixes suggested by clippy
* rustfmt
* Update to use the make_http_request
* Don't handle OrganizationDuo
* move Duo API endpoint fmt strings out of macros and into format! calls
* Add missing indentation
Co-authored-by: Daniel García <dani-garcia@users.noreply.github.com>
* remove redundant expiry check when purging Duo contexts
---------
Co-authored-by: BlackDex <black.dex@gmail.com>
Co-authored-by: Daniel García <dani-garcia@users.noreply.github.com>
MariaDB/MySQL doesn't like the normal `"` quotes around the column name.
This needs to be a backtick **`**.
This PR changes the migration script to fix this issue.
Fixes#3993
While working on the fix I realised the location where the `external_id`
is stored was wrong. It was stored in the `users` table, but it actually
should have been stored in the `users_organizations` table.
This will move the column to the right table. It will not move the
values of the `external_id` column, because if there are more
organizations, there is no way to really know which organization it is
linked to. Setups using the Directory Connector can clear the sync
cache, and sync again, that will store all the `external_id` values at
the right location.
Also changed the function to revoke,restore an org-user and set_external_id to return a boolean.
It will state if the value has been changed or not, and if not, we can
prevent a `save` call to the database.
The `users` table is not changed to remove the `external_id` column, thi
to prevent issue when users want to revert back to an earlier version
for some reason. We can do this after a few minor release i think.
Fixes#3777
It looks like either something changed in the latest v2023.8.x versions,
or when using Biometrics to login, but the MasterPasswordHash is an
optional value during the Approve action.
This PR makes the MasterPasswordHash an optional value which resolves
this issues. Bitwarden works the same way.
I also changed the EncKey to an Option in the database since empty
strings as a default value is not nice in databases, better to use
`null` in these cases.
Fixes#3819
Merging a PR from @Kurnihil into the already rebased branch.
Made some small changes to make it work with newer changes.
Some finetuning is probably still needed.
Co-authored-by: Daniele Andrei <daniele.andrei@geo-satis.com>
Co-authored-by: Kurnihil
This is a WIP for adding organization token login support.
It has basic token login and verification support, but that's about it.
This branch is a refresh of the previous version, and will contain code
from a PR based upon my previous branch.
This PR adds event/audit logging support for organizations.
By default this feature is disabled, since it does log a lot and adds
extra database transactions.
All events are touched except a few, since we do not support those
features (yet), like SSO for example.
This feature is tested with multiple clients and all database types.
Fixes#229
This PR adds event/audit logging support for organizations.
By default this feature is disabled, since it does log a lot and adds
extra database transactions.
All events are touched except a few, since we do not support those
features (yet), like SSO for example.
This feature is tested with multiple clients and all database types.
Fixes#229
This PR adds event/audit logging support for organizations.
By default this feature is disabled, since it does log a lot and adds
extra database transactions.
All events are touched except a few, since we do not support those
features (yet), like SSO for example.
This feature is tested with multiple clients and all database types.
Fixes#229
- Updated jsonwebtoken to latest version
- Trim `username` received from the login form ( Fixes#2348 )
- Make uuid and user_uuid a combined primary key for the devices table ( Fixes#2295 )
- Updated crates including regex which contains a CVE ( https://blog.rust-lang.org/2022/03/08/cve-2022-24713.html )
An incomplete 2FA login is one where the correct master password was provided,
but the 2FA token or action required to complete the login was not provided
within the configured time limit. This potentially indicates that the user's
master password has been compromised, but the login was blocked by 2FA.
Be aware that the 2FA step can usually still be completed after the email
notification has already been sent out, which could be confusing. Therefore,
the incomplete 2FA time limit should be long enough that this situation would
be unlikely. This feature can also be disabled entirely if desired.
- Changed the date of the migration folders to be from this date.
- Removed a lot is_email_domain_allowed checks.
This check only needs to be done during the invite it self, else
everything else will fail even if a user has an account created via the
/admin interface which bypasses that specific check! Also, the check was
at the wrong place anyway's, since it would only not send out an e-mail,
but would still have allowed an not allowed domain to be used when
e-mail would have been disabled. While that check always works, even if
sending e-mails is disasbled.
- Added an extra allowed route during password/key-rotation change which
updates/checks the public-key afterwards.
- A small change with some `Some` and `None` orders.
- Change the new invite object to only generate the UTC time once, since
it could be possible that there will be a second difference, and we only
need to call it just once.
by black.dex@gmail.com
Signed-off-by: thelittlefireman <thelittlefireman@users.noreply.github.com>
- The new web-vault v2.21.0+ has support for Master Password Reset. For
this to work it generates a public/private key-pair which needs to be
stored in the database. Currently the Master Password Reset is not
fixed, but there are endpoints which are needed even if we do not
support this feature (yet). This PR fixes those endpoints, and stores
the keys already in the database.
- There was an issue when you want to do a key-rotate when you change
your password, it also called an Emergency Access endpoint, which we do
not yet support. Because this endpoint failed to reply correctly
produced some errors, and also prevent the user from being forced to
logout. This resolves#1826 by adding at least that endpoint.
Because of that extra endpoint check to Emergency Access is done using
an old user stamp, i also modified the stamp exception to allow multiple
rocket routes to be called, and added an expiration timestamp to it.
During these tests i stumbled upon an issue that after my key-change was
done, it triggered the websockets to try and reload my ciphers, because
they were updated. This shouldn't happen when rotating they keys, since
all access should be invalided. Now there will be no websocket
notification for this, which also prevents error toasts.
- Increased Send Size limit to 500MB (with a litle overhead)
As a side note, i tested these changes on both v2.20.4 and v2.21.1 web-vault versions, all keeps working.
tom27052006
Timshel
Matt Aaron
Mathijs van Veluw
Timshel
Stefan Melmuk
Daniel
0x0fbc
gzfrozen
Daniel García
Bernd Schoolmann
Folke Ashberg
GeekCornerGH
Helmut K. C. Tessarek
sirux88
MFijak
Jeremy Lin
thelittlefireman