Completes the trusted device flow for the case it was missing: a member who
unlocks with a trusted device, has no other device of their own left to ask,
and therefore has no way back into their vault. They can now turn to the
administrators of their organization, who hand them their own user key
encrypted for the key pair of the asking device.
New `atype` on auth_requests, mirroring bitwarden/server's AuthRequestType.
It decides who may answer a request and how long it stays open: 15 minutes
between the user's own devices, a week for an administrator, and half a day
for their answer once given. The purge job applies that per type instead of
dropping everything after 15 minutes, and both the answer and the anonymous
lookup now refuse an expired request, which they did not before.
POST /auth-requests/admin-request ask, one request per org
GET /organizations/<id>/auth-requests what is waiting for an answer
POST /organizations/<id>/auth-requests/<id> approve or deny one
POST /organizations/<id>/auth-requests/deny deny several
POST /organizations/<id>/auth-requests answer several
Asking requires authentication, so the anonymous `POST /auth-requests` now
refuses the type. Answering goes through the organization the request was
addressed to and needs admin rights there; the asking user cannot answer
their own request through `PUT /auth-requests/<id>`, which would make the
whole detour pointless. A denial is saved but not announced, so a request
that did not come from the member does not learn that it was seen. The
administrator's view leaves out the access code, which is the asking
device's proof and none of their business.
The administrators are mailed when a request arrives, the member when one of
their devices was let in, so an approval nobody asked for does not pass
unnoticed.
Two fixes without which none of this is reachable from a client:
- `UserDecryptionOptions.TrustedDeviceOption` reported `HasAdminApproval`
and `HasManageResetPasswordPermission` as a flat false. The clients
decide on `hasAdminApproval || hasMasterPassword` whether a login is a
returning user or a brand new one, so a member without a master password
was shown the screen for creating an account, on every device but the
one they first trusted. Both are now derived from the account recovery
enrollment and the role.
- `PUT /organizations/<id>/users/<id>/reset-password-enrollment` demanded a
master password whenever a key was supplied. An account that unlocks
with a trusted device has none, and the clients send nothing but the key
when they enroll during registration, so enrolling was impossible for
exactly the accounts that need it most. Upstream carves out the same
exception, keyed on the organization's SSO configuration rather than on
a server-wide setting as here. Enrolling now also accepts a pending
invitation, as upstream does, so a just-provisioned member does not stay
invited forever with nobody able to confirm them.
Since the feature `Login with device` some actions done via the
web-vault need to be verified via an OTP instead of providing the MasterPassword.
This only happens if a user used the `Login with device` on a device
which uses either Biometrics login or PIN. These actions prevent the
athorizing device to send the MasterPasswordHash. When this happens, the
web-vault requests an OTP to be filled-in and this OTP is send to the
users email address which is the same as the email address to login.
The only way to bypass this is by logging in with the your password, in
those cases a password is requested instead of an OTP.
In case SMTP is not enabled, it will show an error message telling to
user to login using there password.
Fixes#4042
* Update twofactor_email.hbs subject line to avoid triggering gmail content filter
Previous subject line was triggering Google's spam blocker, breaking the 2FA setup process if a gmail SMTP server is configured. The new subject line does not (currently) run afoul of Google's filter.
* Update twofactor_email.html.hbs subject line to avoid triggering gmail content filter
Previous subject line was triggering Google's spam blocker, breaking the 2FA setup process if a gmail SMTP server is configured. The new subject line does not (currently) run afoul of Google's filter.
* Update twofactor_email.hbs
Changed "Confirmation" to "Verification" for the sake of internal consistency
* Update twofactor_email.hbs
* Update twofactor_email.html.hbs
- Updated branding for admin and emails
- Updated crates and some deprications
- Removed newline-converter because this is built-in into lettre
- Updated email templates to use a shared header and footer template
- Also trigger SMTP SSL When TLS is selected without SSL
Resolves#1641
tom27052006
Mathijs van Veluw
aureateflux
Daniel García
François
vpl