16 docs tagged with "policy"

Use an expression policy when only specific email domains should be allowed to enroll or authenticate.

Device compliance policies are used to limit access to authentik and applications based on Device Compliance information.

By default, authentik does not require email addresses to be unique. If you want to enforce uniqueness, use an expression policy during enrollment or profile-edit flows.

Use an Event Matcher policy when you want to match authentik events by a small set of built-in fields instead of writing a custom expression.

Expression policies let you write custom Python for cases where the built-in policy types are not enough.

This page documents the expression-policy execution environment in authentik.

Use a GeoIP policy when you want to make access decisions based on where a request appears to come from.

Flow context can be read and updated from an Expression policy through context["flow_plan"].context.

Use a Password Expiry policy when passwords should expire after a fixed number of days.

Use a Password policy when you want to validate a password entered in a prompt stage.

The Password Uniqueness policy is an enterprise policy that prevents users from reusing previously used passwords.

Policies are reusable decisions in authentik. They let you control whether a user can access an application, whether a stage in a flow should run, whether a source can be used, or whether data entered in a prompt stage is valid.

For a high-level overview of the available policy types, see Policies. This page focuses on the mechanics: where policies are attached, how bindings work, and how authentik evaluates multiple results.

Policy types are the built-in policy objects you can create in authentik.

Use a Reputation policy when you want authentik to react to repeated failed authentication attempts from a username, a client IP, or both.

You can use an expression policy to route users to different sources based on the email address they enter.