You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Default password policy for new realms in production mode?
#53774
Keycloak doesn't set a password policy when it creates a realm. This includes the master realm, which Keycloak creates automatically on first start (ApplianceBootstrap.createMasterRealm()), and realms created through the Admin Console or Admin REST API. Unless an administrator configures a policy, any password is accepted, including very short ones. For master, which holds the administrator accounts, that's an easy-to-miss gap in production deployments.
I'd like to propose a secure-by-default baseline and would like to hear opinions before opening an enhancement request, because a few things need to be decided first.
The idea
Production mode (start): newly created realms get a default password policy. An explicitly configured policy (import, Admin REST API, Admin Console) is never overridden.
Development mode (start-dev): nothing is enforced, as today.
Startup check: a realm created in dev mode keeps its configuration when the same database is later used in production. So in production mode, Keycloak should also check existing realms at startup and at least log a warning when no password policy is configured.
Possible approaches
Default for every new realm.
Realm creation sets a default policy when not running in dev mode.
The default is configurable through a new option, e.g. default-password-policy, in the existing policy syntax, with a value such as none to opt out.
Only for master (less restrictive). It's the only realm Keycloak creates on its own.
createMasterRealm() sets the policy in production mode.
It's configurable through a new bootstrap option next to bootstrap-admin-username / bootstrap-admin-password, e.g. bootstrap-password-policy, which only takes effect when master is created.
Warning only (smallest step).
Nothing is changed or enforced; in production mode, Keycloak just logs a warning at startup for realms without a password policy.
It can be combined with 1 or 2.
Open questions
Scope: all new realms (1), only master (2), or only a warning (3)?
Bootstrap admin: the realm's password policy is validated whenever a password credential is created (PasswordCredentialProvider → PasswordPolicyManagerProvider.validate()). The bootstrap admin is created right after master, so a weak --bootstrap-admin-password (e.g. admin) would be rejected in production mode. Options:
fail fast with a clear error, which arguably is the point;
apply the policy only after the bootstrap admin exists;
exempt the temporary bootstrap admin, which has to be replaced anyway.
Imports: should a realm imported without a passwordPolicy get the default, or does an imported realm count as configured?
Default values: which concrete rules should the default contain? I'd suggest following current recommendations (e.g. NIST SP 800-63B) and keeping it minimal, e.g. a minimum length plus notUsername().
Configuration: a dedicated option (default-password-policy), a bootstrap-only option for master, or both?
Startup check: only master or all realms? And is a log warning enough, or should it also show up in the Admin Console?
Existing realms would not be changed in any of these approaches; this only concerns realm creation and the startup warning.
Looking forward to your thoughts!
Generative AI disclosure
Claude Code was used to check the current behavior in the code base (realm and master realm creation, password policy validation, bootstrap options, dev mode detection) and to draft this discussion. I reviewed the content before posting.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Keycloak doesn't set a password policy when it creates a realm. This includes the
masterrealm, which Keycloak creates automatically on first start (ApplianceBootstrap.createMasterRealm()), and realms created through the Admin Console or Admin REST API. Unless an administrator configures a policy, any password is accepted, including very short ones. Formaster, which holds the administrator accounts, that's an easy-to-miss gap in production deployments.I'd like to propose a secure-by-default baseline and would like to hear opinions before opening an enhancement request, because a few things need to be decided first.
The idea
start): newly created realms get a default password policy. An explicitly configured policy (import, Admin REST API, Admin Console) is never overridden.start-dev): nothing is enforced, as today.Possible approaches
default-password-policy, in the existing policy syntax, with a value such asnoneto opt out.master(less restrictive). It's the only realm Keycloak creates on its own.createMasterRealm()sets the policy in production mode.bootstrap-admin-username/bootstrap-admin-password, e.g.bootstrap-password-policy, which only takes effect whenmasteris created.Open questions
master(2), or only a warning (3)?PasswordCredentialProvider→PasswordPolicyManagerProvider.validate()). The bootstrap admin is created right aftermaster, so a weak--bootstrap-admin-password(e.g.admin) would be rejected in production mode. Options:passwordPolicyget the default, or does an imported realm count as configured?notUsername().default-password-policy), a bootstrap-only option formaster, or both?masteror all realms? And is a log warning enough, or should it also show up in the Admin Console?Existing realms would not be changed in any of these approaches; this only concerns realm creation and the startup warning.
Looking forward to your thoughts!
Generative AI disclosure
Claude Code was used to check the current behavior in the code base (realm and
masterrealm creation, password policy validation, bootstrap options, dev mode detection) and to draft this discussion. I reviewed the content before posting.All reactions