habsi/authentik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

website/docs: add more info and links about enforciing unique email addresses (#9154)

Browse Source 
* edits and new link

* tweaked wording about default flow

* Ken edit

* Update website/docs/flow/index.md

Co-authored-by: Jens L. <jens@goauthentik.io>
Signed-off-by: Tana M Berry <tanamarieberry@yahoo.com>

---------

Signed-off-by: Tana M Berry <tanamarieberry@yahoo.com>
Co-authored-by: Tana M Berry <tana@goauthentik.com>
Co-authored-by: Jens L. <jens@goauthentik.io>
This commit is contained in:
Tana M Berry
2024-04-11 06:49:34 -05:00
committed by GitHub
parent 6b629d8a9b
commit c89b7b74e0
3 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
website/docs/flow/index.md
View File

@ -12,7 +12,7 @@ For example, a standard login flow would consist of the following stages:
Upon flow execution, a plan containing all stages is generated. This means that all attached policies are evaluated upon execution. This behaviour can be altered by enabling the **Evaluate when stage is run** option on the binding.
To determine which flow is linked, authentik searches all flows with the required designation and chooses the first instance the current user has access to.
The determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../core/brands.md). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
## Permissions
@ -42,7 +42,7 @@ The authentication flow should always contain a [**User Login**](stages/user_log
This designates a flow to be used to invalidate a session.
This stage should always contain a [**User Logout**](stages/user_logout.md) stage, which resets the current session.
This flow should always contain a [**User Logout**](stages/user_logout.md) stage, which resets the current session.
#### Enrollment

2
website/docs/policies/working_with_policies/unique_email.md
View File

@ -4,7 +4,7 @@ title: Ensure unique email addresses
Due to the database design of authentik, email addresses are by default not required to be unique. This behavior can however be changed by policies.
The snippet below can as the expression in policies both with enrollment flows, where the policy should be bound to any stage before the [User write](../../flow/stages/user_write.md) stage, or it can be used with the [Prompt stage](../../flow/stages/prompt/index.md).
The snippet below can be used as the expression in policies both with enrollment flows, where the policy should be bound to any stage before the [User write](../../flow/stages/user_write.md) stage, or with the [Prompt stage](../../flow/stages/prompt/index.md).
```python
from authentik.core.models import User

2
website/docs/user-group-role/user/user_basic_operations.md
View File

@ -4,6 +4,8 @@ title: Manage users
The following topics are for the basic management of users: how to create, modify, delete or deactivate users, and using a recovery email.
[Policies](../../policies/index.md) can be used to further manage how users are authenticated. For example, by default authentik does not require email addresses be unique, but you can use a policy to [enforce unique email addresses](../../policies/working_with_policies/unique_email.md).
### Create a user
> If you want to automate user creation, you can do that either by [invitations](./invitations.md), [`user_write` stage](../../flow/stages/user_write), or [using the API](/developer-docs/api/browser).