add SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION

pull/3899/head
Timshel 3 months ago
parent 95387be709
commit dbf9d18be6

@ -457,6 +457,8 @@
# SSO_ONLY=false
## On SSO Signup if a user with a matching email already exists make the association
# SSO_SIGNUPS_MATCH_EMAIL=true
## Allow unknown email verification status. Allowing this with `SSO_SIGNUPS_MATCH_EMAIL=true` open potential account takeover.
# SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
## Base URL of the OIDC server (auto-discovery is used)
## - Should not include the `/.well-known/openid-configuration` part and no trailing `/`
## - ${SSO_AUTHORITY}/.well-known/openid-configuration should return a json document: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse

@ -15,6 +15,7 @@ The following configurations are available
- `SSO_ENABLED` : Activate the SSO
- `SSO_ONLY` : disable email+Master password authentication
- `SSO_SIGNUPS_MATCH_EMAIL`: On SSO Signup if a user with a matching email already exists make the association (default `true`)
- `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION`: Allow unknown email verification status (default `false`). Allowing this with `SSO_SIGNUPS_MATCH_EMAIL` open potential account takeover.
- `SSO_AUTHORITY` : the OpenID Connect Discovery endpoint of your SSO
- Should not include the `/.well-known/openid-configuration` part and no trailing `/`
- $SSO_AUTHORITY/.well-known/openid-configuration should return the a json document: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse
@ -57,6 +58,16 @@ To delete the association (this has no impact on the `Vaultwarden` user):
TRUNCATE TABLE sso_users;
```
### On `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION`
If your provider does not send the verification status of emails (`email_verified` [claim](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)) you will need to activate this setting.
If set with `SSO_SIGNUPS_MATCH_EMAIL=true` (the default), then a user can associate with an existing, non-SSO account, even if they do not control the email address.
This allow a user to gain access to sensitive information but the master password is still required to read the passwords.
As such when using `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION` it is recommended to disable `SSO_SIGNUPS_MATCH_EMAIL`.
If you need to associate non sso users try to keep both settings activated for the shortest time possible.
## Client Cache
By default the client cache is disabled since it can cause issues with the signing keys.

@ -193,8 +193,13 @@ async fn _sso_login(data: ConnectData, user_uuid: &mut Option<String>, conn: &mu
err!("Email domain not allowed");
}
if !user_infos.email_verified.unwrap_or(true) {
err!("Email needs to be verified before you can use VaultWarden");
match user_infos.email_verified {
None if !CONFIG.sso_allow_unknown_email_verification() => err!(
"Your provider does not send email verification status.\n\
You will need to change the server configuration (check `SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION`) to log in."
),
Some(false) => err!("You need to verify your email with your provider before you can log in"),
_ => (),
}
let mut user = User::new(user_infos.email, user_infos.user_name);

@ -653,6 +653,8 @@ make_config! {
sso_only: bool, true, def, false;
/// Allow email association |> Associate existing non-sso user based on email
sso_signups_match_email: bool, true, def, true;
/// Allow unknown email verification status |> Allowing this with `SSO_SIGNUPS_MATCH_EMAIL=true` open potential account takeover.
sso_allow_unknown_email_verification: bool, false, def, false;
/// Client ID
sso_client_id: String, false, def, String::new();
/// Client Key

Loading…
Cancel
Save