-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for MFA with Duo's Universal Prompt #4637
base: main
Are you sure you want to change the base?
Conversation
Thanks @0x0fbc. On first glance it looks like you need to rebase already, but besides that it looks ok. No deep checking done. The only thing that worries me is the collation for the Isn't there a way to not have this as a key? Or less larger in size. |
The column size can be scaled back, absolutely. I set the state and nonce column sizes in postgres and maria so that someone could change the constant dictating the state length to the largest Duo would accept (1024 characters) without having to mess with the database schema. That constant is set to 64 right now, so the large size is only useful to support this specific future proofing case. If you've seen issues with collations/charsets in the past I'd rather not tempt fate, so I'm in favor of just cutting the size down and dropping the overridden character set/collation for the columns in MariaDB. I'll take care of that and rebase when I get a chance later today. |
965221e
to
8c02577
Compare
@BlackDex, I reduced the column sizes and removed the collation override I had for MariaDB. I also added the changes suggested by Clippy, did another rustfmt, synced my fork, and rebased. |
8c02577
to
f02c892
Compare
This is an upstream client bug and unrelated to vaultwarden. Both snap and appimage builds have (different) issues with the url handlers at the moment. If I recall correctly from debugging, on AppImage the desktop file does not get created anymore. It needs to be created manually. |
f02c892
to
8389bcd
Compare
Overview
This adds support for MFA using Duo's "Universal Prompt".
On March 30th, 2024, the Duo MFA integration that Vaultwarden uses, the 'Traditional Prompt' was end-of-lifed. While Duo's API continues to allow the traditional prompt to be used in some cases, it is entirely unsupported, and it will eventually stop working. Some Vaultwarden users have already begun reporting that their Duo API keys are no longer functional in Vaultwarden. Bitwarden introduced Universal Prompt support in release 2024.2.3 on March 5th.
Duo's Universal Prompt uses the OIDC Authorization Code flow. This flow requires us to pack information about the authentication we want to be prompted for MFA into an authorization request (a JWT signed with a secret key provided by Duo) and send the user to their service, where MFA is performed. The user is then returned to our service with a code that we use to call Duo's API and obtain the result of the MFA. Once we validate the information passed back by the user's client and returned by Duo's service, we can log the user in.
Detailed documentation is located at https://duo.com/docs/oauthapi
The web vault handles receiving the redirection from Duo. It has a 'connector' page responsible for communicating the authorization code back to the user's true client so it can be provided in a call to Vaultwarden's API.
Major additions/changes
Specific Review Items
Beyond what you'd normally check, I'd like to highlight a few decisions I made that you should probably consider in your review.
device_identifier
reported by the client, and hashed to produce the OIDC nonce sent to Duo in the authorization request. Then, thedevice_identifier
reported by the user's client when providing the authorization code is hashed with the saved nonce, and the resulting hash is compared to the OIDC nonce Duo reports when we call their API for the MFA result.get_duo_keys_email
function, which fetches the Duo keys from the database/config for a given user, I set its visibility topub(crate)
and re-used it.Testing
Tested on the following clients; everything is working well:
The only major client issue I found was with the unpackaged AppImage Linux desktop client. When authenticating users on desktop clients, the connector in the web vault opens a
bitwarden://
link, which my system refused to use the AppImage to open. It looks like the AppImage client either doesn't or can't register itself as thex-scheme-handler
forbitwarden
, preventing the redirect connector from handing off to the client. It worked fine with the Flatpak packaged Bitwarden client, so I'm chalking it up to my not configuring the AppImage client correctly.There is also a known issue upstream in the web vault where the redirect connector shows 'successful authentication', does not automatically close, and the JS 'close' button does not work. See bitwarden/clients#8554
I also tested this while running PostgreSQL and MariaDB using the versions packaged in Debian 12; no issues.