Authentik: setting up a Reputation Policy

Policies provide configuration and flexibility when defining the user login and authentication process.

Essentially, policies decide whether a given stage will be applied within a flow, as well as whether specific users can access that flow at all.

For example, you can create a policy that skips the MFA prompt stage for certain users. Or you could define a policy that only allows access to the login flow if certain conditions are met. In this article, I’ll look at the reputation policy.

Reputation Policy

#

Authentik tracks recent login attempts for each identifier (username, email address, etc.) and client IP address. These values are stored as scores. Failed login attempts decrease the score by 1, and successful ones increase it by 1.

This policy can be used, for example, to make users with a low score go through a CAPTCHA check before continuing to log in.

Under the administrator account, go to the Flows and Stages > Flows menu

Select your main identification flow, in my case default-authentication-flow, then go to the Policy/Groups/User Bindings section

Next, go to Create and Bind Policy, and select Reputation Policy from the menu.

In the next section, give the policy a name that makes sense to you.

Next comes a very important point to keep in mind. If you select both check ip and check username, then if, say, user Vanya fails a login attempt from a specific IP address, that access will be denied. But if, say, Galya successfully logs in from that same IP address, she will be granted access.

If you select only check ip, then failed login attempts from a specific IP address, regardless of username, will result in that IP being denied.

Conversely, if you select only check username, then failed login attempts under a specific username will result in that specific user being denied, regardless of the IP address they’re trying to authenticate from.

Choose whichever option best fits your needs.

Threshold is the value at which the policy kicks in. The default is -5.

In the next section, enable the Negate the result option.

Put simply:

• disabled → the policy works “as is”
• enabled → the policy’s result gets flipped

For example, suppose the policy returns:

• true - conditions are met
• false - conditions are not met

If you enable Negate the result:

• true → becomes false
• false → becomes true

Why is this needed in Authentik: this is handy when a policy defines a “bad” condition, but you need to react to the “good” one, or vice versa - applying a stage only when the conditions are NOT met.

Example with the Reputation Policy: the policy checks score ≥ 0. Without negation, the stage is applied when the reputation is normal. With Negate the result, the stage is instead applied when the reputation is bad (for example, to show a CAPTCHA or block the login).

Also specify the policy’s order number.

In the Flow overview section, you can see how the flow now works.

If your reputation is good, you’ll be able to go through all authentication stages. If your reputation is below the configured threshold (in my case, three failed login attempts from the same IP address), Authentik simply won’t let you proceed further.

You can view reputation values in the Customisation → Reputation Scores menu.

In the next article, we’ll talk about setting up a policy based on the geographic location of the user’s IP address.