[WFLY-20765] [CVE-2025-23368] Documentation for the new WildFly Elytron Brute Force Protection implementation. by darranl · Pull Request #19582 · wildfly/wildfly

darranl · 2026-01-30T12:45:01Z

Requires: wildfly/wildfly-core#6634

https://issues.redhat.com/browse/WFLY-20765

…ection utility. This is being enabled by default but can be customised by administrators.

Also add mention of the caching, distributed, and failover realms to the documentation.

rhusar · 2026-02-02T08:25:30Z

Perhaps @skyllarr can review?

OndrejKotek · 2026-02-02T12:16:16Z

docs/src/main/asciidoc/_elytron/components/Brute_Force_Detection.adoc

+Repeated attempts after this point will restart the period the identity is locked
+for.
+
+NOTE: For the realms that delegate to other realms such as the `caching-realm`, the


I suggest to add also a note about the aggregate-realm:

The brute force protection is not applied directly to the aggregate-realm as this maintains a 1:1 mapping to an authentication-realm which will have it's own brute force protection applied.

… for failed authentication tracking.

bstansberry · 2026-02-07T18:10:36Z

docs/src/main/asciidoc/_elytron/components/Brute_Force_Detection.adoc

+before an identity should be temporarily unavailable. [Default: 10]
+* lockout-interval - The time in minutes the identity should be unavailable for
+once the maximum number of attempts is exceeded. [Default: 15]
+* session-timeout - After the most recent failed authentication, how long in


I'm definitely not suggesting changing this here, but when it comes time for the proper management API I suggest reconsidering the term 'session' in the user-visible API. It's an overloaded term and what it represents in this context doesn't really align with what people might guess it means.

Maybe 'tracking-timeout' or 'tracker-timeout'?

bstansberry · 2026-02-07T18:15:22Z

docs/src/main/asciidoc/_elytron/components/Brute_Force_Detection.adoc

+* lockout-interval - The time in minutes the identity should be unavailable for
+once the maximum number of attempts is exceeded. [Default: 15]
+* session-timeout - After the most recent failed authentication, how long in
+minutes to keep the session tracking the identity alive. [Default: 30]


This shouldn't block this but another suggestion for the future is to add a sentence describing what happens after the timeout.

Maybe

"how long in minutes to keep tracking failed authentication attempts for the identity. If tracking for an identity has ended and a new failed authentication attempt occurs it will again be tracked, but the tracking will treat the attempt as if that was the first failed attempt."

bstansberry · 2026-02-07T18:16:25Z

docs/src/main/asciidoc/_elytron/components/Brute_Force_Detection.adoc

+once the maximum number of attempts is exceeded. [Default: 15]
+* session-timeout - After the most recent failed authentication, how long in
+minutes to keep the session tracking the identity alive. [Default: 30]
+* max-cached-sessions - The maximum number of sessions to cache for tracking failed


Similar point about 'session'. Maybe 'identities' here?

Again, not now; this is for the future.

bstansberry

I think the changes noted below should happen for WildFly 40 but I'm not asking that they block any work related to this for 39.0.1. If it makes things easier I'm fine with this being merged as is with a follow-up PR to address these.

docs/src/main/asciidoc/_elytron/components/Brute_Force_Detection.adoc

bstansberry · 2026-02-07T18:29:35Z

docs/src/main/asciidoc/_elytron/components/Brute_Force_Detection.adoc

+ignored.
+
+Where an event is received indicating a failed authentication attempt this utility
+will first check if a session has been established for the specific identity to


Note that I made comments about 'session' above with respect to the management API. Here I think the term is fine as this is a complex description of behavior and a reader can reasonably be expected to understand what is meant from the overall context. For the management API attribute users are likely to have little or no context.

bstansberry

I think the changes noted below should happen for WildFly 40 but I'm not asking that they block any work related to this for 39.0.1. If it makes things easier I'm fine with this being merged as is with a follow-up PR to address these.

To avoid confusion I've changed my review to 'Approve'. My comment ^^^ is way too small in the GH UI compared to the all the detail comments and the red UI widget next to my name.

bstansberry · 2026-02-11T23:00:13Z

I just killed a bunch of ci.wildfly.org jobs on this as those tests are irrelevant to a docs-only change.

I expect they will get requeued, but that's ok; they will then be at the end of the queue. Currently we have a massive queue since the CI server was down for a few days.

rhusar

LGTM

Core upgrade is in, approvals are in, CI not needed, and follow-up Jira created and I really want this to get on par with 39.x and drop it off my items.

rhusar · 2026-02-14T10:58:43Z

Thanks @darranl @OndrejKotek @skyllarr @bstansberry !

rhusar · 2026-02-14T10:59:26Z

I have created a follow-up Jira with un-address comments as: https://issues.redhat.com/browse/WFLY-21474 - update as you see fit.

darranl added 3 commits January 30, 2026 12:40

[WFLY-20765] Add documentation for the brute force authentication det…

e403e50

…ection utility. This is being enabled by default but can be customised by administrators.

[WFLY-20765] Minor documentation update.

9b6b912

[WFLY-20765] Update the out of the box defaults.

61b5fa4

Also add mention of the caching, distributed, and failover realms to the documentation.

darranl mentioned this pull request Jan 30, 2026

[39.x] [WFLY-20765] [CVE-2025-23368] Documentation for the new WildFly Elytron Brute Force Protection implementation. #19583

Merged

rhusar requested a review from skyllarr February 2, 2026 08:25

OndrejKotek reviewed Feb 2, 2026

View reviewed changes

skyllarr approved these changes Feb 3, 2026

View reviewed changes

[WFLY-20765] Add information to the documentation about the LRU cache…

d0a5475

… for failed authentication tracking.

bstansberry reviewed Feb 7, 2026

View reviewed changes

bstansberry requested changes Feb 7, 2026

View reviewed changes

bstansberry reviewed Feb 7, 2026

View reviewed changes

bstansberry approved these changes Feb 7, 2026

View reviewed changes

darranl added 2 commits February 7, 2026 20:17

[WFLY-20765] Apply some documentation fixes post code review.

836ced6

[WFLY-20765] A couple of additional corrections.

09e80a8

darranl removed the missing-reqs Features missing any https://docs.wildfly.org/wildfly-proposals/FEATURE_PROCESS.html#requirements label Feb 10, 2026

bstansberry removed the core-upgrade-needed PR requires a wildfly-core change to be merged and integrated first label Feb 13, 2026

rhusar approved these changes Feb 14, 2026

View reviewed changes

rhusar merged commit 34e589a into wildfly:main Feb 14, 2026
13 of 19 checks passed

Uh oh!

Conversation

darranl commented Jan 30, 2026

Uh oh!

rhusar commented Feb 2, 2026

Uh oh!

OndrejKotek Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

bstansberry Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

bstansberry Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

bstansberry Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

bstansberry left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bstansberry Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

bstansberry left a comment

Choose a reason for hiding this comment

Uh oh!

bstansberry commented Feb 11, 2026

Uh oh!

rhusar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rhusar commented Feb 14, 2026

Uh oh!

rhusar commented Feb 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants