mirror of
https://github.com/goauthentik/authentik.git
synced 2026-06-17 19:09:11 +03:00
899994027d
* core: add hash_password command and password_hash bootstrap support * core: prevent hash format exposure in validation error * core: remove redundant password length check * core: remove extra blank lines from hash_password command * core: add password_hash serializer tests, refine validation and imports * core: add null password fields test, add hash warning to docs * core: move hash validation to User.set_password_from_hash method * core: emit password_changed signal in set_password_from_hash * website: remove redundant hash security warning * core: wrap conflict error message for translation * core: wrap invalid hash error message for translation * web, core: add set_password_hash API endpoint and admin UI * core: simplify password_hash check to None comparison * core: use None check for password conflict validation * website: clarify Docker Compose $ escaping for .env vs compose.yml * website: lint * web: lint * core: add nosec comment for empty password string in signal * core: lint * web: Fix Password Hash help text * sources/kerberos,ldap: Gergo's review * add testing for ^^ and type fix * more general signal tests; not provider specific * only used in tests * add warning * we can do this * signals fix???? * core, web, website: review fixes * style(docs): format automated install guide * web: restore modal invoker import after rebase Co-authored-by: Codex <codex@openai.com> * fix generated clients * core: trim hash password command tests * core: add password hash permission * core: cover service account password hashes * web: remove password hash form * core: regenerate password hash migration * core: reuse password serializer for hashes * docs: clarify hashed password imports * Regenerate * core: deduplicate user serializer writes * core: deduplicate password update actions * core: deduplicate password change signaling * tests: reuse password hash API helper * tests: reuse SSF credential assertions * docs: centralize hashed password caveat * core: name password hash signal source * core: centralize password hash validation * core: deduplicate serializer password saves * docs: link source writeback caveats * api: clarify password hash request field * tests: deduplicate password hash API assertions * web: reuse user display-name helper * web: use existing user display formatter * core: reuse reset password permission for hash endpoint * core: keep separate password hash serializer * tests: remove redundant password hash permission test * 21745 Co-authored-by: Gergo <gergo@goauthentik.io> * core: preserve empty password handling in user serializer * core: inline blueprint user serializer fields * Use password hash constant * Simplify user serializer flow * Inline password update handling * Apply serializer cleanup * Clean blueprint password handling * Drop extra returns * Split password hash signal * Align hash signal receivers * Remove stale password guards * Inline password signal --------- Co-authored-by: Codex <codex@openai.com> Co-authored-by: Gergo <gergo@goauthentik.io>
232 lines
6.1 KiB
Plaintext
232 lines
6.1 KiB
Plaintext
# Models
|
|
|
|
Some models behave differently and allow for access to different API fields when created via blueprint.
|
|
|
|
## `authentik_core.token`
|
|
|
|
### `key`
|
|
|
|
Via the standard API, a token's key cannot be changed, it can only be rotated. This is to ensure a high entropy in its key, and to prevent insecure data from being used. However, when provisioning tokens via a blueprint, it may be required to set a token to an existing value.
|
|
|
|
With blueprints, the field `key` can be set, to set the token's key to any value.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_core.token
|
|
state: present
|
|
identifiers:
|
|
identifier: my-token
|
|
attrs:
|
|
key: this-should-be-a-long-value
|
|
user: !KeyOf my-user
|
|
intent: api
|
|
```
|
|
|
|
## `authentik_core.user`
|
|
|
|
### `password`
|
|
|
|
Via the standard API, a user's password can only be set via the separate `/api/v3/core/users/<id>/set_password/` endpoint. In blueprints, the password of a user can be set using the `password` field.
|
|
|
|
Keep in mind that if an LDAP Source is configured and the user maps to an LDAP user, this password change will be propagated to the LDAP server.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_core.user
|
|
state: present
|
|
identifiers:
|
|
username: test-user
|
|
attrs:
|
|
name: test user
|
|
password: this-should-be-a-long-value
|
|
```
|
|
|
|
### `password_hash`
|
|
|
|
In blueprints, a user's password can also be set using the `password_hash` field. The value must be a valid Django password hash, such as one generated with the `hash_password` management command.
|
|
|
|
Use `password_hash` when you need to import or bootstrap an existing hash without exposing the raw password to authentik:
|
|
|
|
```bash
|
|
docker compose run --rm server hash_password 'your-password'
|
|
```
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_core.user
|
|
state: present
|
|
identifiers:
|
|
username: test-user
|
|
attrs:
|
|
name: test user
|
|
password_hash: pbkdf2_sha256$1000000$xKKFuYtJEE27km09BD49x2$4+Z6j3utmouPF5mik0Z21L2P0og5IlmMmIJ46Tj3zCM=
|
|
```
|
|
|
|
`password` and `password_hash` are mutually exclusive; setting both on the same user causes blueprint validation to fail.
|
|
|
|
`password_hash` follows the [hashed-password import behavior](../../../install-config/automated-install.mdx#authentik_bootstrap_password_hash): it updates only authentik's local password verifier and does not propagate to LDAP or Kerberos integrations.
|
|
|
|
### `permissions`
|
|
|
|
The `permissions` field can be used to set global permissions for a user. A full list of possible permissions is included in the JSON schema for blueprints.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_core.user
|
|
identifiers:
|
|
username: test-user
|
|
attrs:
|
|
permissions:
|
|
- authentik_blueprints.view_blueprintinstance
|
|
```
|
|
|
|
## `authentik_core.application`
|
|
|
|
### `icon`
|
|
|
|
Application icons can be directly set to URLs with the `icon` field.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_core.application
|
|
identifiers:
|
|
slug: my-app
|
|
attrs:
|
|
name: My App
|
|
icon: https://goauthentik.io/img/icon.png
|
|
```
|
|
|
|
## `authentik_sources_oauth.oauthsource`, `authentik_sources_saml.samlsource`, `authentik_sources_plex.plexsource`
|
|
|
|
### `icon`
|
|
|
|
Source icons can be directly set to URLs with the `icon` field.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_sources_oauth.oauthsource
|
|
identifiers:
|
|
slug: my-source
|
|
attrs:
|
|
name: My source
|
|
icon: https://goauthentik.io/img/icon.png
|
|
```
|
|
|
|
## `authentik_flows.flow`
|
|
|
|
### `icon`
|
|
|
|
Flow backgrounds can be directly set to URLs with the `background` field.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_flows.flow
|
|
identifiers:
|
|
slug: my-flow
|
|
attrs:
|
|
name: my-flow
|
|
title: My flow
|
|
designation: authentication
|
|
background: https://goauthentik.io/img/icon.png
|
|
```
|
|
|
|
## `authentik_rbac.role`
|
|
|
|
### `permissions`
|
|
|
|
The `permissions` field can be used to set global permissions for a role. A full list of possible permissions is included in the JSON schema for blueprints.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_rbac.role
|
|
identifiers:
|
|
name: test-role
|
|
attrs:
|
|
permissions:
|
|
- authentik_blueprints.view_blueprintinstance
|
|
```
|
|
|
|
## `authentik_stages_invitation.invitation`:ak-version[2025.12]
|
|
|
|
The `created_by` field can be set to a user. If no value is given, the internal hidden anonymous user is used.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_stages_invitation.invitation
|
|
identifiers:
|
|
name: test-invitation
|
|
attrs:
|
|
created_by: !Find [authentik_core.user, [username, "my-admin-user"]]
|
|
```
|
|
|
|
## `authentik_policies.policybinding`
|
|
|
|
### Required fields
|
|
|
|
Each PolicyBinding entry must have **exactly one** of the following set in `attrs`:
|
|
|
|
- `policy`: Reference to a Policy object
|
|
- `group`: Reference to a Group object
|
|
- `user`: Reference to a User object
|
|
|
|
Setting none or multiple in a single binding will cause validation errors. However, you can create multiple separate bindings to the same target with different `order` values.
|
|
|
|
Example with multiple bindings to the same application:
|
|
|
|
```yaml
|
|
# Bind a policy
|
|
- model: authentik_policies.policybinding
|
|
identifiers:
|
|
target: !Find [authentik_core.application, [slug, my-app]]
|
|
order: 0
|
|
attrs:
|
|
policy: !Find [authentik_policies.expression.expressionpolicy, [name, my-policy]]
|
|
|
|
# Bind a group to the same application
|
|
- model: authentik_policies.policybinding
|
|
identifiers:
|
|
target: !Find [authentik_core.application, [slug, my-app]]
|
|
order: 1
|
|
attrs:
|
|
group: !Find [authentik_core.group, [name, admins]]
|
|
```
|
|
|
|
## `authentik_endpoints_connectors_agent.enrollmenttoken`
|
|
|
|
### `key`
|
|
|
|
Via the standard API, a token's key cannot be changed, it can only be rotated. This is to ensure a high entropy in its key, and to prevent insecure data from being used. However, when provisioning enrollment tokens via a blueprint, it may be required to set a token to an existing value.
|
|
|
|
With blueprints, the field `key` can be set, to set the enrollment token's key to any value.
|
|
|
|
For example:
|
|
|
|
```yaml
|
|
# [...]
|
|
- model: authentik_endpoints_connectors_agent.enrollmenttoken
|
|
state: present
|
|
identifiers:
|
|
name: my-token
|
|
attrs:
|
|
key: this-should-be-a-long-value
|
|
connector: !KeyOf connector
|
|
```
|