System Settings — Versola Docs
VersolaVersola/docs
Pre-1.00.7.1versola.kzGitHub
RUEN

System Settings

Reference for the System Settings screen of the admin console — the global password policy and the identity provider logo shown on login pages

System Settings holds the two settings that apply to the whole deployment instead of one tenant: the password policy and the identity provider logo. Passwords belong to the user, not to a tenant, so the policy that governs them is global too. The screen is not scoped to the tenant selector in the sidebar.

Before you start

NeedPermission
See the screensecurity:read
Change the settings (the Edit button)security:manage

The settings live in Central and reach auth through its configuration sync, so a saved change applies after the next refresh. edge does not use them.

System Settings, read-only view with the defaults
System Settings page in read-only mode: the Password Policy card with the regular expression, a history size of 2 and one different password required, and the Branding card with an empty Identity provider logo.

Fields

Edit opens the form below. Save writes all four values at once; Cancel discards them.

FieldControlsDefaultValidation
Password RegexThe pattern every password a user types must match in full.^(?=.*[A-Z])(?=.*[a-z])(?=.*\d).{8,}$ (at least 8 characters with an uppercase letter, a lowercase letter and a digit)Required. The console refuses a pattern that is not a valid regular expression.
Password History SizeHow many previous passwords Versola keeps per user, counting the current one.2A whole number, 0 or more.
Different Passwords RequiredHow many of the most recent kept passwords a new password must differ from.1 (the new password must differ from the current one)A whole number, 0 or more.
Identity Provider LogoA logo shown on the login screens and used as the favicon of the login pages.empty (shown as — in the read-only view)Empty, or an absolute http or https URL with a host. Whitespace is trimmed; an empty value clears the logo.
System Settings, edit form
System Settings edit form with the Password Regex, Password History Size, Different Passwords Required and Identity Provider Logo fields and the Save and Cancel buttons.

Central rejects a logo that is not an absolute http(s) URL with the message Identity provider logo must be an absolute HTTP(S) URL. Central does not validate the regular expression; the check in the console is the only one. The browser form checks it as a JavaScript pattern, while auth evaluates it in Java, so keep to constructs both support (character classes, quantifiers, lookaheads).

Only passwords that are kept count. Different Passwords Required larger than Password History Size adds nothing, because auth has no older passwords to compare with.

How the policy is applied

The regular expression is checked by auth on the server whenever a password is typed into a sign-in page: the password step, the combined login-and-password step and the Set New Password step. A submission that does not match is rejected with 400 before the password is checked against the stored one.

Warning: The pattern also applies to sign-in, not only to new passwords. After you make it stricter, a user whose existing password no longer matches cannot submit it on the login page. Change the pattern together with a plan for those users, for example a password reset.

If the pattern is not a valid Java regular expression, auth treats every password as matching. The console blocks invalid patterns, so this happens only if the setting was written to Central through the API.

The history rules apply when a user sets a permanent password. A new password is refused when it equals one of the last Different Passwords Required passwords. After it is stored, only the newest Password History Size passwords stay on record. If a user signs in with an old password that is still on record, auth does not accept it and shows when the password was changed.

First sign-in and password reset

Temporary passwords come from two places: the bootstrap password of the first administrator and the Reset Password button on the user card (see User). Both follow the same path:

  1. The user signs in with the temporary password. auth accepts it as the password factor, finishes the remaining factors (for example the OTP code) and then shows Set New Password. An expired temporary password is refused.
  2. The new password must match Password Regex and pass the history rules above. A password that repeats a recent one is refused with a reuse message, and the failed attempt counts against the password submission limits of the tenant (see Challenges & Security).
  3. Saving the new password stores it as permanent, deletes the temporary one and keeps the temporary password out of the history.

Reset generates a temporary password of 16 characters that satisfies Password Regex, trying up to 20 times. If your pattern is so strict that random passwords rarely match it, the reset fails instead of issuing a weak password. A reset without a lifetime expires after 12 hours. In a production environment the password is delivered to the user by email or SMS with the password template from Challenges & Security; showing it in the console is allowed outside production only.

The internal POST /users/password/set call of auth applies the history rules but does not run Password Regex.

Next steps