3.102. <AuthBy FAILUREPOLICY>

<AuthBy FAILUREPOLICY> allows you to act on repeated failures. The current implementation monitors usernames and only considers those failures that indicate bad password as the failure reason.
Two policers are currently implemented. One counts consecutive failures and the other counts cumulative failures. Both policers implement separate failure counters, policy violation time and windowing. Windowing is optional and allows counters to be reset after the configured time window has passed. Counters are not incremented when a policy violation is active. If a violation is not active when a failure occurs, both consecutive counter and cumulative counter are currently incremented.
Windowing is typically used with the cumulative policer. For example, when cumulative failure threshold is set to 200 and windows size to 12 hours, the counter is reset every 12 hours. Window time is based on Unix timestamp and is not relative to Radiator process startup.
Counters are kept in Radiator process memory. If multiple Radiator instances need to share the counters or they need to persist across process restarts and reloads, see Section 3.103. <AuthBy SQLFAILUREPOLICY>
Important
See goodies/failurepolicy.cfg for an example configuration. Currently a hook is needed to monitor failures and maintain counter history.
<AuthBy FAILUREPOLICY> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.102.1. DefaultResult

Result for those requests that are deemed to pass the policy defined by this clause. The default is to IGNORE. This matches the default AuthByPolicy value ContinueWhileIgnore. When the policy is not violated, the next AuthBy is evaluated.
# This Handler has multiple AuthBys that all need to pass
DefaultResult ACCEPT

3.102.2. PolicyResult

Result for those requests that are deemed to violate the policy defined by this clause. The default is to REJECT.
# Complex AuthByPolicies can require to change the default
PolicyResult IGNORE

3.102.3. FailurePolicyContext

FailurePolicyContext is a string parameter that allows grouping policies defined in different AuthBys. The default value is an empty string which puts all monitored policies in the same group.
For example, when failure policy clauses are configured for two Handlers with the same FailurePolicContext value, it is enough for a policy violation to occur in one Handler. The subsequent attempts by the same source will be deemed to be in violation by the both Handlers. With different FailurePolicyContext values, a violation detected in one Handler does not effect policing done within the other Handler.
# This AuthBy has its separate policy group
FailurePolicyContext clause1-policy

3.102.4. ConsecutiveFailures

This integer value parameter defines how many consecutive failures trigger a policy violation. There is no default and the policy is not enabled.
# 5 consecutive failures trigger a policy violation
ConsecutiveFailures 5

3.102.5. ConsecutiveLockTime

This integer value parameter defines in seconds how long a policy violation remains active. There is no default and the lock opens immediately.
# When ConsecutiveFailures is hit, violation is active for 5 minutes
ConsecutiveLockTime 300

3.102.6. ConsecutiveWindow

This integer value parameter defines in seconds the size of windows within which the consecutive failures must occur. There is no default and consecutive failures are not limited by time. While windowing is available with consecutive failure policer, most configure may choose not to active it.
# Reset consecutive counter every two minutes
ConsecutiveWindow 120

3.102.7. CumulativeFailures

This integer value parameter defines how many cumulative failures trigger a policy violation. There is no default and the policy is not enabled.
# 200 cumulative failures trigger a policy violation
CumulativeFailures 200

3.102.8. CumulativeLockTime

This integer value parameter defines in seconds how long a policy violation remains active. There is no default and the lock opens immediately.
# When CumulativeFailures is hit, violation is active for 4 hours
CumulativeLockTime 14400

3.102.9. CumulativeWindow

This integer value parameter defines in seconds the size of windows within which the cumulative failures must occur. There is no default and cumulative failures are not limited by time. Windowing is typically used with cumulative failure policy to prevent eventual policy violations.
# Reset cumulative counter every 12 hours
CumulativeWindow 43200