mirror of
https://github.com/goauthentik/authentik
synced 2026-04-28 02:18:11 +02:00
404570a4d2
* Reorganize policy documentation * website/docs: address policy docs review feedback * post-rebase * website/docs: Reorganize policy documentation -- Revisions (#21601) * apply suggestions --------- Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
113 lines
5.3 KiB
Markdown
113 lines
5.3 KiB
Markdown
---
|
|
title: Policy Bindings and Evaluation
|
|
tags:
|
|
- policy
|
|
- bindings
|
|
- access-control
|
|
---
|
|
|
|
For step-by-step instructions on creating and attaching policies, see [Working with policies](./working_with_policies.md). This page focuses on where policy bindings apply, how authentik evaluates them, and which options affect the result.
|
|
|
|
## Where policies can be bound
|
|
|
|
:::info Stage Bindings
|
|
In authentik, a stage is attached to a flow through a stage binding. When you attach a policy to a stage inside a flow, you are binding the policy to that stage binding, not directly to the stage definition itself. To learn more, see [Bindings](../../add-secure-apps/bindings-overview/index.md).
|
|
:::
|
|
|
|
| Binding target | What it controls | How to configure it |
|
|
| -------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
|
|
| Flow | Whether the user can start or continue using the flow | [Bind a policy to a flow](./working_with_policies.md#bind-a-policy-to-a-flow) |
|
|
| Stage binding | Whether a specific stage runs in that flow | [Bind a policy to a stage binding](./working_with_policies.md#bind-a-policy-to-a-stage-binding) |
|
|
| Application | Whether the user can access the application | [Bind a policy to an application](./working_with_policies.md#bind-a-policy-to-an-application) |
|
|
| Source | Whether the source can be used for login or enrollment | [Bind a policy to a source](./working_with_policies.md#bind-a-policy-to-a-source) |
|
|
|
|
In the same binding UI, you can also bind a **user** or **group** directly. Those are evaluated as simple membership checks and are useful when you want a direct allow or deny rule without creating a separate policy object.
|
|
|
|
## Validate prompt data with policies
|
|
|
|
Some stages also have their own policy hooks. The most common example is the [Prompt stage](../../add-secure-apps/flows-stages/stages/prompt/index.md), which supports **Validation Policies**.
|
|
|
|
Use prompt-stage validation policies when the decision depends on data the user has just entered, such as:
|
|
|
|
- password complexity
|
|
- password history
|
|
- matching two prompt fields
|
|
- validating an email domain during enrollment
|
|
|
|
Prompt-stage validation is often the right place for [Password](./types/password.md), [Password Uniqueness](./types/password-uniqueness.md), and [Expression](./types/expression/index.mdx) policies.
|
|
|
|
## How authentik evaluates policies
|
|
|
|
When a flow, stage binding, application, or source has multiple bindings, authentik evaluates them in order.
|
|
|
|
### Engine mode: `Any` vs `All`
|
|
|
|
Every policy binding target has a **Policy engine mode**:
|
|
|
|
- `Any`: the target passes when any binding passes
|
|
- `All`: the target passes only when every binding passes
|
|
|
|
The default mode is `Any`.
|
|
|
|
### Order
|
|
|
|
Bindings are evaluated in ascending order. This matters most when you inspect logs or when you are combining multiple policies that produce end-user messages.
|
|
|
|
### Enabled bindings only
|
|
|
|
Disabled bindings are skipped entirely.
|
|
|
|
### Direct user and group bindings
|
|
|
|
Bindings to users and groups are evaluated alongside policy bindings:
|
|
|
|
- a user binding passes when the current user matches
|
|
- a group binding passes when the current user is a member of that group
|
|
|
|
These are a simple way to mix static membership checks with policy-based logic.
|
|
|
|
### No bindings means pass
|
|
|
|
If a target has no applicable bindings, authentik treats the result as passing.
|
|
|
|
## Binding options
|
|
|
|
Bindings have a few important options beyond the target and order.
|
|
|
|
### Negate
|
|
|
|
**Negate** flips the pass or fail result of the binding. This is useful when you want to express "everyone except this group" or turn an allow-style policy into a deny-style rule without copying it.
|
|
|
|
Negation only changes the boolean result. Any messages returned by the policy are left unchanged.
|
|
|
|
### Timeout
|
|
|
|
**Timeout** limits how long authentik will wait for a policy execution before it is terminated. This is especially relevant for expression policies or other policy types that may call external systems. Defaults to 30 seconds.
|
|
|
|
### Failure result
|
|
|
|
If a policy errors during execution, **Failure result** decides whether authentik should treat that failure as pass or fail.
|
|
|
|
Use this carefully:
|
|
|
|
- fail closed when the policy protects access to something sensitive
|
|
- fail open only when availability is more important than enforcement for that specific check
|
|
|
|
### Execution logging
|
|
|
|
Individual policies can enable **Execution logging**. When enabled, authentik logs every execution of that policy, not only failures and exceptions. This is helpful while debugging complex access rules.
|
|
|
|
## Common patterns
|
|
|
|
### Limit application access with a group or policy
|
|
|
|
Bind a group directly when the rule is static. Bind a policy when access depends on runtime context such as network, source, prompt data, or request history.
|
|
|
|
### Run a stage only for some users
|
|
|
|
Bind a policy to the stage binding, not just to the flow. The stage will only run when that binding passes.
|
|
|
|
### Validate user input
|
|
|
|
Attach validation policies directly to the prompt stage when the decision depends on the values the user just entered.
|