Files
authentik/website/docs/customize/blueprints/v1/models.mdx
T
Dominic R 899994027d core: support hashed password in users API + automated install (#18686)
* 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>
2026-04-29 06:27:59 +02:00

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
```