website: latest migration to new structure (#11522)
* first pass
* dependency shenanigans
* move blueprints
* few broken links
* change config the throw errors
* internal file edits
* fighting links
* remove sidebarDev
* fix subdomain
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix relative URL
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix mismatched package versions
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix api reference build
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* test tweak
* links hell
* more links hell
* links hell2
* yep last of the links
* last broken link fixed
* re-add cves
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add devdocs redirects
* add dir
* tweak netlify.toml
* move latest 2 CVES into dir
* fix links to moved cves
* typoed title fix
* fix link
* remove banner
* remove committed api docs
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* integrations: remove version dropdown
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* Update Makefile
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* change doc links in web as well
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* fix some more docs paths
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* fix more docs paths
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* ci: require ci-web.build for merging
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* Revert "ci: require ci-web.build for merging"
This reverts commit b99a4842a9.
* remove sluf for Application
* put slug back in
* minor fix to trigger deploy
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Co-authored-by: Tana M Berry <tana@goauthentik.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
This commit is contained in:
Tana M Berry
41
website/docs/add-secure-apps/applications/index.md
Normal file
41
website/docs/add-secure-apps/applications/index.md
Normal file
@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Applications
|
||||
slug: /applications
|
||||
---
|
||||
|
||||
Applications, as defined in authentik, are used to configure and separate the authorization/access control and the appearance of a specific software application in the **My applications** page.
|
||||
|
||||
When a user logs into authentik, they see a list of the applications for which authentik is configured to provide authentication and authorization (the applications that that they are authorized to use).
|
||||
|
||||
Applications are the "other half" of providers. They typically exist in a 1-to-1 relationship; each application needs a provider and every provider can be used with one application. Applications can, however, use specific, additional providers to augment the functionality of the main provider. For more information, see [Backchannel providers](./manage_apps.md#backchannel-providers).
|
||||
|
||||
Furthermore, the [RAC (Remote Access Control)](../providers/rac/index.md) feature uses a single application and a single provider, but multiple "endpoints". An endpoint defines each remote machine.
|
||||
|
||||
:::info
|
||||
For information about creating and managing applications, refer to [Manage applications](./manage_apps.md).
|
||||
:::
|
||||
|
||||
## Appearance
|
||||
|
||||
Applications are displayed to users when:
|
||||
|
||||
- The user has access defined via policies (or the application has no policies bound)
|
||||
- A valid Launch URL is configured/could be guessed, this consists of URLs starting with http:// and https://
|
||||
|
||||
The following options can be configured:
|
||||
|
||||
- _Name_: This is the name shown for the application card
|
||||
- _Launch URL_: The URL that is opened when a user clicks on the application. When left empty, authentik tries to guess it based on the provider
|
||||
|
||||
You can use placeholders in the launch url to build them dynamically based on the logged in user. For example, you can set the Launch URL to `https://goauthentik.io/%(username)s`, which will be replaced with the currently logged in user's username.
|
||||
|
||||
Only applications whose launch URL starts with `http://` or `https://` or are relative URLs are shown on the users' **My applications** page. This can also be used to hide applications that shouldn't be visible on the **My applications** page but are still accessible by users, by setting the _Launch URL_ to `blank://blank`.
|
||||
|
||||
- _Icon (URL)_: Optionally configure an Icon for the application
|
||||
|
||||
If the authentik server does not have a volume mounted under `/media`, you'll get a text input. This accepts absolute URLs. If you've mounted single files into the container, you can reference them using `https://authentik.company/media/my-file.png`.
|
||||
|
||||
If there is a mount under `/media` or if [S3 storage](../../install-config/storage-s3.md) is configured, you'll instead see a field to upload a file.
|
||||
|
||||
- _Publisher_: Text shown below the application
|
||||
- _Description_: Subtext shown on the application card below the publisher
|
||||
52
website/docs/add-secure-apps/applications/manage_apps.md
Normal file
52
website/docs/add-secure-apps/applications/manage_apps.md
Normal file
@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Manage applications
|
||||
---
|
||||
|
||||
Managing the applications that your team uses involves several tasks, from initially adding the application and provider, to controlling access and visibility of the application, to providing access URLs.
|
||||
|
||||
## Add new applications
|
||||
|
||||
Learn how to add new applications from our video or follow the instructions below.
|
||||
|
||||
### Video
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/broUAWrIWDI;start=22" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
|
||||
### Instructions
|
||||
|
||||
To add an application to authentik and have it display on users' **My applications** page, you can use the Application Wizard, which creates both the new application and the required provider at the same time.
|
||||
|
||||
1. Log into authentik as an admin, and navigate to **Applications --> Applications**.
|
||||
|
||||
2. Click **Create with Wizard**. (Alternatively, use our legacy process and click **Create**. The legacy process requires that the application and its authentication provider be configured separately.)
|
||||
|
||||
3. In the **New application** wizard, define the application details, the provider type and configuration, and then click **Submit**.
|
||||
|
||||
4. To manage the display of the new application on the **My applications** page, you can optionally define the bindings for a specific policy, group, or user. Note that if you do not define bindings, then all users have access to the application, For more information, refer to [authorization](#authorization).
|
||||
|
||||
## Authorization
|
||||
|
||||
Application access can be configured using (Policy) Bindings. Click on an application in the applications list, and select the _Policy / Group / User Bindings_ tab. There you can bind users/groups/policies to grant them access. When nothing is bound, everyone has access. You can use this to grant access to one or multiple users/groups, or dynamically give access using policies.
|
||||
|
||||
By default, all users can access applications when no policies are bound.
|
||||
|
||||
When multiple policies/groups/users are attached, you can configure the _Policy engine mode_ to either:
|
||||
|
||||
- Require users to pass all bindings/be member of all groups (ALL), or
|
||||
- Require users to pass either binding/be member of either group (ANY)
|
||||
|
||||
## Hide applications
|
||||
|
||||
To hide an application without modifying its policy settings or removing it, you can simply set the _Launch URL_ to `blank://blank`, which will hide the application from users.
|
||||
|
||||
Keep in mind that users still have access, so they can still authorize access when the login process is started from the application.
|
||||
|
||||
## Launch URLs
|
||||
|
||||
To give users direct links to applications, you can now use a URL like `https://authentik.company/application/launch/<slug>/`. If the user is already logged in, they will be redirected to the application automatically. Otherwise, they'll be sent to the authentication flow and, if successful, forwarded to the application.
|
||||
|
||||
## Backchannel providers
|
||||
|
||||
Backchannel providers can augment the functionality of applications by using additional protocols. The main provider of an application provides the SSO protocol that is used for logging into the application. Then, additional backchannel providers can be used for protocols such as [SCIM](../providers/scim/index.md) and [LDAP](../providers/ldap/index.md) to provide directory syncing.
|
||||
|
||||
Access restrictions that are configured on an application apply to all of its backchannel providers.
|
||||
191
website/docs/add-secure-apps/flows-stages/flow/context/index.md
Normal file
191
website/docs/add-secure-apps/flows-stages/flow/context/index.md
Normal file
@ -0,0 +1,191 @@
|
||||
---
|
||||
title: Flow Context
|
||||
---
|
||||
|
||||
Each flow execution has an independent _context_. This context holds all of the arbitrary data about that specific flow, data which can then be used and transformed by stages and policies.
|
||||
|
||||
## Managing data in a flow context
|
||||
|
||||
You create and manage the data for a context by configuring policies, stages, and bindings. As you plan your flow, and set up the required stages, etc. you are creating the context data for that flow.
|
||||
|
||||
For example, in the Identification Stage (part of the default login flow), you can define whether users will be prompted to enter an email address, a username, or both. All such information about the flow's configuration makes up the context.
|
||||
|
||||
Any data can be stored in the flow context, however there are some reserved keys in the context dictionary that are used by authentik stages.
|
||||
|
||||
## Context dictionary and reserved keys
|
||||
|
||||
This section describes the data (the context) that are used in authentik, and provides a list of keys, what they are used for and when they are set.
|
||||
|
||||
:::warning
|
||||
Keys prefixed with `goauthentik.io` are used internally by authentik and are subject to change without notice, and should not be modified in policies in most cases.
|
||||
:::
|
||||
|
||||
### Common keys
|
||||
|
||||
#### `pending_user` ([User object](../../../../users-sources/user/user_ref.md#object-properties))
|
||||
|
||||
`pending_user` is used by multiple stages. In the context of most flow executions, it represents the data of the user that is executing the flow. This value is not set automatically, it is set via the [Identification stage](../../stages/identification/index.md).
|
||||
|
||||
Stages that require a user, such as the [Password stage](../../stages/password/index.md), the [Authenticator validation stage](../../stages/authenticator_validate/index.md) and others will use this value if it is set, and fallback to the request's users when possible.
|
||||
|
||||
#### `prompt_data` (Dictionary)
|
||||
|
||||
`prompt_data` is primarily used by the [Prompt stage](../../stages/prompt/index.md). The value of any field within a prompt stage is written to the `prompt_data` dictionary. For example, given a field with the _Field key_ `email` that was submitted with the value `foo@bar.baz` will result in the following context:
|
||||
|
||||
```json
|
||||
{
|
||||
"prompt_data": {
|
||||
"email": "foo@bar.baz"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This data can be modified with policies. The data is also used by stages like [User write](../../stages/user_write.md), which takes data in `prompt_data` and writes it to `pending_user`.
|
||||
|
||||
#### `redirect` (string)
|
||||
|
||||
Stores the final redirect URL that the user's browser will be sent to after the flow is finished executing successfully. This is set when an un-authenticated user attempts to access a secured application, and when a user authenticates/enrolls with an external source.
|
||||
|
||||
#### `pending_user_identifier` (string)
|
||||
|
||||
If _Show matched user_ is disabled, this key will hold the user identifier entered by the user in the identification stage.
|
||||
|
||||
Stores the final redirect URL that the user's browser will be sent to after the flow is finished executing successfully. This is set when an un-authenticated user attempts to access a secured application, and when a user authenticates/enrolls with an external source.
|
||||
|
||||
#### `application` (Application object)
|
||||
|
||||
When an unauthenticated user attempts to access a secured resource, they are redirected to an authentication flow. The application they attempted to access will be stored in the key attached to this object. For example: `application.github`, with `application` being the key and `github` the value.
|
||||
|
||||
#### `source` (Source object)
|
||||
|
||||
When a user authenticates/enrolls via an external source, this will be set to the source they are using.
|
||||
|
||||
#### `outpost` (dictionary) <span class="badge badge--version">authentik 2024.10+</span>
|
||||
|
||||
When a flow is executed by an Outpost (for example the [LDAP](../../../providers/ldap/index.md) or [RADIUS](../../../providers/radius/index.mdx)), this will be set to a dictionary containing the Outpost instance under the key `"instance"`.
|
||||
|
||||
### Scenario-specific keys
|
||||
|
||||
#### `is_sso` (boolean)
|
||||
|
||||
Set to `True` when the flow is executed from an "SSO" context. For example, this is set when a flow is used during the authentication or enrollment via an external source, and if a flow is executed to authorize access to an application.
|
||||
|
||||
#### `is_restored` (Token object)
|
||||
|
||||
Set when a flow execution is continued from a token. This happens for example when an [Email stage](../../stages/email/index.mdx) is used and the user clicks on the link within the email. The token object contains the key that was used to restore the flow execution.
|
||||
|
||||
### Stage-specific keys
|
||||
|
||||
#### Autosubmit stage
|
||||
|
||||
The autosubmit stage is an internal stage type that is not configurable via the API/Web interface. It is used in certain situations, where a POST request is sent from the browser, such as with SAML POST bindings. This works by using an HTML form that is submitted automatically.
|
||||
|
||||
##### `title` (string)
|
||||
|
||||
Optional title of the form shown to the user. Automatically set when this stage is used by the backend.
|
||||
|
||||
##### `url` (string)
|
||||
|
||||
URL that the form will be submitted to.
|
||||
|
||||
##### `attrs` (dictionary)
|
||||
|
||||
Key-value pairs of the data that is included in the form and will be submitted to `url`.
|
||||
|
||||
#### Captcha stage <span class="badge badge--version">authentik 2024.6+</span>
|
||||
|
||||
##### `captcha` (dictionary)
|
||||
|
||||
When `error_on_invalid_score` (TODO) is set to false on a captcha stage, after the execution of the captcha stage, this object will be set in the flow context.
|
||||
|
||||
It contains two keys, `response` which is the raw response from the specified captcha verification URL, and `stage`, which is a reference to the captcha stage that executed the test.
|
||||
|
||||
#### Consent stage
|
||||
|
||||
##### `consent_header` (string)
|
||||
|
||||
The title of the consent prompt shown. Set automatically when the consent stage is used with a OAuth2, Proxy or SAML provider.
|
||||
|
||||
##### `consent_permissions` (List of PermissionDict)
|
||||
|
||||
An optional list of all permissions that will be given to the application by granting consent. Not supported with SAML. When used with an OAuth2 or Proxy provider, this will be set based on the configured scopes.
|
||||
|
||||
#### Deny stage
|
||||
|
||||
##### `deny_message` (string) <span class="badge badge--version">authentik 2023.10+</span>
|
||||
|
||||
Optionally overwrite the deny message shown, has a higher priority than the message configured in the stage.
|
||||
|
||||
#### User write stage
|
||||
|
||||
##### `groups` (List of [Group objects](../../../../users-sources/groups/index.mdx))
|
||||
|
||||
See [Group](../../../../users-sources/groups/index.mdx). If set in the flow context, the `pending_user` will be added to all the groups in this list.
|
||||
|
||||
If set, this must be a list of group objects and not group names.
|
||||
|
||||
##### `user_path` (string)
|
||||
|
||||
Path the `pending_user` will be written to. If not set in the flow, falls back to the value set in the user_write stage, and otherwise to the `users` path.
|
||||
|
||||
##### `user_type` (string) <span class="badge badge--version">authentik 2023.10+</span>
|
||||
|
||||
Type the `pending_user` will be created as. Must be one of `internal`, `external` or `service_account`.
|
||||
|
||||
#### Password stage
|
||||
|
||||
##### `user_backend` (string)
|
||||
|
||||
Set by the [Password stage](../../stages/password/index.md) after successfully authenticating in the user. Contains a dot-notation to the authentication backend that was used to successfully authenticate the user.
|
||||
|
||||
##### `auth_method` (string)
|
||||
|
||||
Set by the [Password stage](../../stages/password/index.md), the [Authenticator validation stage](../../stages/authenticator_validate/index.md), the [OAuth2 Provider](../../../providers/oauth2/index.md), and the API authentication depending on which method was used to authenticate.
|
||||
|
||||
Possible options:
|
||||
|
||||
- `password` (Authenticated via the password in authentik's database)
|
||||
- `token` (Authenticated via API token)
|
||||
- `ldap` (Authenticated via LDAP bind from an LDAP source)
|
||||
- `auth_mfa` (Authentication via MFA device without password)
|
||||
- `auth_webauthn_pwl` (Passwordless authentication via WebAuthn)
|
||||
- `jwt` ([M2M](../../../providers/oauth2/client_credentials.md) authentication via an existing JWT)
|
||||
|
||||
##### `auth_method_args` (dictionary)
|
||||
|
||||
Additional arguments used during the authentication. Value varies depending on `auth_method`.
|
||||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
// List of the MFA device objects used during authentication
|
||||
// applies for `auth_method` `auth_mfa`
|
||||
"mfa_devices": [],
|
||||
// MFA device used for passwordless authentication, applies to
|
||||
// `auth_method` `auth_webauthn_pwl`
|
||||
"device": null,
|
||||
// the token identifier when `auth_method` `token` was used
|
||||
"identifier": "",
|
||||
// JWT information when `auth_method` `jwt` was used
|
||||
"jwt": {},
|
||||
"source": null,
|
||||
"jwk_id": ""
|
||||
}
|
||||
```
|
||||
|
||||
#### Email stage
|
||||
|
||||
##### `email_sent` (boolean)
|
||||
|
||||
Boolean set to true after the email form the email stage has been sent.
|
||||
|
||||
##### `email` (string)
|
||||
|
||||
Optionally override the email address that the email will be sent to. If not set, defaults to the email of `pending_user`.
|
||||
|
||||
#### Identification stage
|
||||
|
||||
##### `pending_user_identifier` (string)
|
||||
|
||||
If _Show matched user_ is disabled, this key will be set to the user identifier entered by the user in the identification stage.
|
||||
BIN
website/docs/add-secure-apps/flows-stages/flow/create-flow.png
Normal file
BIN
website/docs/add-secure-apps/flows-stages/flow/create-flow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 113 KiB |
@ -0,0 +1,57 @@
|
||||
---
|
||||
title: Example Flows
|
||||
---
|
||||
|
||||
:::info
|
||||
You can apply these flows multiple times to stay updated, however this will discard all changes you've made.
|
||||
:::
|
||||
|
||||
:::info
|
||||
The example flows provided below will **override** the default flows, please review the contents of the example flow before importing and consider exporting the affected existing flows first.
|
||||
:::
|
||||
|
||||
## Enrollment (2 Stage)
|
||||
|
||||
Flow: right-click [here](/blueprints/example/flows-enrollment-2-stage.yaml) and save the file.
|
||||
|
||||
Sign-up flow for new users, which prompts them for their username, email, password and name. No verification is done. Users are also immediately logged on after this flow.
|
||||
|
||||
## Enrollment with email verification
|
||||
|
||||
Flow: right-click [here](/blueprints/example/flows-enrollment-email-verification.yaml) and save the file.
|
||||
|
||||
Same flow as above, with an extra email verification stage.
|
||||
|
||||
You'll probably have to adjust the Email stage and set your connection details.
|
||||
|
||||
## Two-factor Login
|
||||
|
||||
Flow: right-click [here](/blueprints/example/flows-login-2fa.yaml) and save the file.
|
||||
|
||||
Login flow which follows the default pattern (username/email, then password), but also checks for the user's OTP token, if they have one configured.
|
||||
|
||||
You can force two-factor authentication by editing the _Not configured action_ in the Authenticator Validation Stage.
|
||||
|
||||
## Login with conditional Captcha
|
||||
|
||||
Flow: right-click [here](/blueprints/example/flows-login-conditional-captcha.yaml) and save the file.
|
||||
|
||||
Login flow which conditionally shows the users a captcha, based on the reputation of their IP and Username.
|
||||
|
||||
By default, the captcha test keys are used. You can get a proper key [here](https://www.google.com/recaptcha/intro/v3.html).
|
||||
|
||||
## Recovery with email verification
|
||||
|
||||
Flow: right-click [here](/blueprints/example/flows-recovery-email-verification.yaml) and save the file.
|
||||
|
||||
Recovery flow, the user is sent an email after they've identified themselves. After they click on the link in the email, they are prompted for a new password and immediately logged on.
|
||||
|
||||
## User deletion
|
||||
|
||||
Flow: right-click [here](/blueprints/example/flows-unenrollment.yaml) and save the file.
|
||||
|
||||
Flow for users to delete their account.
|
||||
|
||||
:::warning
|
||||
This is done without any warning.
|
||||
:::
|
||||
@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Example policy snippets for flows
|
||||
---
|
||||
|
||||
### Redirect current flow to another URL <span class="badge badge--version">authentik 2022.7+</span>
|
||||
|
||||
```python
|
||||
plan = request.context.get("flow_plan")
|
||||
if not plan:
|
||||
return False
|
||||
plan.redirect("https://foo.bar")
|
||||
return False
|
||||
```
|
||||
|
||||
This policy should be bound to the stage after your redirect should happen. For example, if you have an identification and a password stage, and you want to redirect after identification, bind the policy to the password stage. Make sure the stage binding's option _Evaluate when stage is run_ is enabled.
|
||||
|
||||
### Deny flow when user is authenticated
|
||||
|
||||
```python
|
||||
return not request.user.is_authenticated
|
||||
```
|
||||
|
||||
When used with authentik 2022.7 or later, set the flow _Denied action_ to _CONTINUE_. This will redirect already authenticated users to the default interface if they try to use the respective flow.
|
||||
@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Headless
|
||||
---
|
||||
|
||||
The headless flow executor is used by clients that don't have access to the web interface. It is currently used by the LDAP and Radius outposts to authenticate users.
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [**Identification stage**](../../stages/identification/index.md)
|
||||
- [**Password stage**](../../stages/password/index.md)
|
||||
- [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.md)
|
||||
@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Default
|
||||
---
|
||||
|
||||
This is the default, web-based environment that flows are executed in. All stages are compatible with this environment and no limitations are imposed.
|
||||
|
||||
:::info
|
||||
All flow executors use the same [API](../../../../developer-docs/api/flow-executor.md), which allows for the implementation of custom flow executors.
|
||||
:::
|
||||
@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Simplified flow executor
|
||||
---
|
||||
|
||||
<span class="badge badge--version">authentik 2024.6.1+</span>
|
||||
|
||||
A simplified web-based flow executor that authentik automatically uses for older browsers that do not support modern web technologies.
|
||||
|
||||
Currently this flow executor is automatically used for the following browsers:
|
||||
|
||||
- Internet Explorer
|
||||
- Microsoft Edge (up to and including version 18)
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [**Identification stage**](../../stages/identification/index.md)
|
||||
|
||||
:::info
|
||||
Only user identifier and user identifier + password stage configurations are supported; sources and passwordless configurations are not supported.
|
||||
:::
|
||||
|
||||
- [**Password stage**](../../stages/password/index.md)
|
||||
- [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.md)
|
||||
|
||||
Compared to the [default flow executor](./if-flow.md), this flow executor does _not_ support the following features:
|
||||
|
||||
- Localization
|
||||
- Theming (Dark / light themes)
|
||||
- Theming (Custom CSS)
|
||||
- Stages not listed above
|
||||
- Flow inspector
|
||||
@ -0,0 +1,13 @@
|
||||
---
|
||||
title: User settings
|
||||
---
|
||||
|
||||
<span class="badge badge--version">authentik 2023.3+</span>
|
||||
|
||||
---
|
||||
|
||||
The user interface (/if/user/) uses a specialized flow executor to allow individual users to customize their profile. A user's profile consists of key/value fields, so this executor only supports Prompt or User Write stages. If the configured flow contains another stage, a button will be shown to open the default executor.
|
||||
|
||||
Because the stages in a flow can change during its execution, be awre that configuring this executor to use any stage type other than Prompt or User Write will automatically trigger a redirect to the standard executor.
|
||||
|
||||
An admin can customize which fields can be changed by the user by updating the default-user-settings-flow, or copying it to create a new flow with a Prompt Stage and a User Write Stage. Different variants of your flow can be applied to different [Brands](../../../../customize/brands.md) on the same authentik instance.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 564 KiB |
103
website/docs/add-secure-apps/flows-stages/flow/index.md
Normal file
103
website/docs/add-secure-apps/flows-stages/flow/index.md
Normal file
@ -0,0 +1,103 @@
|
||||
---
|
||||
title: Flows
|
||||
---
|
||||
|
||||
Flows are a major component in authentik. In conjunction with stages and [policies](../../../customize/policies/index.md), flows are at the heart of our system of building blocks, used to define and execute the workflows of authentication, authorization, enrollment, and user settings.
|
||||
|
||||
There are over a dozen default, out-of-the box flows available in authentik. Users can decide if they already have everything they need with the default flows or if they want to [create](#create-a-custom-flow) their own custom flow, using the Admin interface.
|
||||
|
||||
A flow is a method of describing a sequence of stages. A stage represents a single verification or logic step. By connecting a series of stages within a flow (and optionally attaching policies as needed) you can build a highly flexible process for authenticating users, enrolling them, and more.
|
||||
|
||||
For example, a standard login flow would consist of the following stages:
|
||||
|
||||
- **Identification stage**: user identifies themselves via a username or email address
|
||||
- **Password stage**: the user's password is checked against the hash in the database
|
||||
- **Login stage**: this stage attaches a currently pending user to the current session
|
||||
|
||||
When these stages are successfully completed, authentik logs in the user.
|
||||
|
||||
|
||||
|
||||
By default, policies are evaluated dynamically, right before the stage (to which a policy is bound) is presented to the user. This flexibility allows the login process to continue, change, or stop, based on the success or failure of each policy.
|
||||
|
||||
This default behaviour can be altered by enabling the **Evaluate when flow is planned** option on the stage binding. With this setting a _flow plan_ containing all stages is generated upon flow execution. This means that all attached policies are evaluated upon execution. For more information about flow plans, read our [flow context documentation](./context/index.md).
|
||||
|
||||
To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../../../customize/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
|
||||
|
||||
Flows can have [policies](../stages/index.md) assigned to them. These policies determine if the current user is allowed to see and use this flow.
|
||||
|
||||
Keep in mind that in certain circumstances, policies cannot match against users and groups as there is no authenticated user yet.
|
||||
|
||||
## Import & Export
|
||||
|
||||
Flows can be imported and exported to share with other people, the community, and for troubleshooting. Flows can be imported to apply new functionality and apply existing workflows.
|
||||
|
||||
Download our [Example flows](./examples/flows.md) and then import them into your authentik instance.
|
||||
|
||||
Starting with authentik 2022.8, flows will be exported as YAML, but JSON-based flows can still be imported.
|
||||
|
||||
## Create a custom flow
|
||||
|
||||
To create a flow, follow these steps:
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
2. In the Admin interface, navigate to **Flows and Stages -> Flows**.
|
||||
3. Click **Create**, define the flow using the [configuration settings](#flow-configuration-options) described below, and then click **Finish**.
|
||||
|
||||
After creating the flow, you can then [bind specific stages](../stages/index.md#bind-a-stage-to-a-flow) to the flow and [bind policies](../../../customize/policies/working_with_policies/working_with_policies.md) to the flow to further customize the user's log in and authentication process.
|
||||
|
||||
To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../../../customize/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.
|
||||
|
||||
## Flow configuration options
|
||||
|
||||
When creating or editing a flow in the UI of the Admin interface, you can set the following configuration options.
|
||||
|
||||
|
||||
|
||||
**Name**: Enter a descriptive name. This is the name that will appear on the list of flows in the Admin interface.
|
||||
|
||||
**Title**: This is the title that will appear on the flow as the end-user logs in and encounters the flow.
|
||||
|
||||
**Slug**: The slug will be used, and appear, in the URL when the flow is in use.
|
||||
|
||||
**Designation**: Flows are designated for a single purpose. This designation changes when a flow is used. The following designations are available:
|
||||
|
||||
- **Authentication**: this option designates a flow to be used for authentication. The authentication flow should always contain a [**User Login**](../stages/user_login/index.md) stage, which attaches the staged user to the current session.
|
||||
|
||||
- **Authorization**: designates a flow to be used for authorization. The authorization flow `default-provider-authorization-explicit-consent` should always contain a consent stage.
|
||||
|
||||
- **Invalidation**: designates a flow to be used to invalidate a session. This flow should always contain a [**User Logout**](../stages/user_logout.md) stage, which resets the current session.
|
||||
|
||||
- **Enrollment**: designates a flow for enrollment. This flow can contain any amount of verification stages, such as [**email**](../stages/email/index.mdx) or [**captcha**](../stages/captcha/index.md). At the end, to create the user, you can use the [**user_write**](../stages/user_write.md) stage, which either updates the currently staged user, or if none exists, creates a new one.
|
||||
|
||||
- **Unenrollment**: designates a flow for unenrollment. This flow can contain any amount of verification stages, such as [**email**](../stages/email/index.mdx) or [**captcha**](../stages/captcha/index.md). As a final stage, to delete the account, use the [**user_delete**](../stages/user_delete.md) stage.
|
||||
|
||||
- **Recovery**: designates a flow for recovery. This flow normally contains an [**identification**](../stages/identification/index.md) stage to find the user. It can also contain any amount of verification stages, such as [**email**](../stages/email/index.mdx) or [**captcha**](../stages/captcha/index.md). Afterwards, use the [**prompt**](../stages/prompt/index.md) stage to ask the user for a new password and the [**user_write**](../stages/user_write.md) stage to update the password.
|
||||
|
||||
- **Stage configuration**: designates a flow for general setup. This designation doesn't have any constraints in what you can do. For example, by default this designation is used to configure Factors, like change a password and setup TOTP.
|
||||
|
||||
**Authentication**: Using this option, you can configure whether the the flow requires initial authentication or not, whether the user must be a superuser, or if the flow requires an outpost.
|
||||
|
||||
**Behavior settings**:
|
||||
|
||||
- **Compatibility mode**: Toggle this option on to increase compatibility with password managers and mobile devices. Password managers like [1Password](https://1password.com/), for example, don't need this setting to be enabled, when accessing the flow from a desktop browser. However accessing the flow from a mobile device might necessitate this setting to be enabled.
|
||||
|
||||
The technical reasons for this settings' existence is due to the JavaScript libraries we're using for the default flow interface. These interfaces are implemented using [Lit](https://lit.dev/), which is a modern web development library. It uses a web standard called ["Shadow DOMs"](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM), which makes encapsulating styles simpler. Due to differences in Browser APIs, many password managers are not compatible with this technology.
|
||||
|
||||
When the compatibility mode is enabled, authentik uses a polyfill which emulates the Shadow DOM APIs without actually using the feature, and instead a traditional DOM is rendered. This increases support for password managers, especially on mobile devices.
|
||||
|
||||
- **Denied action**: Configure what happens when access to a flow is denied by a policy. By default, authentik will redirect to a `?next` parameter if set, and otherwise show an error message.
|
||||
|
||||
- `MESSAGE_CONTINUE`: Show a message if no `?next` parameter is set, otherwise redirect.
|
||||
- `MESSAGE`: Always show error message.
|
||||
- `CONTINUE`: Always redirect, either to `?next` if set, otherwise to the default interface.
|
||||
|
||||
- **Policy engine mode**: Configure the flow to succeed in _any_ policy passes, or only if _all_ policies pass.
|
||||
|
||||
**Appearance Settings**:
|
||||
|
||||
- **Layout**: select how the UI displays the flow when it is executed; with stacked elements, content left or right, and sidebar left or right.
|
||||
|
||||
- **Background**: optionally, select a background image for the UI presentation of the flow.
|
||||
65
website/docs/add-secure-apps/flows-stages/flow/inspector.md
Normal file
65
website/docs/add-secure-apps/flows-stages/flow/inspector.md
Normal file
@ -0,0 +1,65 @@
|
||||
---
|
||||
title: Flow Inspector
|
||||
---
|
||||
|
||||
The flow inspector, introduced in 2021.10, allows administrators to visually determine how custom flows work, inspect the current [flow context](./context/index.md), and investigate issues.
|
||||
|
||||
As shown in the screenshot below, the flow inspector displays next to the selected flow (in this case, "Change Password"), with [information](#flow-inspector-details) about that specific flow and flow context.
|
||||
|
||||
|
||||
|
||||
## Access the Flow Inspector
|
||||
|
||||
:::info
|
||||
Be aware that when running a flow with the inspector enabled, the flow is still executed normally. This means that for example, a [User write](../stages/user_write.md) stage _will_ write user data.
|
||||
:::
|
||||
|
||||
### Permissions and debug mode
|
||||
|
||||
By default, the inspector is only enabled when the currently authenticated user is a superuser, OR if a user has been granted the [permission](../../../users-sources/access-control/permissions.md) **Can inspect a Flow's execution** (or is a user assigned to role with the permission).
|
||||
|
||||
When developing authentik with the debug mode enabled, the inspector is enabled by default and can be accessed by both unauthenticated users and standard users. However the debug mode should only be used for the development of authentik. So unless you are a developer and need the more verbose error information, the best practice for using the flow inspector is to assign the permission, not use debug mode.
|
||||
|
||||
### Open the Flow Inspector
|
||||
|
||||
1. To access the inspector, open the Admin interface and navigate to **Flows and Stages -> Flows**.
|
||||
|
||||
2. Select the specific flow that you want to inspect by clicking its name in the list.
|
||||
|
||||
3. On the Flow's detail page, on the left side under **Execute Flow**, click **with inspector**.
|
||||
|
||||
4. The selected flow will launch in a new browser tab, with the flow inspector displayed to the right.
|
||||
|
||||
Alternatively, a user with the correct permission can launch the inspector by adding the query parameter `?inspector` to the URL when the URL opens on a flow.
|
||||
|
||||
:::info
|
||||
Troubleshooting:
|
||||
|
||||
- If the flow inspector does not launch and a "Bad request" error displays, this is likely either because you selected a flow that is not defined in your instance or the flow has a policy bound directly to it that prevents access, so the inspector won't open because the flow can't run results.
|
||||
- If the flow inspector launches but is empty, you can refresh the browser or advance the flow to load the inspector. This can occur when a race condition happens (the inspector tries to fetch the data before the flow plan is fully planned and as such the panel just shows blank).
|
||||
|
||||
:::
|
||||
|
||||
### Flow Inspector Details
|
||||
|
||||
The following information is shown in the inspector:
|
||||
|
||||
#### Next stage
|
||||
|
||||
This is the currently planned next stage. If you have stage bindings configured to `Evaluate when flow is planned`\_`, then you will see the result here. If, however, you have them configured to re-evaluate (`Evaluate when stage is run`), then this will not show up here, since the results will vary based on your input.
|
||||
|
||||
Shown is the name and kind of the stage, as well as the unique ID.
|
||||
|
||||
#### Plan history
|
||||
|
||||
Here you can see an overview of which stages have run, which is currently active, and which is planned to come next. Same caveats as above apply.
|
||||
|
||||
#### Current plan context
|
||||
|
||||
This shows you the current context. This will contain fields depending on the same, after an identification stage for example you would see "pending_user" defined.
|
||||
|
||||
This data is not cleaned, so if your flow involves inputting a password, it will be shown here too.
|
||||
|
||||
#### Session ID
|
||||
|
||||
The unique ID for the currently used session. This can be used to debug issues with flows restarting/losing state.
|
||||
25
website/docs/add-secure-apps/flows-stages/flow/layouts.md
Normal file
25
website/docs/add-secure-apps/flows-stages/flow/layouts.md
Normal file
@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Layouts
|
||||
---
|
||||
|
||||
Starting with authentik 2022.5, the layout of the default flow executor can be changed. Below are examples for the available options:
|
||||
|
||||
### Stacked (default)
|
||||
|
||||
|
||||
|
||||
### Content besides logo (left)
|
||||
|
||||
|
||||
|
||||
### Content besides logo (right)
|
||||
|
||||
|
||||
|
||||
### Sidebar (left)
|
||||
|
||||
|
||||
|
||||
### Sidebar (right)
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 2.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.8 MiB |
BIN
website/docs/add-secure-apps/flows-stages/flow/simple_stages.png
Normal file
BIN
website/docs/add-secure-apps/flows-stages/flow/simple_stages.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Duo authenticator setup stage
|
||||
---
|
||||
|
||||
This stage configures a Duo authenticator. To get the API Credentials for this stage, open your Duo Admin dashboard.
|
||||
|
||||
Go to Applications, click on Protect an Application and search for "Auth API". Click on Protect.
|
||||
|
||||
Copy all of the integration key, secret key and API hostname, and paste them in the Stage form.
|
||||
|
||||
Devices created reference the stage they were created with, since the API credentials are needed to authenticate. This also means when the stage is deleted, all devices are removed.
|
||||
|
||||
## Importing users <span class="badge badge--version">authentik 2022.9+</span>
|
||||
|
||||
:::info
|
||||
Due to the way the Duo API works, authentik can only automatically import existing Duo users when a Duo MFA or higher license is active.
|
||||
:::
|
||||
|
||||
To import a device, open the Stages list in the authentik Admin interface. On the right next to the import button you'll see an import button, with which you can import Duo devices to authentik users.
|
||||
|
||||
The Duo username can be found by navigating to your Duo Admin dashboard and selecting _Users_ in the sidebar. Optionally if you have multiple users with the same username, you can click on a User and copy their ID from the URL, and use that to import the device.
|
||||
|
||||
### Older versions <span class="badge badge--version">authentik 2021.9.1+</span>
|
||||
|
||||
You can call the `/api/v3/stages/authenticator/duo/{stage_uuid}/import_devices/` endpoint ([see here](https://goauthentik.io/api/#post-/stages/authenticator/duo/-stage_uuid-/import_devices/)) using the following parameters:
|
||||
|
||||
- `duo_user_id`: The Duo User's ID. This can be found in the Duo Admin Portal, navigating to the user list and clicking on a single user. Their ID is shown in th URL.
|
||||
- `username`: The authentik user's username to assign the device to.
|
||||
|
||||
Additionally, you need to pass `stage_uuid` which is the `authenticator_duo` stage, in which you entered your API credentials.
|
||||
@ -0,0 +1,80 @@
|
||||
---
|
||||
title: SMS authenticator setup stage
|
||||
---
|
||||
|
||||
This stage configures an SMS-based authenticator using either Twilio, or a generic HTTP endpoint.
|
||||
|
||||
## Providers
|
||||
|
||||
#### Twilio
|
||||
|
||||
Navigate to https://console.twilio.com/, and log in to your existing account, or create a new one.
|
||||
|
||||
In the sidebar, navigate to _Explore Products_, then _Messaging_, and _Services_ below that.
|
||||
|
||||
Click on _Create Messaging Service_ to create a new set of API credentials.
|
||||
|
||||
Give the service a Name, and select _Verify users_ as a use-case.
|
||||
|
||||
In the next step, add an address from your Sender Pool. Instructions on how to create numbers are not covered here, please check the Twilio documentation [here](https://www.twilio.com/docs).
|
||||
|
||||
The other two steps can be skipped using the _Skip setup_ button.
|
||||
|
||||
Navigate back to the root of your Twilio console, and copy the Auth token. This is the value for the _Twilio Auth Token_ field in authentik. Copy the value of **Account SID**. This is the value for the _Twilio Account SID_ field in authentik.
|
||||
|
||||
#### Generic
|
||||
|
||||
For the generic provider, a POST request will be sent to the URL you have specified in the _External API URL_ field. The request payload looks like this
|
||||
|
||||
```json
|
||||
{
|
||||
"From": "<value of the *From number* field>",
|
||||
"To": "<the phone number of the user's device>",
|
||||
"Body": "<the token that the user needs to authenticate>,
|
||||
}
|
||||
```
|
||||
|
||||
Authentication can either be done as HTTP Basic, or via a Bearer Token. Any response with status 400 or above is counted as failed, and will prevent the user from proceeding.
|
||||
|
||||
Starting with authentik 2022.10, a custom webhook mapping can be specified to freely customize the payload of the request. For example:
|
||||
|
||||
```python
|
||||
return {
|
||||
"from": stage.from_number,
|
||||
"to": device.phone_number,
|
||||
"body": f"foo bar baz {token}".
|
||||
}
|
||||
```
|
||||
|
||||
## Verify only <span class="badge badge--version">authentik 2022.6+</span>
|
||||
|
||||
To only verify the validity of a users' phone number, without saving it in an easily accessible way, you can enable this option. Phone numbers from devices enrolled through this stage will only have their hashed phone number saved. These devices can also not be used with the [Authenticator validation](../authenticator_validate/index.md) stage.
|
||||
|
||||
## Limiting phone numbers
|
||||
|
||||
To limit phone numbers (for example to a specific region code), you can create an expression policy to validate the phone number, and use a prompt stage for input.
|
||||
|
||||
### Expression policy
|
||||
|
||||
Create an expression policy to check the phone number:
|
||||
|
||||
```python
|
||||
# Trim all whitespace in and around the user input
|
||||
phone_number = regex_replace(request.context["prompt_data"]["phone"], r'\s+', '')
|
||||
|
||||
# Only allow a specific region code
|
||||
if phone_number.startswith("+1234"):
|
||||
return True
|
||||
ak_message("Invalid phone number or missing region code")
|
||||
return False
|
||||
```
|
||||
|
||||
### Prompt stage
|
||||
|
||||
Create a text prompt field with the _field key_ set to `phone`. Make sure it is selected as a required field.
|
||||
|
||||
Create a prompt stage with the phone field you created above, and select the expression policy created above as validation policy.
|
||||
|
||||
### Flow
|
||||
|
||||
Create a new flow to enroll SMS devices. Bind the prompt stage created above as first stage, and create/bind a _SMS Authenticator Setup Stage_, and bind it to the flow as second stage. This stage will see the `phone` field in the flow's context's `prompt_data`, and not prompt the user for a phone number.
|
||||
@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Static authenticator setup stage
|
||||
---
|
||||
|
||||
This stage configures static Tokens, which can be used as a backup method to time-based OTP tokens.
|
||||
|
||||
You can configure how many tokens are shown to the user.
|
||||
@ -0,0 +1,9 @@
|
||||
---
|
||||
title: TOTP authenticator setup stage
|
||||
---
|
||||
|
||||
This stage configures a time-based OTP Device, such as Google Authenticator or Authy.
|
||||
|
||||
You can configure how many digits should be used for the OTP Token.
|
||||
|
||||
The Config URL's Issuer is set based on the currently active brand's branding title. The default setup can cause issues if the same username is used on multiple authentik issues within the same authenticator app, so changing the brand title is recommended.
|
||||
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: Authenticator validation stage
|
||||
---
|
||||
|
||||
This stage validates an already configured Authenticator Device. This device has to be configured using any of the other authenticator stages:
|
||||
|
||||
- [Duo authenticator stage](../authenticator_duo/index.md)
|
||||
- [SMS authenticator stage](../authenticator_sms/index.md).
|
||||
- [Static authenticator stage](../authenticator_static/index.md).
|
||||
- [TOTP authenticator stage](../authenticator_totp/index.md)
|
||||
- [WebAuth authenticator stage](../authenticator_webauthn/index.md).
|
||||
|
||||
You can select which type of device classes are allowed.
|
||||
|
||||
Using the `Not configured action`, you can choose what happens when a user does not have any matching devices.
|
||||
|
||||
- Skip: Validation is skipped and the flow continues
|
||||
- Deny: Access is denied, the flow execution ends
|
||||
- Configure: This option requires a _Configuration stage_ to be set. The validation stage will be marked as successful, and the configuration stage will be injected into the flow.
|
||||
|
||||
By default, authenticator validation is required every time the flow containing this stage is executed. To only change this behavior, set _Last validation threshold_ to a non-zero value. (Requires authentik 2022.5)
|
||||
Keep in mind that when using Code-based devices (TOTP, Static and SMS), values lower than `seconds=30` cannot be used, as with the way TOTP devices are saved, there is no exact timestamp.
|
||||
|
||||
### Options
|
||||
|
||||
#### Less-frequent validation <span class="badge badge--version">authentik 2022.5.1+</span>
|
||||
|
||||
You can configure this stage to only ask for MFA validation if the user hasn't authenticated themselves within a defined time period. To configure this, set _Last validation threshold_ to any non-zero value. Any of the users devices within the selected classes are checked.
|
||||
|
||||
#### Passwordless authentication <span class="badge badge--version">authentik 2021.12.4+</span>
|
||||
|
||||
:::caution
|
||||
Firefox has some known issues regarding TouchID (see https://bugzilla.mozilla.org/show_bug.cgi?id=1536482)
|
||||
:::
|
||||
|
||||
Passwordless authentication currently only supports WebAuthn devices, like security keys and biometrics. For an alternate passwordless setup, see [Password stage](../password/index.md#passwordless-login), which supports other types.
|
||||
|
||||
To configure passwordless authentication, create a new Flow with the designation set to _Authentication_.
|
||||
|
||||
As first stage, add an _Authenticator validation_ stage, with the WebAuthn device class allowed.
|
||||
After this stage you can bind any additional verification stages.
|
||||
As final stage, bind a _User login_ stage.
|
||||
|
||||
Users can either access this flow directly via its URL, or you can modify any Identification stage's _Passwordless flow_ setting to add a direct link to this flow.
|
||||
|
||||
#### Logging
|
||||
|
||||
Logins which used Passwordless authentication have the _auth_method_ context variable set to `auth_webauthn_pwl`, and the device used is saved in the arguments. Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"auth_method": "auth_webauthn_pwl",
|
||||
"http_request": {
|
||||
"args": {
|
||||
"query": ""
|
||||
},
|
||||
"path": "/api/v3/flows/executor/test/",
|
||||
"method": "GET"
|
||||
},
|
||||
"auth_method_args": {
|
||||
"device": {
|
||||
"pk": 1,
|
||||
"app": "authentik_stages_authenticator_webauthn",
|
||||
"name": "test device",
|
||||
"model_name": "webauthndevice"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### WebAuthn Device type restrictions <span class="badge badge--version">authentik 2024.4+</span>
|
||||
|
||||
Optionally restrict which WebAuthn device types can be used to authenticate.
|
||||
|
||||
When no restriction is set, all WebAuthn devices a user has registered are allowed.
|
||||
|
||||
These restrictions only apply to WebAuthn devices created with authentik 2024.4 or later.
|
||||
@ -0,0 +1,27 @@
|
||||
---
|
||||
title: WebAuthn authenticator setup stage
|
||||
---
|
||||
|
||||
This stage configures a WebAuthn-based Authenticator. This can either be a browser, biometrics or a Security stick like a YubiKey.
|
||||
|
||||
### Options
|
||||
|
||||
#### User verification
|
||||
|
||||
Configure if authentik should require, prefer or discourage user verification for the authenticator. For example when using a virtual authenticator like Windows Hello, this setting controls if a PIN is required.
|
||||
|
||||
#### Resident key requirement
|
||||
|
||||
Configure if the created authenticator is stored in the encrypted memory on the device or in persistent memory. When configuring [passwordless login](../identification/index.md#passwordless-flow), this should be set to either _Preferred_ or _Required_, otherwise the authenticator cannot be used for passwordless authentication.
|
||||
|
||||
#### Authenticator Attachment
|
||||
|
||||
Configure if authentik will require either a removable device (like a YubiKey, Google Titan, etc) or a non-removable device (like Windows Hello, TouchID or password managers), or not send a requirement.
|
||||
|
||||
#### Device type restrictions <span class="badge badge--version">authentik 2024.4+</span>
|
||||
|
||||
Optionally restrict the types of devices allowed to be enrolled. This option can be used to ensure users are only able to enroll FIPS-compliant devices for example.
|
||||
|
||||
When no restrictions are selected, all device types are allowed.
|
||||
|
||||
As authentik does not know of all possible device types, it is possible to select the special option `authentik: Unknown devices` to allow unknown devices.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Captcha stage
|
||||
---
|
||||
|
||||
This stage adds a form of verification using [Google's ReCaptcha](https://www.google.com/recaptcha/intro/v3.html) or compatible services. Currently supported implementations:
|
||||
|
||||
- ReCaptcha
|
||||
- hCaptcha
|
||||
- Turnstile
|
||||
|
||||
## Captcha provider configuration
|
||||
|
||||
### Google ReCaptcha
|
||||
|
||||
This stage has two required fields: Public key and private key. These can both be acquired at https://www.google.com/recaptcha/admin.
|
||||
|
||||
|
||||
|
||||
#### Configuration options
|
||||
|
||||
- JS URL: `https://www.recaptcha.net/recaptcha/api.js`
|
||||
- API URL: `https://www.recaptcha.net/recaptcha/api/siteverify`
|
||||
- Score minimum threshold: `0.5`
|
||||
- Score maximum threshold: `1`
|
||||
|
||||
### hCaptcha
|
||||
|
||||
See https://docs.hcaptcha.com/switch
|
||||
|
||||
#### Configuration options
|
||||
|
||||
- JS URL: `https://js.hcaptcha.com/1/api.js`
|
||||
- API URL: `https://api.hcaptcha.com/siteverify`
|
||||
|
||||
**Score options only apply to hCaptcha Enterprise**
|
||||
|
||||
- Score minimum threshold: `0`
|
||||
- Score maximum threshold: `0.5`
|
||||
|
||||
### Turnstile
|
||||
|
||||
See https://developers.cloudflare.com/turnstile/get-started/migrating-from-recaptcha
|
||||
|
||||
:::warning
|
||||
To use Cloudflare Turnstile, the site must be configured to use the "Invisible" mode, otherwise the widget will be rendered incorrectly.
|
||||
:::
|
||||
|
||||
#### Configuration options
|
||||
|
||||
- JS URL: `https://challenges.cloudflare.com/turnstile/v0/api.js`
|
||||
- API URL: `https://challenges.cloudflare.com/turnstile/v0/siteverify`
|
||||
|
||||
**Score options do not apply when using with turnstile**
|
||||
10
website/docs/add-secure-apps/flows-stages/stages/deny.md
Normal file
10
website/docs/add-secure-apps/flows-stages/stages/deny.md
Normal file
@ -0,0 +1,10 @@
|
||||
---
|
||||
title: Deny stage
|
||||
---
|
||||
|
||||
This stage stops the execution of a flow. This can be used to conditionally deny users access to a flow,
|
||||
even if they are not signed in (and permissions can't be checked via groups).
|
||||
|
||||
:::caution
|
||||
To effectively use this stage, make sure _Evaluate when flow is planned_ is **disable** on the Stage binding.
|
||||
:::
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
164
website/docs/add-secure-apps/flows-stages/stages/email/index.mdx
Normal file
164
website/docs/add-secure-apps/flows-stages/stages/email/index.mdx
Normal file
@ -0,0 +1,164 @@
|
||||
---
|
||||
title: Email stage
|
||||
---
|
||||
|
||||
This stage can be used for email verification. authentik's background worker will send an email using the specified connection details. When an email can't be delivered, delivery is automatically retried periodically.
|
||||
|
||||
|
||||
|
||||
## Behaviour
|
||||
|
||||
By default, the email is sent to the currently pending user. To override this, you can set `email` in the plan's context to another email address, which will override the user's email address (the user won't be changed).
|
||||
|
||||
For example, create this expression policy and bind it to the email stage:
|
||||
|
||||
```python
|
||||
request.context["flow_plan"].context["email"] = "foo@bar.baz"
|
||||
# Or get it from a prompt
|
||||
# request.context["flow_plan"].context["email"] = request.context["prompt_data"]["email"]
|
||||
# Or another user attribute
|
||||
# request.context["flow_plan"].context["email"] = request.context["pending_user"].attributes.get("otherEmail")
|
||||
return True
|
||||
```
|
||||
|
||||
## Custom Templates
|
||||
|
||||
You can also use custom email templates, to use your own design or layout.
|
||||
|
||||
:::info
|
||||
Starting with authentik 2024.2, it is possible to create `.txt` files with the same name as the `.html` template. If a matching `.txt` file exists, the email sent will be a multipart email with both the text and HTML template.
|
||||
:::
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
<Tabs
|
||||
defaultValue="docker-compose"
|
||||
values={[
|
||||
{label: 'docker-compose', value: 'docker-compose'},
|
||||
{label: 'Kubernetes', value: 'kubernetes'},
|
||||
]}>
|
||||
<TabItem value="docker-compose">
|
||||
Place any custom templates in the `custom-templates` Folder, which is in the same folder as your docker-compose file. Afterwards, you'll be able to select the template when creating/editing an Email stage.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="kubernetes">
|
||||
Create a ConfigMap with your email templates:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: authentik-templates
|
||||
namespace: authentik
|
||||
data:
|
||||
my-template.html: |
|
||||
<tr>...
|
||||
```
|
||||
|
||||
Then, in the helm chart add this to your `values.yaml` file:
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
- name: email-templates
|
||||
configMap:
|
||||
name: authentik-templates
|
||||
volumeMounts:
|
||||
- name: email-templates
|
||||
mountPath: /templates
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::info
|
||||
If you've add the line and created a file, and can't see if, check the worker logs using `docker compose logs -f worker` or `kubectl logs -f deployment/authentik-worker`.
|
||||
:::
|
||||
|
||||
|
||||
|
||||
### Example template
|
||||
|
||||
Templates are rendered using Django's templating engine. The following variables can be used:
|
||||
|
||||
- `url`: The full URL for the user to click on
|
||||
- `user`: The pending user object.
|
||||
- `expires`: The timestamp when the token expires.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
```html
|
||||
{# This is how you can write comments which aren't rendered. #}
|
||||
{# Extend this template from the base email template, which includes base layout and CSS. #}
|
||||
{% extends "email/base.html" %}
|
||||
{# Load the internationalization module to translate strings, and humanize to show date-time #}
|
||||
{% load i18n %}
|
||||
{% load humanize %}
|
||||
{# The email/base.html template uses a single "content" block #}
|
||||
{% block content %}
|
||||
<tr>
|
||||
<td class="alert alert-success">
|
||||
{% blocktrans with username=user.username %} Hi {{ username }},
|
||||
{% endblocktrans %}
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content-wrap">
|
||||
<table width="100%" cellpadding="0" cellspacing="0">
|
||||
<tr>
|
||||
<td class="content-block">
|
||||
{% trans 'You recently requested to change your password for you authentik account. Use the button below to set a new password.' %}
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content-block">
|
||||
<table
|
||||
role="presentation"
|
||||
border="0"
|
||||
cellpadding="0"
|
||||
cellspacing="0"
|
||||
class="btn btn-primary"
|
||||
>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td align="center">
|
||||
<table
|
||||
role="presentation"
|
||||
border="0"
|
||||
cellpadding="0"
|
||||
cellspacing="0"
|
||||
>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>
|
||||
<a
|
||||
id="confirm"
|
||||
href="{{ url }}"
|
||||
rel="noopener noreferrer"
|
||||
target="_blank"
|
||||
>{% trans 'Reset Password' %}</a
|
||||
>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content-block">
|
||||
{% blocktrans with expires=expires|naturaltime %}
|
||||
If you did not request a password change, please ignore this Email. The link above is valid for {{ expires }}.
|
||||
{% endblocktrans %}
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
{% endblock %}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Identification stage
|
||||
---
|
||||
|
||||
This stage provides a ready-to-go form for users to identify themselves.
|
||||
|
||||
## User Fields
|
||||
|
||||
Select which fields the user can use to identify themselves. Multiple fields can be selected. If no fields are selected, only sources will be shown.
|
||||
|
||||
- Username
|
||||
- Email
|
||||
- UPN
|
||||
|
||||
UPN will attempt to identify the user based on the `upn` attribute, which can be imported with an [LDAP Source](../../../../users-sources/sources/protocols/ldap)
|
||||
|
||||
## Password stage
|
||||
|
||||
To prompt users for their password on the same step as identifying themselves, a password stage can be selected here. If a password stage is selected in the Identification stage, the password stage should not be bound to the flow.
|
||||
|
||||
## Enrollment/Recovery Flow
|
||||
|
||||
These fields specify if and which flows are linked on the form. The enrollment flow is linked as `Need an account? Sign up.`, and the recovery flow is linked as `Forgot username or password?`.
|
||||
|
||||
## Pretend user exists <span class="badge badge--version">authentik 2024.2+</span>
|
||||
|
||||
When enabled, any user identifier will be accepted as valid (as long as they match the correct format, i.e. when [User fields](#user-fields) is set to only allow Emails, then the identifier still needs to be an Email). The stage will succeed and the flow will continue to the next stage. Stages like the [Password stage](../password/index.md) and [Email stage](../email/index.mdx) are aware of this "pretend" user and will behave the same as if the user would exist.
|
||||
|
||||
## Source settings
|
||||
|
||||
Some sources (like the [OAuth Source](../../../../users-sources/sources/protocols/oauth/index.md) and [SAML Source](../../../../users-sources/sources/protocols/saml/index.md)) require user interaction. To make these sources available to users, they can be selected in the Identification stage settings, which will show them below the selected [user field](#user-fields).
|
||||
|
||||
By default, sources are only shown with their icon, which can be changed with the _Show sources' labels_ option.
|
||||
|
||||
Furthermore, it is also possible to deselect any [user field option](#user-fields) for an Identification stage, which will result in users only being able to use currently configured sources.
|
||||
|
||||
:::info
|
||||
Starting with authentik 2023.5, when no user fields are selected and only one source is selected, authentik will automatically redirect the user to that source. This only applies when the **Passwordless flow** option is _not_ configured.
|
||||
:::
|
||||
|
||||
## Flow settings
|
||||
|
||||
### Passwordless flow
|
||||
|
||||
See [Passwordless authentication](../authenticator_validate/index.md#passwordless-authentication-authentik-2021124).
|
||||
|
||||
### Enrollment flow
|
||||
|
||||
Optionally can be set to a flow with the designation of _Enrollment_, which will allow users to sign up.
|
||||
|
||||
### Recovery flow
|
||||
|
||||
Optionally can be set to a flow with the designation of _Recovery_, which will allow users to recover their credentials.
|
||||
56
website/docs/add-secure-apps/flows-stages/stages/index.md
Normal file
56
website/docs/add-secure-apps/flows-stages/stages/index.md
Normal file
@ -0,0 +1,56 @@
|
||||
---
|
||||
title: Stages
|
||||
---
|
||||
|
||||
Stages are one of the fundamental building blocks in authentik, along with [flows](../flow/index.md) and [policies](../../../customize/policies/index.md).
|
||||
|
||||
A stage represents a single verification or logic step within a flow. You can bind one or more stages to a flow to create a customized, flexible login and authentication process.
|
||||
|
||||
In the following diagram of the `default-authentication-flow`, you see multiple stages, or steps, in the authentication process for a user. Policies are bound to some stages; this provides for dynamic application of a specific stage _if_ the policy criteria is met.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
flow_pre[["Pre-flow policies"]]
|
||||
flow_pre --Binding 10--> flow_policy_0{{"Policy (Event Matcher Policy)
|
||||
default-match-update"}}
|
||||
flow_policy_0 --Policy denied--> done[["End of the flow"]]
|
||||
flow_policy_0 --> flow_start[["Flow
|
||||
Welcome to authentik!"]]
|
||||
stage_0_policy_0 --Policy passed--> stage_0(["Stage (Identification Stage)
|
||||
default-authentication-identification"])
|
||||
stage_1_policy_0 --Policy passed--> stage_1(["Stage (Password Stage)
|
||||
default-authentication-password"])
|
||||
--> stage_2(["Stage (Authenticator Validation Stage)
|
||||
default-authentication-mfa-validation"])
|
||||
--> stage_3(["Stage (User Login Stage)
|
||||
default-authentication-login"])
|
||||
flow_start --> stage_0_policy_0{{"Policy (Event Matcher Policy)
|
||||
default-match-configuration-error"}}
|
||||
stage_0 --> stage_1_policy_0{{"Policy (Expression Policy)
|
||||
default-authentication-flow-password-stage"}}
|
||||
stage_0_policy_0 --Policy denied--> stage_1(["Stage (Password Stage)
|
||||
default-authentication-password"])
|
||||
stage_1_policy_0 --Policy denied--> stage_2(["Stage (Authenticator Validation Stage)
|
||||
default-authentication-mfa-validation"])
|
||||
stage_3 --> done[["End of the flow"]]
|
||||
```
|
||||
|
||||
## Create a Stage
|
||||
|
||||
To create a stage, follow these steps:
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
2. In the Admin interface, navigate to **Flows and Stages -> Stages**.
|
||||
3. Click **Create**, define the flow using the configuration settings, and then click **Finish**.
|
||||
|
||||
After creating the stage, you can then [bind the stage to a flow](#bind-a-stage-to-a-flow) or [bind a policy to the stage](../../../customize/policies/working_with_policies/working_with_policies.md) (the policy determines whether or not the stage will be implemented in the flow).
|
||||
|
||||
## Bind a stage to a flow
|
||||
|
||||
To bind a stage to a flow, follow these steps:
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
2. In the Admin interface, navigate to **Flows and Stages -> Flows**.
|
||||
3. In the list of flows, click the name of the flow to which you want to bind one or more stages.
|
||||
4. On the Flow page, click the **Stage Bindings** tab at the top.
|
||||
5. Here, you can decide if you want to create a new stage and bind it to the flow (**Create and bind Stage**), or if you want to select an existing stage and bind it to the flow (**Bind existing stage**).
|
||||
@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Invitation stage
|
||||
---
|
||||
|
||||
This stage can be used to invite users. You can use this to enroll users with preset values.
|
||||
|
||||
If the option `Continue Flow without Invitation` is enabled, this stage will continue even when no invitation token is present.
|
||||
|
||||
To check if a user has used an invitation within a policy, you can check `request.context.get("invitation_in_effect", False)`.
|
||||
|
||||
To use an invitation, use the URL `https://authentik.tld/if/flow/your-enrollment-flow/?itoken=invitation-token`.
|
||||
|
||||
You can also prompt the user for an invite by using the [_Prompt stage_](../prompt/index.md) by using a field with a field key of `token`.
|
||||
@ -0,0 +1,29 @@
|
||||
---
|
||||
title: Password stage
|
||||
---
|
||||
|
||||
This is a generic password prompt which authenticates the current `pending_user`. This stage allows the selection of the source the user is authenticated against.
|
||||
|
||||
## Passwordless login
|
||||
|
||||
There are two different ways to configure passwordless authentication; you can follow the instructions [here](../authenticator_validate/index.md#passwordless-authentication-authentik-2021124) to allow users to directly authenticate with their authenticator (only supported for WebAuthn devices), or dynamically skip the password stage depending on the users device, which is documented here.
|
||||
|
||||
Depending on what kind of device you want to require the user to have:
|
||||
|
||||
#### WebAuthn
|
||||
|
||||
```python
|
||||
from authentik.stages.authenticator_webauthn.models import WebAuthnDevice
|
||||
return WebAuthnDevice.objects.filter(user=request.context['pending_user'], confirmed=True).exists()
|
||||
```
|
||||
|
||||
#### Duo
|
||||
|
||||
```python
|
||||
from authentik.stages.authenticator_duo.models import DuoDevice
|
||||
return DuoDevice.objects.filter(user=request.context['pending_user'], confirmed=True).exists()
|
||||
```
|
||||
|
||||
Afterwards, bind the policy you've created to the stage binding of the password stage.
|
||||
|
||||
Make sure to uncheck _Evaluate when flow is planned_ and check _Evaluate when stage is run_, otherwise an invalid result will be cached.
|
||||
113
website/docs/add-secure-apps/flows-stages/stages/prompt/index.md
Normal file
113
website/docs/add-secure-apps/flows-stages/stages/prompt/index.md
Normal file
@ -0,0 +1,113 @@
|
||||
---
|
||||
title: Prompt stage
|
||||
---
|
||||
|
||||
This stage is used to show the user arbitrary prompts.
|
||||
|
||||
## Prompt
|
||||
|
||||
The prompt can be any of the following types:
|
||||
|
||||
| Type | Description |
|
||||
| --------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| Text | Arbitrary text. No client-side validation is done. |
|
||||
| Text (Read only) | Same as above, but cannot be edited. |
|
||||
| Text Area | Arbitrary multiline text. No client-side validation is done. |
|
||||
| Text Area (Read only) | Same as above, but cannot be edited. |
|
||||
| Username | Same as text, except the username is validated to be unique. |
|
||||
| Email | Text input, ensures the value is an email address (validation is only done client-side). |
|
||||
| Password | Same as text, shown as a password field client-side, and custom validation (see below). |
|
||||
| Number | Numerical textbox. |
|
||||
| Checkbox | Simple checkbox. |
|
||||
| Radio Button Group | Similar to checkboxes, but allows selecting a value from a set of predefined values. |
|
||||
| Dropdown | A simple dropdown menu filled with predefined values. |
|
||||
| Date | Same as text, except the client renders a date-picker |
|
||||
| Date-time | Same as text, except the client renders a date-time-picker |
|
||||
| File | Allow users to upload a file, which will be available as base64-encoded data in the flow . |
|
||||
| Separator | Passive element to group surrounding elements |
|
||||
| Hidden | Hidden input field. Allows for the pre-setting of default values. |
|
||||
| Static | Display arbitrary value as is |
|
||||
| authentik: Locale | Display a list of all locales authentik supports. |
|
||||
|
||||
:::note
|
||||
`TextArea`, `TextArea (Read only)`, `Radio Button Group` and `Dropdown` options require authentik 2023.4+
|
||||
:::
|
||||
|
||||
Some types have special behaviors:
|
||||
|
||||
- _Username_: Input is validated against other usernames to ensure a unique value is provided.
|
||||
- _Password_: All prompts with the type password within the same stage are compared and must be equal. If they are not equal, an error is shown
|
||||
- _Hidden_ and _Static_: Their initial values are defaults and are not user-changeable.
|
||||
- _Radio Button Group_ and _Dropdown_: Only allow the user to select one of a set of predefined values.
|
||||
|
||||
A prompt has the following attributes:
|
||||
|
||||
### `field_key`
|
||||
|
||||
The field name used for the prompt. This key is also used to later retrieve the data in expression policies:
|
||||
|
||||
```python
|
||||
request.context.get('prompt_data').get('<field_key>')
|
||||
```
|
||||
|
||||
### `label`
|
||||
|
||||
The label used to describe the field. Depending on the selected template, this may not be shown.
|
||||
|
||||
### `required`
|
||||
|
||||
A flag which decides whether or not this field is required.
|
||||
|
||||
### `placeholder`
|
||||
|
||||
A field placeholder, shown within the input field.
|
||||
|
||||
By default, the placeholder is interpreted as-is. If you enable _Interpret placeholder as expression_, the placeholder
|
||||
will be evaluated as a Python expression. This happens in the same environment as [_Policies_](../../../../customize/policies/expression.mdx).
|
||||
|
||||
In the case of `Radio Button Group` and `Dropdown` prompts, this field defines all possible values (choices). When interpreted as-is, only one value will be allowed (the placeholder string). When interpreted as expression, a list of values can be returned to define multiple choices. For example, `return ["first option", 42, "another option"]` defines 3 possible values.
|
||||
|
||||
You can access both the HTTP request and the user as with a mapping. Additionally, you can access `prompt_context`, which is a dictionary of the current state of the prompt stage's data.
|
||||
|
||||
For `Radio Button Group` and `Dropdown` prompts, if a key with the same name as the prompt's `field_key` and a suffix of `__choices` (`<field_key>__choices`) is present in the `prompt_context` dictionary, its value will be returned directly, even if _Interpret placeholder as expression_ is enabled.
|
||||
|
||||
### `initial_value`
|
||||
|
||||
The prompt's initial value. It can also be left empty, in which case the field will not have a pre-filled value.
|
||||
|
||||
With the `hidden` prompt, the initial value will also be the actual value, because the field is hidden to the user.
|
||||
|
||||
By default, the initial value is interpreted as-is. If you enable _Interpret initial value as expression_, the initial value
|
||||
will be evaluated as a Python expression. This happens in the same environment as [_Policies_](../../../../customize/policies/expression.mdx).
|
||||
|
||||
In the case of `Radio Button Group` and `Dropdown` prompts, this field defines the default choice. When interpreted as-is, the default choice will be the initial value string. When interpreted as expression, the default choice will be the returned value. For example, `return 42` defines `42` as the default choice.
|
||||
|
||||
:::note
|
||||
The default choice defined for any fixed choice field **must** be one of the valid choices specified in the prompt's placeholder.
|
||||
:::
|
||||
|
||||
You can access both the HTTP request and the user as with a mapping. Additionally, you can access `prompt_context`, which is a dictionary of the current state of the prompt stage's data. If a key with the same name as the prompt's `field_key` is present in the `prompt_context` dictionary, its value will be returned directly, even if _Interpret initial value as expression_ is enabled.
|
||||
|
||||
### `order`
|
||||
|
||||
The numerical index of the prompt. This applies to all stages which this prompt is a part of.
|
||||
|
||||
# Validation
|
||||
|
||||
Further validation of prompts can be done using policies.
|
||||
|
||||
To validate that two password fields are identical, create the following expression policy:
|
||||
|
||||
```python
|
||||
if request.context.get('prompt_data').get('password') == request.context.get('prompt_data').get('password_repeat'):
|
||||
return True
|
||||
|
||||
ak_message("Passwords don't match.")
|
||||
return False
|
||||
```
|
||||
|
||||
This policy expects you to have two password fields with `field_key` set to `password` and `password_repeat`.
|
||||
|
||||
Afterwards, bind this policy to the prompt stage you want to validate.
|
||||
|
||||
Before 2021.12, any policy was required to pass for the result to be considered valid. This has been changed, and now all policies are required to be valid.
|
||||
@ -0,0 +1,57 @@
|
||||
---
|
||||
title: Source stage
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
<span class="badge badge--version">authentik 2024.4+</span>
|
||||
|
||||
---
|
||||
|
||||
The source stage injects an [OAuth](../../../../users-sources/sources/protocols/oauth/index.md) or [SAML](../../../../users-sources/sources/protocols/saml/index.md) Source into the flow execution. This allows for additional user verification, or to dynamically access different sources for different user identifiers (username, email address, etc).
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant u as User
|
||||
participant ak as authentik
|
||||
participant eidp as External IDP
|
||||
|
||||
u->>ak: User initiates flow
|
||||
ak->>u: User reaches Source Stage
|
||||
|
||||
u->>eidp: User is redirected to external IDP
|
||||
eidp->>ak: User has authenticated with external IDP
|
||||
|
||||
alt User is connected to external IDP (auth)
|
||||
ak->>u: Source's authentication flow is started
|
||||
u->>ak: User finishes source's authentication flow
|
||||
else User has not been connected to external IDP (enroll)
|
||||
ak->>u: Source's enrollment flow is started
|
||||
u->>ak: User finishes source's enrollment flow
|
||||
end
|
||||
|
||||
ak->>u: Execution of the previous flow is resumed
|
||||
```
|
||||
|
||||
### Considerations
|
||||
|
||||
It is very important that the configured source's authentication and enrollment flows (when set; they can be left unselected to prevent authentication or enrollment with the source) do **not** have a [User login stage](../user_login/index.md) bound to them.
|
||||
|
||||
This is because the Source stage works by appending a [dynamic in-memory](../../../../core/terminology.md#dynamic-in-memory-stage) stage to the source's flow, so having a [User login stage](../user_login/index.md) bound will cause the source's flow to not resume the original flow it was started from, and instead directly authenticating the pending user.
|
||||
|
||||
### Example use case
|
||||
|
||||
This stage can be used to leverage an external OAuth/SAML identity provider.
|
||||
|
||||
For example, you can authenticate users by routing them through a custom device-health solution.
|
||||
|
||||
Another use case is to route users to authenticate with your legacy (Okta, etc) IdP and then use the returned identity and attributes within authentik as part of an authorization flow, for example as part of an IdP migration. For authentication/enrollment this is also possible with an [OAuth](../../../../users-sources/sources/protocols/oauth/index.md)/[SAML](../../../../users-sources/sources/protocols/saml/index.md) source by itself.
|
||||
|
||||
### Options
|
||||
|
||||
#### Source
|
||||
|
||||
The source the user is redirected to. Must be a web-based source, such as [OAuth](../../../../users-sources/sources/protocols/oauth/index.md) or [SAML](../../../../users-sources/sources/protocols/saml/index.md). Sources like [LDAP](../../../../users-sources/sources/protocols/ldap/index.md) are _not_ compatible.
|
||||
|
||||
#### Resume timeout
|
||||
|
||||
Because the execution of the current flow is suspended before the user is redirected to the configured source, this option configures how long the suspended flow is saved. If this timeout is exceeded, upon return from the configured source, the suspended flow will restart from the beginning.
|
||||
@ -0,0 +1,11 @@
|
||||
---
|
||||
title: User delete stage
|
||||
---
|
||||
|
||||
:::danger
|
||||
This stage deletes the `pending_user` without any confirmation. You have to make sure the user is aware of this.
|
||||
:::
|
||||
|
||||
This stage is intended for an unenrollment flow. It deletes the currently pending user.
|
||||
|
||||
The pending user is also removed from the current session.
|
||||
@ -0,0 +1,84 @@
|
||||
---
|
||||
title: User login stage
|
||||
---
|
||||
|
||||
This stage attaches a currently pending user to the current session.
|
||||
|
||||
It can be used after `user_write` during an enrollment flow, or after a `password` stage during an authentication flow.
|
||||
|
||||
## User login stage configuration options
|
||||
|
||||
When creating or editing this stage in the UI of the Admin interface, you can set the following configuration options.
|
||||
|
||||
**Name**: enter a descriptive name for the stage.
|
||||
|
||||
**Stage-specific settings**
|
||||
|
||||
- **Session duration**: By default, the authentik session expires when you close your browser (_seconds=0_).
|
||||
|
||||
:::warning
|
||||
Different browsers handle session cookies differently, and might not remove them even when the browser is closed. See [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#expiresdate) for more info.
|
||||
:::
|
||||
|
||||
You can set the session to expire after any duration using the syntax of `hours=1,minutes=2,seconds=3`. The following keys are allowed:
|
||||
|
||||
- Microseconds
|
||||
- Milliseconds
|
||||
- Seconds
|
||||
- Minutes
|
||||
- Hours
|
||||
- Days
|
||||
- Weeks
|
||||
|
||||
All values accept floating-point values.
|
||||
|
||||
- **Stay signed in offset**: When this is set to a higher value than the default _seconds=0_, the user logging in is shown a prompt, allowing the user to choose if their session should be extended or not. The same syntax as for _Session duration_ applies.
|
||||
|
||||
|
||||
|
||||
- **Network binding and GeoIP binding**
|
||||
|
||||
When configured, all sessions authenticated by this stage will be bound to the selected network and/or GeoIP criteria.
|
||||
|
||||
Sessions that break this binding will be terminated on use. The created [`logout`](../../../../sys-mgmt/events/index.md#logout) event will contain additional data related to what caused the binding to be broken:
|
||||
|
||||
```json
|
||||
{
|
||||
"asn": {
|
||||
"asn": 6805,
|
||||
"as_org": "Telefonica Germany",
|
||||
"network": "5.4.0.0/14"
|
||||
},
|
||||
"geo": {
|
||||
"lat": 51.2993,
|
||||
"city": "",
|
||||
"long": 9.491,
|
||||
"country": "DE",
|
||||
"continent": "EU"
|
||||
},
|
||||
"binding": {
|
||||
"reason": "network.missing",
|
||||
"new_value": {
|
||||
"asn": 6805,
|
||||
"as_org": "Telefonica Germany",
|
||||
"network": "5.4.0.0/14"
|
||||
},
|
||||
"previous_value": {}
|
||||
},
|
||||
"ip": {
|
||||
"previous": "1.2.3.4",
|
||||
"new": "5.6.7.8"
|
||||
},
|
||||
"http_request": {
|
||||
"args": {},
|
||||
"path": "/if/admin/",
|
||||
"method": "GET",
|
||||
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
|
||||
},
|
||||
"logout_reason": "Session binding broken"
|
||||
}
|
||||
```
|
||||
|
||||
- **Terminate other sessions**
|
||||
|
||||
When enabled, previous sessions of the user logging in will be revoked. This has no affect on OAuth refresh tokens.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
@ -0,0 +1,5 @@
|
||||
---
|
||||
title: User logout stage
|
||||
---
|
||||
|
||||
Opposite stage of [User Login Stages](./user_login/index.md). It removes the user from the current session.
|
||||
@ -0,0 +1,27 @@
|
||||
---
|
||||
title: User write stage
|
||||
---
|
||||
|
||||
This stages writes data from the current flow context to a user.
|
||||
|
||||
Newly created users can be created as inactive and can be assigned to a selected group.
|
||||
|
||||
### Dynamic groups
|
||||
|
||||
Starting with authentik 2022.5, users can be added to dynamic groups. To do so, simply set `groups` in the flow plan context before this stage is run, for example
|
||||
|
||||
```python
|
||||
from authentik.core.models import Group
|
||||
group, _ = Group.objects.get_or_create(name="some-group")
|
||||
# ["groups"] *must* be set to an array of Group objects, names alone are not enough.
|
||||
request.context["flow_plan"].context["groups"] = [group]
|
||||
return True
|
||||
```
|
||||
|
||||
### User creation
|
||||
|
||||
By default, this stage will create a new user when none is present in the flow context.
|
||||
|
||||
Starting with authentik 2022.12, the stage can by default not create new users to prevent users from creating new accounts without authorization.
|
||||
|
||||
Starting with authentik 2023.1, this option has been expanded to allow user creation, forbid it or force user creation.
|
||||
94
website/docs/add-secure-apps/outposts/_config.md
Normal file
94
website/docs/add-secure-apps/outposts/_config.md
Normal file
@ -0,0 +1,94 @@
|
||||
```yaml
|
||||
# Log level that the outpost will set
|
||||
# Allowed levels: trace, debug, info, warning, error
|
||||
# Applies to: non-embedded
|
||||
log_level: debug
|
||||
# Interval at which the outpost will refresh the providers
|
||||
# from authentik. For caching outposts (such as LDAP), the
|
||||
# cache will also be invalidated at that interval.
|
||||
# (Format: hours=1;minutes=2;seconds=3).
|
||||
refresh_interval: minutes=5
|
||||
########################################
|
||||
# The settings below are only relevant when using a managed outpost
|
||||
########################################
|
||||
# URL that the outpost uses to connect back to authentik
|
||||
authentik_host: https://authentik.tld/
|
||||
# Disable SSL Validation for the authentik connection
|
||||
authentik_host_insecure: false
|
||||
# Optionally specify a different URL used for user-facing interactions
|
||||
# Applies to: proxy outposts
|
||||
authentik_host_browser:
|
||||
# Template used for objects created (deployments/containers, services, secrets, etc)
|
||||
object_naming_template: ak-outpost-%(name)s
|
||||
# Use a specific docker image for this outpost rather than the default. This also applies to Kubernetes
|
||||
# outposts.
|
||||
# Applies to: non-embedded
|
||||
container_image:
|
||||
########################################
|
||||
# Docker outpost specific settings
|
||||
########################################
|
||||
# Network the outpost container should be connected to
|
||||
# Applies to: non-embedded
|
||||
docker_network: null
|
||||
# Optionally disable mapping of ports to outpost container, may be useful when using docker networks
|
||||
# (Available with 2021.9.4+)
|
||||
# Applies to: non-embedded
|
||||
docker_map_ports: true
|
||||
# Optionally additional labels for docker containers
|
||||
# (Available with 2022.1.2)
|
||||
# Applies to: non-embedded
|
||||
docker_labels: null
|
||||
########################################
|
||||
# Kubernetes outpost specific settings
|
||||
########################################
|
||||
# Replica count for the deployment of the outpost
|
||||
# Applies to: non-embedded
|
||||
kubernetes_replicas: 1
|
||||
# Namespace to deploy in, defaults to the same namespace authentik is deployed in (if available)
|
||||
kubernetes_namespace: authentik
|
||||
# Any additional annotations to add to the ingress object, for example cert-manager
|
||||
kubernetes_ingress_annotations: {}
|
||||
# Name of the secret that is used for TLS connections, leave empty to disable TLS
|
||||
kubernetes_ingress_secret_name: authentik-outpost-tls
|
||||
# Service kind created, can be set to LoadBalancer for LDAP outposts for example
|
||||
kubernetes_service_type: ClusterIP
|
||||
# Disable any components of the kubernetes integration, can be any of
|
||||
# - 'secret'
|
||||
# - 'deployment'
|
||||
# - 'service'
|
||||
# - 'prometheus servicemonitor'
|
||||
# - 'ingress'
|
||||
# - 'traefik middleware'
|
||||
kubernetes_disabled_components: []
|
||||
# If the above docker image is in a private repository, use these secrets to pull.
|
||||
# NOTE: The secret must be created manually in the namespace first.
|
||||
# Applies to: non-embedded
|
||||
kubernetes_image_pull_secrets: []
|
||||
# Optionally configure an ingress class name. If not set, the ingress will use the cluster's
|
||||
# default ingress class
|
||||
# (Available with 2022.11.0+)
|
||||
# Applies to: proxy outposts
|
||||
kubernetes_ingress_class_name: null
|
||||
# Optionally apply an RFC 6902 compliant patch to the Kubernetes objects.
|
||||
# For an understanding of how this works, refer to the link below:
|
||||
# https://github.com/kubernetes-sigs/kustomize/blob/master/examples/jsonpatch.md
|
||||
#
|
||||
# This value expects a mapping where the key represents
|
||||
# the Kubernetes component that shall be patched.
|
||||
# It can be any of the same values supported by `kubernetes_disabled_components`.
|
||||
#
|
||||
# For example use this patch to add custom resource requests and limits
|
||||
# to the outpost deployment:
|
||||
#
|
||||
# deployment:
|
||||
# - op: add
|
||||
# path: "/spec/template/spec/containers/0/resources"
|
||||
# value:
|
||||
# requests:
|
||||
# cpu: 2000m
|
||||
# memory: 2000Mi
|
||||
# limits:
|
||||
# cpu: 4000m
|
||||
# memory: 8000Mi
|
||||
kubernetes_json_patches: null
|
||||
```
|
||||
47
website/docs/add-secure-apps/outposts/embedded/embedded.mdx
Normal file
47
website/docs/add-secure-apps/outposts/embedded/embedded.mdx
Normal file
@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Embedded Outpost
|
||||
---
|
||||
|
||||
Starting with 2021.8.1, authentik comes with an embedded outpost. This has been added to simplify deployment for users using the Proxy provider.
|
||||
|
||||
The embedded outpost runs in the main `server` container, and is managed by authentik itself. The embedded outpost authenticates itself via the secret key.
|
||||
|
||||
You can access the embedded outpost on the same ports as authentik itself, 9000 and 9443.
|
||||
|
||||
If the embedded outpost doesn't make sense for your deployment, you can simply ignore it.
|
||||
|
||||
### Configuration
|
||||
|
||||
Since authentik doesn't know it's own "primary" URL, there might be some configuration required.
|
||||
|
||||
By default, when opening the admin dashboard on a fresh install, authentik will automatically configure the outpost to use the same URL as was used to access authentik.
|
||||
|
||||
If this isn't correct, or needs to be changed, click the edit button on the right of the outpost, and set the value of `authentik_host` to the URL you want to login with.
|
||||
Make sure to set it to full URL, only configuring a hostname or FQDN will not work.
|
||||
|
||||
Additionally, most of the other configuration options can be used as with any other outpost, except from items which are marked as "non-embedded"
|
||||
|
||||
import Configuration from "../_config.md";
|
||||
|
||||
<Configuration />
|
||||
|
||||
### Routing
|
||||
|
||||
Routing is handled like this:
|
||||
|
||||
1. Paths starting with `/static`, `/media` and `/help` return packaged CSS/JS files, and user-uploaded media files.
|
||||
2. Paths starting with `/outpost.goauthentik.io` are sent to the embedded outpost.
|
||||
3. Any hosts configured in the providers assigned to the embedded outpost are sent to the outpost.
|
||||
4. Everything remaining is sent to the authentik backend server.
|
||||
|
||||
### Differences
|
||||
|
||||
There are a few more differences between managed outposts and the embedded outpost, mainly due to the fact that authentik can't fully manage the containers.
|
||||
|
||||
1. (Docker-only) No automatic traefik labels are added to the server container.
|
||||
|
||||
When you deploy a managed outpost on docker, the container has several labels to automatically configure traefik. This is not done for the embedded outpost.
|
||||
|
||||
2. (Kubernetes-only) An additional service is created.
|
||||
|
||||
Since authentik does not know what the normal authentik Service is called, another one is created with a common set of labels that is always set.
|
||||
68
website/docs/add-secure-apps/outposts/index.mdx
Normal file
68
website/docs/add-secure-apps/outposts/index.mdx
Normal file
@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Outposts
|
||||
---
|
||||
|
||||
An outpost is a single deployment of an authentik component, essentially a service, that can be deployed anywhere that allows for a connection to the authentik API.
|
||||
|
||||
An outpost is required if you use any of the following types of providers with your application:
|
||||
|
||||
- [LDAP Provider](../providers/ldap/index.md)
|
||||
- [Proxy Provider](../providers/proxy/index.md)
|
||||
- [RADIUS Provider](../providers/radius/index.mdx)
|
||||
- [RAC Provider](../providers/rac/index.md)
|
||||
|
||||
These types of providers use an outpost for increased flexibility and speed. Instead of the provider logic being implemented in authentik Core, these providers use an outpost to handle the logic, which provides improved performance.
|
||||
|
||||
An additional advantage of using an outpost is that outposts, like authentik itself, do not require access to the wider internet. Transactions between the application, the provider, and the outpost occur via the authentik API, and support single sign-on operations in firewalled or airgapped deployments and offline connections to remote machines that are not on the internet.
|
||||
|
||||
An outpost is given permissions to access the authentik API using a service account and token, both of which are auto-generated when you create a new outpost. The outpost is granted rights to only the application/provider pairs configured (and other necessary related objects such as certificates).
|
||||
|
||||
Any change made to the outpost's associated app or provider immediately triggers an event to update the configuration data stored on the outpost, via websockets. Websockets are used also by the outpost to send healthchecks to the authentik Core.
|
||||
|
||||
## Create and configure an outpost
|
||||
|
||||
1. To create a new outpost, log in to authentik as an administrator, and open to the Admin interface.
|
||||
|
||||
2. Navigate to **Applications --> Outposts** and then click **Create**.
|
||||
|
||||
|
||||
|
||||
3. Define the following values:
|
||||
|
||||
- **Name**: a name for the new outpost
|
||||
- **Type**: select the provider type (Proxy, LDAP, Radius, RAC)
|
||||
- **Integration** (_optional_): select either your [Docker or Kubernetes connection](#more-about-outpost-integrations)
|
||||
- **Applications**: select the applications that you want the outpost to serve
|
||||
- **Advanced settings** (*optional*): For further optional configuration settings, refer to [Configuration](#configuration) below.
|
||||
|
||||
4. Click **Create** to save your new outpost settings and close the modal.
|
||||
|
||||
Upon creation, a service account and a token is generated. The service account only has permissions to read the outpost and provider configuration. This token is used by the outpost to connect to authentik.
|
||||
|
||||
### More about outpost integrations
|
||||
|
||||
authentik can manage the deployment, updating, and general lifecycle of an outpost. To communicate with the underlying platforms on which the outpost is deployed, authentik has several built-in integrations.
|
||||
|
||||
- If you've deployed authentik on Docker Compose, authentik automatically creates an integration for the local docker socket (See [Docker](./integrations/docker.md)).
|
||||
- If you've deployed authentik on Kubernetes, with `kubernetesIntegration` set to true (default), authentik automatically creates an integrations for the local Kubernetes Cluster (see [Kubernetes](./integrations/kubernetes.md)).
|
||||
|
||||
To deploy an outpost with these integrations, select them during the creation of an outpost. A background task is started, which creates the container/deployment. The outpost deployment can be monitored from the **Dashboards -> System Tasks** page in the Admin interface.
|
||||
|
||||
To deploy an outpost manually, see:
|
||||
|
||||
- [Kubernetes](./manual-deploy-kubernetes.md)
|
||||
- [Docker Compose](./manual-deploy-docker-compose.md)
|
||||
|
||||
### Configuration
|
||||
|
||||
Outposts fetch their configuration from authentik. Below are all the options you can set, and how they influence the outpost.
|
||||
|
||||
import Configuration from "./_config.md";
|
||||
|
||||
<Configuration />
|
||||
|
||||
## Prometheus Metrics
|
||||
|
||||
Each authentik outpost has a Prometheus metrics endpoint accessible under port `:9300/metrics`. This endpoint is not mapped via Docker, as the endpoint doesn't have any authentication.
|
||||
|
||||
For the embedded outpost, the metrics of the outpost and the metrics of the core authentik server are both returned under the same endpoint.
|
||||
80
website/docs/add-secure-apps/outposts/integrations/docker.md
Normal file
80
website/docs/add-secure-apps/outposts/integrations/docker.md
Normal file
@ -0,0 +1,80 @@
|
||||
---
|
||||
title: Docker
|
||||
---
|
||||
|
||||
The Docker integration automatically deploys and manages outpost containers using the Docker HTTP API.
|
||||
|
||||
This integration has the advantage over manual deployments of automatic updates (whenever authentik is updated, it updates the outposts), and authentik can (in a future version) automatically rotate the token that the outpost uses to communicate with the core authentik server.
|
||||
|
||||
The following outpost settings are used:
|
||||
|
||||
- `object_naming_template`: Configures how the container is called
|
||||
- `container_image`: Optionally overwrites the standard container image (see [Configuration](../../../install-config/configuration/configuration.mdx#authentik_outposts) to configure the global default)
|
||||
- `docker_network`: The Docker network the container should be added to. This needs to be modified if you plan to connect to authentik using the internal hostname.
|
||||
- `docker_map_ports`: Enable/disable the mapping of ports. When using a proxy outpost with Traefik for example, you might not want to bind ports as they are routed through Traefik.
|
||||
- `docker_labels`: Optional additional labels that can be applied to the container.
|
||||
|
||||
The container is created with the following hardcoded properties:
|
||||
|
||||
- Labels
|
||||
|
||||
- `io.goauthentik.outpost-uuid`: Used by authentik to identify the container, and to allow for name changes.
|
||||
|
||||
Additionally, the proxy outposts have the following extra labels to add themselves into Traefik automatically.
|
||||
|
||||
- `traefik.enable`: "true"
|
||||
- `traefik.http.routers.ak-outpost-<outpost-name>-router.rule`: `Host(...)`
|
||||
- `traefik.http.routers.ak-outpost-<outpost-name>-router.service`: `ak-outpost-<outpost-name>-service`
|
||||
- `traefik.http.routers.ak-outpost-<outpost-name>-router.tls`: "true"
|
||||
- `traefik.http.services.ak-outpost-<outpost-name>-service.loadbalancer.healthcheck.path`: "/outpost.goauthentik.io/ping"
|
||||
- `traefik.http.services.ak-outpost-<outpost-name>-service.loadbalancer.healthcheck.port`: "9300"
|
||||
- `traefik.http.services.ak-outpost-<outpost-name>-service.loadbalancer.server.port`: "9000"
|
||||
|
||||
## Permissions
|
||||
|
||||
To minimise the potential risks of mapping the Docker socket into a container/giving an application access to the Docker API, many people use Projects like [docker-socket-proxy](https://github.com/Tecnativa/docker-socket-proxy). authentik requires these permissions from the Docker API:
|
||||
|
||||
- Images/Pull: authentik tries to pre-pull the custom image if one is configured, otherwise falling back to the default image.
|
||||
- Containers/Read: Gather infos about currently running container
|
||||
- Containers/Create: Create new containers
|
||||
- Containers/Kill: Cleanup during upgrades
|
||||
- Containers/Remove: Removal of outposts
|
||||
|
||||
## Remote hosts (TLS)
|
||||
|
||||
To connect remote hosts, follow this guide from Docker [Use TLS (HTTPS) to protect the Docker daemon socket](https://docs.docker.com/engine/security/protect-access/#use-tls-https-to-protect-the-docker-daemon-socket) to configure Docker.
|
||||
|
||||
Afterwards, create two certificate-keypairs in authentik:
|
||||
|
||||
- `Docker CA`, with the contents of `~/.docker/ca.pem` as Certificate
|
||||
- `Docker Cert`, with the contents of `~/.docker/cert.pem` as the certificate and `~/.docker/key.pem` as the private key.
|
||||
|
||||
Create an integration with `Docker CA` as _TLS Verification Certificate_ and `Docker Cert` as _TLS Authentication Certificate_.
|
||||
|
||||
## Remote hosts (SSH)
|
||||
|
||||
Starting with authentik 2021.12.5, you can connect to remote Docker hosts using SSH. To configure this, create a new SSH keypair using these commands:
|
||||
|
||||
```
|
||||
# Generate the keypair itself, using RSA keys in the PEM format
|
||||
ssh-keygen -t rsa -f authentik -N "" -m pem
|
||||
# Generate a certificate from the private key, required by authentik.
|
||||
# The values that openssl prompts you for are not relevant
|
||||
openssl req -x509 -sha256 -nodes -days 365 -out certificate.pem -key authentik
|
||||
```
|
||||
|
||||
You'll end up with three files:
|
||||
|
||||
- `authentik.pub` is the public key, this should be added to the `~/.ssh/authorized_keys` file on the target host and user.
|
||||
- `authentik` is the private key, which should be imported into a Keypair in authentik.
|
||||
- `certificate.pem` is the matching certificate for the keypair above.
|
||||
|
||||
Modify/create a new Docker integration, and set your _Docker URL_ to `ssh://hostname`, and select the keypair you created above as _TLS Authentication Certificate/SSH Keypair_.
|
||||
|
||||
The _Docker URL_ field include a user, if none is specified authentik connects with the user `authentik`.
|
||||
|
||||
#### Advanced SSH config
|
||||
|
||||
With the above configuration, authentik will create and manage an `~/.ssh/config` file. If you need advanced configuration, for example SSH Certificates, you can mount a custom SSH Config file.
|
||||
|
||||
Mount the config file into `/authentik/.ssh/config`, and mount any other relevant files into a directory under `/opt`. Afterwards, create an integration using `ssh://hostname`, and don't select a keypair.
|
||||
@ -0,0 +1,46 @@
|
||||
---
|
||||
title: Kubernetes
|
||||
---
|
||||
|
||||
The kubernetes integration will automatically deploy outposts on any Kubernetes Cluster.
|
||||
|
||||
This integration has the advantage over manual deployments of automatic updates (whenever authentik is updated, it updates the outposts), and authentik can (in a future version) automatically rotate the token that the outpost uses to communicate with the core authentik server.
|
||||
|
||||
This integration creates the following objects:
|
||||
|
||||
- Deployment for the outpost container
|
||||
- Service
|
||||
- Secret to store the token
|
||||
- Prometheus ServiceMonitor (if the Prometheus Operator is installed in the target cluster)
|
||||
- Ingress (only Proxy outposts)
|
||||
- Traefik Middleware (only Proxy outposts with forward auth enabled)
|
||||
|
||||
The following outpost settings are used:
|
||||
|
||||
- `object_naming_template`: Configures how the container is called
|
||||
- `container_image`: Optionally overwrites the standard container image (see [Configuration](../../../install-config/configuration/configuration.mdx) to configure the global default)
|
||||
- `kubernetes_replicas`: Replica count for the deployment of the outpost
|
||||
- `kubernetes_namespace`: Namespace to deploy in, defaults to the same namespace authentik is deployed in (if available)
|
||||
- `kubernetes_ingress_annotations`: Any additional annotations to add to the ingress object, for example cert-manager
|
||||
- `kubernetes_ingress_secret_name`: Name of the secret that is used for TLS connections, can be empty to disable TLS config
|
||||
- `kubernetes_ingress_class_name`: Optionally set the ingress class used for the generated ingress, requires authentik 2022.11.0
|
||||
- `kubernetes_service_type`: Service kind created, can be set to LoadBalancer for LDAP outposts for example
|
||||
- `kubernetes_disabled_components`: Disable any components of the kubernetes integration, can be any of
|
||||
- 'secret'
|
||||
- 'deployment'
|
||||
- 'service'
|
||||
- 'prometheus servicemonitor'
|
||||
- 'ingress'
|
||||
- 'traefik middleware'
|
||||
- `kubernetes_image_pull_secrets`: If the above docker image is in a private repository, use these secrets to pull. (NOTE: The secret must be created manually in the namespace first.)
|
||||
- `kubernetes_json_patches`: Applies an RFC 6902 compliant JSON patch to the Kubernetes objects.
|
||||
|
||||
## Permissions
|
||||
|
||||
The permissions required for this integration are documented in the helm chart. See [Cluster-level](https://github.com/goauthentik/helm/blob/main/charts/authentik-remote-cluster/templates/clusterrolebinding.yaml) and [Namespace-level](https://github.com/goauthentik/helm/blob/main/charts/authentik-remote-cluster/templates/rolebinding.yaml).
|
||||
|
||||
## Remote clusters
|
||||
|
||||
To add a remote cluster, you can simply install this helm chart in the target cluster and namespace: https://artifacthub.io/packages/helm/goauthentik/authentik-remote-cluster
|
||||
|
||||
After installation, the helm chart outputs an example kubeconfig file, that you can enter in authentik to connect to the cluster.
|
||||
@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Manual Outpost deployment in docker-compose
|
||||
---
|
||||
|
||||
To deploy an outpost with docker-compose, use this snippet in your docker-compose file.
|
||||
|
||||
You can also run the outpost in a separate docker-compose project, you just have to ensure that the outpost container can reach your application container.
|
||||
|
||||
### Proxy outpost
|
||||
|
||||
```yaml
|
||||
services:
|
||||
authentik_proxy:
|
||||
image: ghcr.io/goauthentik/proxy
|
||||
# Optionally specify which networks the container should be
|
||||
# might be needed to reach the core authentik server
|
||||
# networks:
|
||||
# - foo
|
||||
ports:
|
||||
- 9000:9000
|
||||
- 9443:9443
|
||||
environment:
|
||||
AUTHENTIK_HOST: https://your-authentik.tld
|
||||
AUTHENTIK_INSECURE: "false"
|
||||
AUTHENTIK_TOKEN: token-generated-by-authentik
|
||||
# Starting with 2021.9, you can optionally set this too
|
||||
# when authentik_host for internal communication doesn't match the public URL
|
||||
# AUTHENTIK_HOST_BROWSER: https://external-domain.tld
|
||||
```
|
||||
|
||||
### LDAP outpost
|
||||
|
||||
```yaml
|
||||
services:
|
||||
authentik_ldap:
|
||||
image: ghcr.io/goauthentik/ldap
|
||||
# Optionally specify which networks the container should be
|
||||
# might be needed to reach the core authentik server
|
||||
# networks:
|
||||
# - foo
|
||||
ports:
|
||||
- 389:3389
|
||||
- 636:6636
|
||||
environment:
|
||||
AUTHENTIK_HOST: https://your-authentik.tld
|
||||
AUTHENTIK_INSECURE: "false"
|
||||
AUTHENTIK_TOKEN: token-generated-by-authentik
|
||||
```
|
||||
|
||||
### RADIUS outpost
|
||||
|
||||
```yaml
|
||||
services:
|
||||
radius_outpost:
|
||||
image: ghcr.io/goauthentik/radius
|
||||
# Optionally specify which networks the container should be
|
||||
# might be needed to reach the core authentik server
|
||||
# networks:
|
||||
# - foo
|
||||
ports:
|
||||
- 1812:1812/udp
|
||||
environment:
|
||||
AUTHENTIK_HOST: https://your-authentik.tld
|
||||
AUTHENTIK_INSECURE: "false"
|
||||
AUTHENTIK_TOKEN: token-generated-by-authentik
|
||||
```
|
||||
@ -0,0 +1,126 @@
|
||||
---
|
||||
title: Manual Outpost deployment on Kubernetes
|
||||
---
|
||||
|
||||
Use the following manifest, replacing all values surrounded with `__`.
|
||||
|
||||
Afterwards, configure the proxy provider to connect to `<service name>.<namespace>.svc.cluster.local`, and update your Ingress to connect to the `authentik-outpost` service.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-proxy
|
||||
app.kubernetes.io/version: 2021.12.3
|
||||
name: authentik-outpost-api
|
||||
stringData:
|
||||
authentik_host: "__AUTHENTIK_URL__"
|
||||
authentik_host_insecure: "true"
|
||||
token: "__AUTHENTIK_TOKEN__"
|
||||
type: Opaque
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-proxy
|
||||
app.kubernetes.io/version: 2021.12.3
|
||||
name: authentik-outpost
|
||||
spec:
|
||||
ports:
|
||||
- name: http
|
||||
port: 9000
|
||||
protocol: TCP
|
||||
targetPort: http
|
||||
- name: https
|
||||
port: 9443
|
||||
protocol: TCP
|
||||
targetPort: https
|
||||
type: ClusterIP
|
||||
selector:
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-outpost
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-proxy
|
||||
app.kubernetes.io/version: 2021.12.3
|
||||
name: authentik-outpost
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-proxy
|
||||
app.kubernetes.io/version: 2021.12.3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-proxy
|
||||
app.kubernetes.io/version: 2021.12.3
|
||||
spec:
|
||||
containers:
|
||||
- env:
|
||||
- name: AUTHENTIK_HOST
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
key: authentik_host
|
||||
name: authentik-outpost-api
|
||||
- name: AUTHENTIK_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
key: token
|
||||
name: authentik-outpost-api
|
||||
- name: AUTHENTIK_INSECURE
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
key: authentik_host_insecure
|
||||
name: authentik-outpost-api
|
||||
image: ghcr.io/goauthentik/proxy
|
||||
name: proxy
|
||||
ports:
|
||||
- containerPort: 9000
|
||||
name: http
|
||||
protocol: TCP
|
||||
- containerPort: 9443
|
||||
name: https
|
||||
protocol: TCP
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
annotations:
|
||||
nginx.ingress.kubernetes.io/affinity: cookie
|
||||
nginx.ingress.kubernetes.io/proxy-buffer-size: 16k
|
||||
nginx.ingress.kubernetes.io/proxy-buffers-number: "4"
|
||||
traefik.ingress.kubernetes.io/affinity: "true"
|
||||
labels:
|
||||
app.kubernetes.io/instance: __OUTPOST_NAME__
|
||||
app.kubernetes.io/managed-by: goauthentik.io
|
||||
app.kubernetes.io/name: authentik-proxy
|
||||
app.kubernetes.io/version: 2021.12.3
|
||||
name: authentik-outpost
|
||||
spec:
|
||||
rules:
|
||||
- host: __EXTERNAL_HOSTNAME__
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
service:
|
||||
name: authentik-outpost
|
||||
port:
|
||||
name: http
|
||||
path: /
|
||||
```
|
||||
BIN
website/docs/add-secure-apps/outposts/outpost-create.png
Normal file
BIN
website/docs/add-secure-apps/outposts/outpost-create.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 131 KiB |
11
website/docs/add-secure-apps/outposts/upgrading.md
Normal file
11
website/docs/add-secure-apps/outposts/upgrading.md
Normal file
@ -0,0 +1,11 @@
|
||||
---
|
||||
title: Upgrading an Outpost
|
||||
---
|
||||
|
||||
In the Outpost Overview list, you'll see if any deployed outposts are out of date.
|
||||
|
||||
|
||||
|
||||
To upgrade the Outpost to the latest version, simply adjust the docker tag of the outpost to the new version.
|
||||
|
||||
Since the configuration is managed by authentik, that's all you have to do.
|
||||
BIN
website/docs/add-secure-apps/outposts/upgrading_outdated.png
Normal file
BIN
website/docs/add-secure-apps/outposts/upgrading_outdated.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Add an Entra ID provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
---
|
||||
|
||||
For more information about using an Entra ID provider, see the [Overview](./index.md) documentation.
|
||||
|
||||
:::info
|
||||
This feature is in technical preview, so please report any bugs on [GitHub](https://github.com/goauthentik/authentik/issues).
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To create an Entra ID provider provider in authentik, you must have already [configured Entra ID](./setup-entra.md) to integrate with authentik. You will need to obtain from Entra three values: the Application (client) ID, the Directory (tenant) ID, and the Client secret. When adding an Entra ID provider in authentik, you must provide these values.
|
||||
|
||||
:::info
|
||||
As detailed in the steps below, when you add an Entra ID provider in authentik you must define the **Backchannel provider** using the name of the Entra ID provider that you created in authentik. If you have also configured Entra ID to log in using authentik, then this configuration can be done on the same app.
|
||||
:::
|
||||
|
||||
### Create the Entra ID provider in authentik
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
2. In the Admin interface, navigate to **Applications -> Providers**.
|
||||
3. Click **Create**, and in the **New provider** modal box select **Microsoft Entra Provider** as the type and click **Next**.
|
||||
4. Define the following fields:
|
||||
|
||||
- **Name**: define a descriptive name, such as "Entra provider".
|
||||
|
||||
- **Protocol settings**
|
||||
|
||||
- **Client ID**: enter the Client ID that you [copied from your Entra app](./setup-entra.md).
|
||||
- **Client Secret**: enter the secret from Entra.
|
||||
- **Tenant ID**: enter the Tenant ID from Entra.
|
||||
- **User deletion action**: determines what authentik will do when a user is deleted from the Entra ID system.
|
||||
- **Group deletion action**: determines what authentik will do when a group is deleted from the Entra ID system.
|
||||
|
||||
**User filtering**
|
||||
|
||||
- **Exclude service accounts**: set whether to include or exclude service accounts.
|
||||
- **Group**: select any specific groups to enforce that filtering (for all actions) is done only for the selected groups.
|
||||
|
||||
**Attribute mapping**
|
||||
|
||||
- **User Property Mappings**: select any applicable mappings, or use the default.
|
||||
- **Group Property Mappings**: select any applicable mappings, or use the default.
|
||||
|
||||
5. Click **Finish**.
|
||||
|
||||
### Create an Entra ID application in authentik
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
2. In the Admin interface, navigate to **Applications -> Applications**.
|
||||
3. Click **Create**, and in the **Create Application** modal box define the following fields:
|
||||
|
||||
- **Name**: provide a descriptive name.
|
||||
- **Slug**: enter the name of the app as you want it to appear in the URL.
|
||||
- **Group**: optionally, chose a group; apps in the same group are displayed together on the **My applications** page.
|
||||
- **Provider**: when _not_ used in conjunction with the Entra ID SAML configuration this field should be left empty.
|
||||
- **Backchannel Providers**: this field is required for Entra ID. Select the name of the Entra ID provider that you created in the steps above.
|
||||
- **Policy engine mode**: select **any** or **all** to set your policy mode.
|
||||
- **UI settings**: leave these fields empty for Entra ID.
|
||||
|
||||
4. Click **Create**.
|
||||
50
website/docs/add-secure-apps/providers/entra/index.md
Normal file
50
website/docs/add-secure-apps/providers/entra/index.md
Normal file
@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Microsoft Entra ID provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
---
|
||||
|
||||
:::info
|
||||
This feature is in technical preview, so please report any bugs on [GitHub](https://github.com/goauthentik/authentik/issues).
|
||||
:::
|
||||
|
||||
With the Microsoft Entra ID provider, authentik serves as the single source of truth for all users and groups. Configuring Entra ID as a provider allows for auto-discovery of user and group accounts, on-going synchronization of user data such as email address, name, and status, and integrated data mapping of field names and values.
|
||||
|
||||
- For instructions to configure your Entra ID tenant to integrate with authentik, refer to [Configure Entra ID](./setup-entra.md).
|
||||
- For instructions to add Entra ID as a provider in authentik, refer to [Create a Entra ID provider](./add-entra-provider.md).
|
||||
|
||||
## About using Entra ID with authentik
|
||||
|
||||
The following sections discuss how Entra ID operates with authentik.
|
||||
|
||||
### Discovery
|
||||
|
||||
When first creating and configuring the provider, authentik will run a discovery process and query your Entra ID for all users and groups, and attempt to match them with their respective counterparts in authentik. This discovery takes into consideration any **User filtering** options configured in the provider, such as only linking to authentik users in a specific group or excluding service accounts.
|
||||
|
||||
This discovery happens every time before a full sync is started.
|
||||
|
||||
### Synchronization
|
||||
|
||||
There are two types of synchronization: a direct sync and a full sync.
|
||||
|
||||
A _direct sync_ happens when a user or group is created, updated or deleted in authentik, or when a user is added to or removed from a group. When one of these events happens, the direct sync automatically forwards those changes to Entra ID.
|
||||
|
||||
The _full sync_ happens when the provider is initially created and when it is saved. The full sync goes through all users and groups matching the **User filtering** options set and will create/update them in Entra ID. After the initial sync, authentik will run a full sync every four hours to ensure the consistency of users and groups.
|
||||
|
||||
During either sync, if a user or group was created in authentik and a matching user/group exists in Entra ID, authentik will automatically link them together. Furthermore, users present in authentik but not in Entra ID will be created and and linked.
|
||||
|
||||
When a property mapping has an invalid expression, it will cause the sync to stop to prevent errors from being spammed. To handle any kind of network interruptions, authentik will detect transient request failures and retry any sync tasks.
|
||||
|
||||
### Customization for data mapping
|
||||
|
||||
There are a couple of considerations in regard to how authentik data is mapped to Entra ID user/group data by default.
|
||||
|
||||
- For users, authentik only saves the full display name, not separate first and family names.
|
||||
- By default, authentik synchs a user’s email, a user’s name, and their active status between Entra ID and authentik. For groups, the name is synced.
|
||||
|
||||
Refer to Microsoft documentation for further details.
|
||||
|
||||
- https://learn.microsoft.com/en-us/graph/api/user-post-users?view=graph-rest-1.0&tabs=http#request-body
|
||||
- https://learn.microsoft.com/en-us/graph/api/group-post-groups?view=graph-rest-1.0&tabs=http#request-body
|
||||
31
website/docs/add-secure-apps/providers/entra/setup-entra.md
Normal file
31
website/docs/add-secure-apps/providers/entra/setup-entra.md
Normal file
@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Configure Entra ID
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
---
|
||||
|
||||
The configuration of your Microsoft Entra ID environment must be completed before you [add the new provider](./add-entra-provider.md) in authentik.
|
||||
|
||||
For detailed instructions, refer to Microsoft Entra ID documentation.
|
||||
|
||||
## Configure Entra ID
|
||||
|
||||
1. Log into the Azure portal and on the Home page, under Azure services, click on or search for **App registrations**.
|
||||
2. On the **App registrations** page, click **New registration**.
|
||||
3. On the **Register an application** page, define the **Name** of the app, and under **Supported account types** select **Accounts in this organizational directory only**. Leave **Redirect URI** empty.
|
||||
4. Click **Register**.
|
||||
The app's detail page displays.
|
||||
5. On the app detail page, copy both the **Application (client) ID** and the **Directory (tenant) ID** values and store in a temporary place. These values will be needed when you [create the Entra ID provider](./add-entra-provider.md) in authentik.
|
||||
6. Next, click on **Certificates and Secrets** in the near-left navigation pane and create a new secret.
|
||||
7. On the **Certificates and Secrets** page, on the **Client secrets** tab, copy the **Value** of the secret and store it in a temporary place. Like with the client ID and the tenant ID, this secret will be needed when you [create the Entra ID provider](./add-entra-provider.md) in authentik.
|
||||
8. Next, click on **API permissions** in the near-left navigation pane.
|
||||
9. Click on **Add a permission** and add the following permissions by selecting **Microsoft Graph** and then **Application Permissions**:
|
||||
- `Group.Create`
|
||||
- `Group.ReadWrite.All`
|
||||
- `GroupMember.ReadWrite.All`
|
||||
- `User.Read`
|
||||
- `User.ReadWrite.All`
|
||||
|
||||
Now you are ready to [add Entra ID as a provider](./add-entra-provider.md) in authentik.
|
||||
@ -0,0 +1,67 @@
|
||||
---
|
||||
title: Create a Google Workspace provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
---
|
||||
|
||||
:::info
|
||||
This feature is in technical preview, so please report any bugs on [GitHub](https://github.com/goauthentik/authentik/issues).
|
||||
:::
|
||||
|
||||
For more information about using a Google Workspace provider, see the [Overview](./index.md) documentation.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To create a Google Workspace provider in authentik, you must have already [configured Google Workspace](./setup-gws.md) to integrate with authentik.
|
||||
|
||||
:::info
|
||||
When adding the Google Workspace provider in authentik, you must define the **Backchannel provider** using the name of the Google Workspace provider that you created in authentik. If you have also configured Google Workspace to log in using authentik following [these](../../../../integrations/services/google/), then this configuration can be done on the same app.
|
||||
:::
|
||||
|
||||
### Create the Google Workspace provider in authentik
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
|
||||
2. In the Admin interface, navigate to **Applications -> Providers**.
|
||||
|
||||
3. Click **Create**, and select **Google Workspace Provider**, and in the **New provider** modal box, define the following fields:
|
||||
|
||||
- **Name**: define a descriptive name, such as "GWS provider".
|
||||
|
||||
- **Protocol settings**
|
||||
|
||||
- **Credentials**: paste the contents of the JSON file you downloaded earlier.
|
||||
- **Delegated Subject**: enter the email address of the user all of authentik's actions should be delegated to
|
||||
- **Default group email domain**: enter a default domain which will be used to generate the domain for groups synced from authentik.
|
||||
- **User deletion action**: determines what authentik will do when a user is deleted from authentik.
|
||||
- **Group deletion action**: determines what authentik will do when a group is deleted from authentik.
|
||||
|
||||
- **User filtering**
|
||||
|
||||
- **Exclude service accounts**: set whether to include or exclude service accounts.
|
||||
- **Group**: select any specific groups to enforce that filtering (for all actions) is done only for the selected groups.
|
||||
|
||||
- **Attribute mapping**
|
||||
|
||||
- **User Property Mappings**: select any applicable mappings, or use the default.
|
||||
- **Group Property Mappings**: select any applicable mappings, or use the default.
|
||||
|
||||
4. Click **Finish**.
|
||||
|
||||
### Create a Google Workspace application in authentik
|
||||
|
||||
1. Log in as an admin to authentik, and go to the Admin interface.
|
||||
2. In the Admin interface, navigate to **Applications -> Applications**.
|
||||
:::info
|
||||
If you have also configured Google Workspace to log in using authentik following [these](https://docs.goauthentik.io/integrations/services/google/index), then this configuration can be done on the same app by adding this new provider as a backchannel provider on the existing app instead of creating a new app.
|
||||
:::
|
||||
3. Click **Create**, and in the **New provider** modal box, and define the following fields:
|
||||
|
||||
- **Slug**: enter the name of the app as you want it to appear in the URL.
|
||||
- **Provider**: when _not_ used in conjunction with the Google SAML configuration should be left empty.
|
||||
- **Backchannel Providers**: this field is required for Google Workspace. Select the name of the Google Workspace provider that you created in the steps above.
|
||||
- **UI settings**: leave these fields empty for Google Workspace.
|
||||
|
||||
4. Click **Finish**.
|
||||
53
website/docs/add-secure-apps/providers/gws/index.md
Normal file
53
website/docs/add-secure-apps/providers/gws/index.md
Normal file
@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Google Workspace provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
---
|
||||
|
||||
:::info
|
||||
This feature is in technical preview, so please report any bugs on [GitHub](https://github.com/goauthentik/authentik/issues).
|
||||
:::
|
||||
|
||||
With the Google Workspace provider, authentik serves as the single source of truth for all users and groups, when using Google products like Gmail.
|
||||
|
||||
- For instructions to configure your Google Workspace to integrate with authentik, refer to [Configure Google Workspace](./setup-gws.md).
|
||||
- For instructions to add Google Workspace as a provider, refer to [Create a Google Workspace provider](./add-gws-provider.md).
|
||||
|
||||
## About using Google Workspace with authentik
|
||||
|
||||
The following sections discuss how Google Workspace operates with authentik.
|
||||
|
||||
### Discovery
|
||||
|
||||
When first creating the provider and setting it up correctly, the provider will run a discovery and query your google workspace for all users and groups, and attempt to match them with their respective counterparts in authentik.
|
||||
|
||||
This matching is done by email address for users as google uses that as their primary identifier, and using group names for groups. This discovery also takes into consideration any **User filtering** options configured in the provider, such as only linking to authentik users in a specific group or excluding service accounts. This discovery happens every time before a full sync is started.
|
||||
|
||||
### Synchronization
|
||||
|
||||
There are two types of synchronization: a direct sync and a full sync.
|
||||
|
||||
A _direct sync_ happens when a user or group is created, updated or deleted in authentik, or when a user is added to or removed from a group. When one of these events happens, the direct sync automatically forwards those changes to Google Workspace.
|
||||
|
||||
The _full sync_ happens when the provider is initially created and when it is saved. The full sync goes through all users and groups matching the **User filtering** options set and will create/update them in Google Workspace. After the initial sync, authentik will run a full sync every four hours to ensure the consistency of users and groups.
|
||||
|
||||
During the full sync, if a user or group was created in authentik and a matching user/group exists in Google Workspace, authentik will automatically link them together. Furthermore, users present in authentik but not in Google Workspace will be created and and linked.
|
||||
|
||||
When a property mapping has an invalid expression, it will cause the sync to stop to prevent errors from being spammed. To handle any kind of network interruptions, authentik will detect transient request failures and retry any sync tasks.
|
||||
|
||||
### Customization for data mapping
|
||||
|
||||
There are a couple of considerations in regard to how authentik data is mapped to google workspace user/group data by default.
|
||||
|
||||
- For users, authentik only saves the full display name, while Google requires given/family name separately, and as such authentik attempts to separate the full name automatically with the default User property mapping.
|
||||
|
||||
- For groups, Google groups require an email address. Thus in authentik the provider configuration has an option **Default group email domain**, which will be used in conjunction with the group’s name to generate an email address. This can be customized with a property mapping.
|
||||
|
||||
- By default, authentik maps a user’s email, a user’s name, and their active status. For groups, the name is synced.
|
||||
|
||||
Refer to Google documentation for further details on which fields data can be mapped to:
|
||||
|
||||
- https://developers.google.com/admin-sdk/directory/reference/rest/v1/users#User
|
||||
- https://developers.google.com/admin-sdk/directory/reference/rest/v1/groups#Group
|
||||
69
website/docs/add-secure-apps/providers/gws/setup-gws.md
Normal file
69
website/docs/add-secure-apps/providers/gws/setup-gws.md
Normal file
@ -0,0 +1,69 @@
|
||||
---
|
||||
title: Configure Google Workspace
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
---
|
||||
|
||||
The configuration and set up of your Google Workspace must be completed before you [add the new provider](./add-gws-provider.md) in authentik.
|
||||
|
||||
## Overview of steps
|
||||
|
||||
The main steps to set up your Google workspace are as follows:
|
||||
|
||||
1. [Create your Google Cloud Project](#create-a-google-cloud-project)
|
||||
2. [Create a service account](#create-a-service-account)
|
||||
3. [Set credentials for the service account](#set-credentials-for-the-service-account)
|
||||
4. [Define access and scope in the Admin Console](#set-credentials-for-the-service-account)
|
||||
5. [Select email address for the Delegated Subject](#select-email-address-for-the-delegated-subject)
|
||||
|
||||
For detailed instructions, refer to Google documentation.
|
||||
|
||||
### Create a Google cloud project
|
||||
|
||||
1. Open the Google Cloud Console (https://cloud.google.com/cloud-console).
|
||||
2. In upper left, click the drop-down box to open the **Select a project** modal box, and then select **New Project**.
|
||||
3. Create a new project and give it a name like "authentik GWS"
|
||||
4. Use the search bar at the top of your new project page to search for "API Library".
|
||||
5. On the **API Library** page, use the search bar again to find "Admin SDK API".
|
||||
6. On the **Admin SDK API** page, click **Enable**.
|
||||
|
||||
### Create a service account
|
||||
|
||||
1. After the new Admin SDK API is enabled (it might take a few minutes), return to the Google Cloud console home page (click on **Google Cloud** in upper left).
|
||||
2. Use the search bar to find and navigate to the **IAM** page.
|
||||
3. On the **IAM** page, click **Service Accounts** in the left navigation pane.
|
||||
4. At the top of the **Service Accounts** page, click **Create Service Account**.
|
||||
|
||||
- Under **Service account details** page, define the **Name** and **Description** for the new service account, and then click **Create and Continue**.
|
||||
- Under **Grant this service account access to project** you do not need to define a role, so click **Continue**.
|
||||
- Under **Grant users access to project** you do not need to define a role, so click **Done** to complete the creation of the service account.
|
||||
|
||||
### Set credentials for the service account
|
||||
|
||||
1. On the **Service accounts** page, click the account that you just created.
|
||||
2. Click the **Keys** tab at top of the page, the click **Add Key -> Create new key**.
|
||||
3. In the Create modal box, select JSON as the key type, and then click **Create**.
|
||||
A pop-up displays with the private key, and the key is saved to your computer as a JSON file.
|
||||
Later, when you create your authentik provider for Google Workspace, you will add this key in the **Credentials** field.
|
||||
4. On the service account page, click the **Details** tab, and expand the **Advanced settings** area.
|
||||
5. Copy the **Client ID** (under **Domain-wide delegation**), and then click **View Google Workspace Admin Console**.
|
||||
6. Log in to the Admin Console, and then navigate to **Security -> Access and data control -> API controls**.
|
||||
7. On the **API controls** page, click **Manage Domain Wide Delegation**.
|
||||
8. On the **Domain Wide Delegation** page, click **Add new**.
|
||||
9. In the **Add a new client ID** modal box, paste in the Client ID that you copied from the Admin console earlier (the value from the downloaded JSON file) and paste in the following scope documents:
|
||||
- `https://www.googleapis.com/auth/admin.directory.user`
|
||||
- `https://www.googleapis.com/auth/admin.directory.group`
|
||||
- `https://www.googleapis.com/auth/admin.directory.group.member`
|
||||
- `https://www.googleapis.com/auth/admin.directory.domain.readonly`
|
||||
|
||||
### Select email address for the Delegated Subject
|
||||
|
||||
The Delegated Subject email address is a required field when creating the provider in authentik.
|
||||
|
||||
1. Open to the main Admin console page, and navigate to **Directory -> Users**.
|
||||
2. You can either select an existing user's email address or **Add new user** and define the user and email address to use as the Delegated Subject.
|
||||
3. Save this email address to enter into authentik when you are creating the Google Workspace provider.
|
||||
|
||||
Now that you have configured your Google Workspace, you are ready to [add it as a provider in authentik](./add-gws-provider.md).
|
||||
20
website/docs/add-secure-apps/providers/index.mdx
Normal file
20
website/docs/add-secure-apps/providers/index.mdx
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Providers
|
||||
slug: /providers
|
||||
---
|
||||
|
||||
import DocCardList from "@theme/DocCardList";
|
||||
|
||||
A Provider is an authentication method, a service that is used by authentik to authenticate the user for the associated application. Common Providers are OpenID Connect (OIDC)/OAuth2, LDAP, SAML, and generic proxy provider, and others.
|
||||
|
||||
Providers are the "other half" of [applications](../applications/index.md). They typically exist in a 1-to-1 relationship; each application needs a provider and every provider can be used with one application.
|
||||
|
||||
Applications can use additional providers to augment the functionality of the main provider. For more information, see [Backchannel providers](../applications/manage_apps.md#backchannel-providers).
|
||||
|
||||
You can create a new provider in the Admin interface, or you can use the [Application wizard](../applications/manage_apps.md#instructions) to create a new application and its provider at the same time.
|
||||
|
||||
Refer to the documentation for each provider:
|
||||
|
||||
<DocCardList />
|
||||
|
||||
You can also create a SAML provider by uploading an SP metadata XML file that contains the service provider's configuration data. SAML metadata is used to share configuration information between the Identity Provider (IdP) and the Service Provider (SP). An SP metadata XML file typically contains the SP certificate, the entity ID, the Assertion Consumer Service URL (ACS URL), and a log out URL (SingleLogoutService).
|
||||
BIN
website/docs/add-secure-apps/providers/ldap/general_setup1.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup10.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup11.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup11.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup12.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup12.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup13.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup13.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup14.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup14.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup15.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup15.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 106 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup16.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup16.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup2.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup3.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup4.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup5.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup5.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup6.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup6.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup7.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup7.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup8.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup8.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
website/docs/add-secure-apps/providers/ldap/general_setup9.png
Normal file
BIN
website/docs/add-secure-apps/providers/ldap/general_setup9.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
95
website/docs/add-secure-apps/providers/ldap/generic_setup.md
Normal file
95
website/docs/add-secure-apps/providers/ldap/generic_setup.md
Normal file
@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Create an LDAP provider
|
||||
---
|
||||
|
||||
### Create Service account
|
||||
|
||||
1. Create a new user account to bind with under _Directory_ -> _Users_ -> _Create_, in this example called `ldapservice`.
|
||||
|
||||
Note the DN of this user will be `cn=ldapservice,ou=users,dc=ldap,dc=goauthentik,dc=io`
|
||||
|
||||
:::info
|
||||
Note: The `default-authentication-flow` validates MFA by default, and currently everything but SMS-based devices and WebAuthn devices are supported by LDAP. If you plan to use only dedicated service accounts to bind to LDAP, or don't use SMS-based authenticators, then you can use the default flow and skip the extra steps below and continue at [Create LDAP Application & Provider](#create-ldap-application--provider)
|
||||
:::
|
||||
|
||||
### LDAP Flow
|
||||
|
||||
#### Create Custom Stages
|
||||
|
||||
1. Create a new identification stage. _Flows & Stage_ -> _Stages_ -> _Create_
|
||||
|
||||
2. Name it `ldap-identification-stage`. Select User fields Username and Email (and UPN if it is relevant to your setup).
|
||||
|
||||
3. Create a new password stage. _Flows & Stage_ -> _Stages_ -> _Create_
|
||||
|
||||
4. Name it `ldap-authentication-password`. Leave the defaults for Backends.
|
||||
|
||||
5. Create a new user login stage. _Flows & Stage_ -> _Stages_ -> _Create_
|
||||
|
||||
6. Name it `ldap-authentication-login`.
|
||||
|
||||
|
||||
#### Create Custom Flow
|
||||
|
||||
1. Create a new authentication flow under _Flows & Stage_ -> _Flows_ -> _Create_, and name it `ldap-authentication-flow`
|
||||
|
||||
2. Click the newly created flow and choose _Stage Bindings_.
|
||||
|
||||
3. Click `Bind Stage` choose `ldap-identification-stage` and set the order to `10`.
|
||||
|
||||
4. Click `Bind Stage` choose `ldap-authentication-login` and set the order to `30`.
|
||||
|
||||
5. Edit the `ldap-identification-stage`.
|
||||
|
||||
6. Change the Password stage to `ldap-authentication-password`.
|
||||
|
||||
|
||||
### Create LDAP Application & Provider
|
||||
|
||||
1. Create the LDAP Application under _Applications_ -> _Applications_ -> _Create With Wizard_ and name it `LDAP`.
|
||||
|
||||
|
||||
|
||||
### Assign LDAP permissions
|
||||
|
||||
1. Navigate to the LDAP Provider under _Applications_ -> _Providers_ -> `Provider for LDAP`.
|
||||
2. Switch to the _Permissions_ tab.
|
||||
3. Click the _Assign to new user_ button to select a user to assign the full directory search permission to.
|
||||
4. Select the `ldapservice` user in the modal by typing in its username. Select the _Search full LDAP directory_ permission and click _Assign_
|
||||
|
||||
### Create LDAP Outpost
|
||||
|
||||
1. Create (or update) the LDAP Outpost under _Applications_ -> _Outposts_ -> _Create_. Set the Type to `LDAP` and choose the `LDAP` application created in the previous step.
|
||||
|
||||
|
||||
:::info
|
||||
The LDAP Outpost selects different providers based on their Base DN. Adding multiple providers with the same Base DN will result in inconsistent access
|
||||
:::
|
||||
|
||||
### ldapsearch Test
|
||||
|
||||
Test connectivity by using ldapsearch.
|
||||
|
||||
:::info
|
||||
ldapsearch can be installed on Linux system with these commands
|
||||
|
||||
```shell
|
||||
sudo apt-get install ldap-utils -y # Debian-based systems
|
||||
sudo yum install openldap-clients -y # CentOS-based systems
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
```shell
|
||||
ldapsearch \
|
||||
-x \
|
||||
-H ldap://<LDAP Outpost IP address>:<Port number 389> \ # In production it is recommended to use SSL, which also requires `ldaps://` as the protocol and the SSL port
|
||||
-D 'cn=ldapservice,ou=users,DC=ldap,DC=goauthentik,DC=io' \
|
||||
-w '<ldapuserpassword>' \
|
||||
-b 'DC=ldap,DC=goauthentik,DC=io' \
|
||||
'(objectClass=user)'
|
||||
```
|
||||
|
||||
:::info
|
||||
This query will log the first successful attempt in an event in the _Events_ -> _Logs_ area, further successful logins from the same user are not logged as they are cached in the outpost.
|
||||
:::
|
||||
121
website/docs/add-secure-apps/providers/ldap/index.md
Normal file
121
website/docs/add-secure-apps/providers/ldap/index.md
Normal file
@ -0,0 +1,121 @@
|
||||
---
|
||||
title: LDAP Provider
|
||||
---
|
||||
|
||||
You can configure an LDAP Provider for applications that don't support any newer protocols or require LDAP.
|
||||
|
||||
:::info
|
||||
Note: This provider requires the deployment of the [LDAP Outpost](../../outposts/index.mdx)
|
||||
:::
|
||||
|
||||
All users and groups in authentik's database are searchable. Currently, there is limited support for filters (you can only search for objectClass), but this will be expanded in further releases.
|
||||
|
||||
Binding against the LDAP Server uses a flow in the background. This allows you to use the same policies and flows as you do for web-based logins. For more info, see [Bind modes](#binding--bind-modes).
|
||||
|
||||
You can configure under which base DN the information should be available. For this documentation we'll use the default of `DC=ldap,DC=goauthentik,DC=io`.
|
||||
|
||||
Users are available under `ou=users,<base DN>` and groups under `ou=groups,<base DN>`. To aid compatibility, each user belongs to its own "virtual" group, as is standard on most Unix-like systems. This group does not exist in the authentik database, and is generated on the fly. These virtual groups are under the `ou=virtual-groups,<base DN>` DN.
|
||||
|
||||
:::info
|
||||
Note: Every LDAP provider needs to have a unique base DN. You can achieve this by prepending an application-specific OU or DC. e.g. `OU=appname,DC=ldap,DC=goauthentik,DC=io`
|
||||
:::
|
||||
|
||||
The following fields are currently sent for users:
|
||||
|
||||
- `cn`: User's username
|
||||
- `uid`: Unique user identifier
|
||||
- `uidNumber`: A unique numeric identifier for the user
|
||||
- `name`: User's name
|
||||
- `displayName`: User's name
|
||||
- `mail`: User's email address
|
||||
- `objectClass`: A list of these strings:
|
||||
- "user"
|
||||
- "organizationalPerson"
|
||||
- "goauthentik.io/ldap/user"
|
||||
- `memberOf`: A list of all DNs that the user is a member of
|
||||
- `homeDirectory`: A default home directory path for the user, by default `/home/$username`. Can be overwritten by setting `homeDirectory` as an attribute on users or groups.
|
||||
- `ak-active`: "true" if the account is active, otherwise "false"
|
||||
- `ak-superuser`: "true" if the account is part of a group with superuser permissions, otherwise "false"
|
||||
|
||||
The following fields are current set for groups:
|
||||
|
||||
- `cn`: The group's name
|
||||
- `uid`: Unique group identifier
|
||||
- `gidNumber`: A unique numeric identifier for the group
|
||||
- `member`: A list of all DNs of the groups members
|
||||
- `objectClass`: A list of these strings:
|
||||
- "group"
|
||||
- "goauthentik.io/ldap/group"
|
||||
|
||||
A virtual group is also created for each user, they have the same fields as groups but have an additional objectClass: `goauthentik.io/ldap/virtual-group`.
|
||||
The virtual groups gidNumber is equal to the uidNumber of the user.
|
||||
|
||||
**Additionally**, for both users and (non-virtual) groups, any attributes you set are also present as LDAP Attributes.
|
||||
|
||||
:::info
|
||||
Starting with 2021.9.1, custom attributes will override the inbuilt attributes.
|
||||
:::
|
||||
|
||||
:::info
|
||||
Starting with 2023.3, periods and slashes in custom attributes will be sanitized.
|
||||
:::
|
||||
|
||||
## SSL / StartTLS
|
||||
|
||||
You can also configure SSL for your LDAP Providers by selecting a certificate and a server name in the provider settings.
|
||||
|
||||
Starting with authentik 2023.6, StartTLS is supported, and the provider will pick the correct certificate based on the configured _TLS Server name_ field. The certificate is not picked based on the Bind DN, as the StartTLS operation should happen be the bind request to ensure bind credentials are transmitted over TLS.
|
||||
|
||||
This enables you to bind on port 636 using LDAPS.
|
||||
|
||||
## Integrations
|
||||
|
||||
See the integration guide for [sssd](/integrations/services/sssd) for an example guide.
|
||||
|
||||
## Binding & Bind Modes
|
||||
|
||||
All bind modes rely on flows.
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [Identification](../../flows-stages/stages/identification/index.md)
|
||||
- [Password](../../flows-stages/stages/password/index.md)
|
||||
- [Authenticator validation](../../flows-stages/stages/authenticator_validate/index.md)
|
||||
|
||||
Note: Authenticator validation currently only supports DUO, TOTP and static authenticators.
|
||||
|
||||
Starting with authentik 2023.6, code-based authenticators are only supported when _Code-based MFA Support_ is enabled in the provider. When enabled, all users that will bind to the LDAP provider should have a TOTP device configured, as otherwise a password might be incorrectly rejected when semicolons are used in the password.
|
||||
|
||||
For code-based authenticators, the code must be given as part of the bind password, separated by a semicolon. For example for the password `example-password` and the code `123456`, the input must be `example-password;123456`.
|
||||
|
||||
SMS-based authenticators are not supported as they require a code to be sent from authentik, which is not possible during the bind.
|
||||
|
||||
- [User Logout](../../flows-stages/stages/user_logout.md)
|
||||
- [User Login](../../flows-stages/stages/user_login/index.md)
|
||||
- [Deny](../../flows-stages/stages/deny.md)
|
||||
|
||||
#### Direct bind
|
||||
|
||||
In this mode, the outpost will always execute the configured flow when a new bind request is received.
|
||||
|
||||
#### Cached bind
|
||||
|
||||
This mode uses the same logic as direct bind, however the result is cached for the entered credentials, and saved in memory for the standard session duration. Sessions are saved independently, meaning that revoking sessions does _not_ remove them from the outpost, and neither will changing a users credentials.
|
||||
|
||||
## Searching & Search Modes
|
||||
|
||||
Any user that is authorized to access the LDAP provider's application can execute search the LDAP directory. Without explicit permissions to do broader searches, a user's search request will return information about themselves, including user info, group info, and group membership.
|
||||
|
||||
[Users](../../../users-sources/user/index.mdx) and [roles](../../../users-sources/roles/index.md) can be assigned the permission "Search full LDAP directory" to allow them to search the full LDAP directory and retrieve information about all users in the authentik instance.
|
||||
|
||||
:::info
|
||||
Up to authentik version 2024.8 this was managed using the "Search group" attribute in the LDAP Provider, where users could be added to a group to grant them this permission. With authentik 2024.8 this is automatically migrated to the "Search full LDAP directory" permission, which can be assigned more flexibly.
|
||||
:::
|
||||
|
||||
#### Direct search
|
||||
|
||||
Every LDAP search request will trigger one or more requests to the authentik core API. This will always return the latest data, however also has a performance hit due all the layers the backend requests have to go through, etc.
|
||||
|
||||
#### Cached search
|
||||
|
||||
In this mode, the outpost will periodically fetch all users and groups from the backend, hold them in memory, and respond to search queries directly. This means greatly improved performance but potentially returning old/invalid data.
|
||||
@ -0,0 +1,64 @@
|
||||
# Machine-to-machine authentication
|
||||
|
||||
Client credentials can be used for machine-to-machine communication authentication. Clients can authenticate themselves using service-accounts; standard client_id + client_secret is not sufficient. This behavior is due to providers only being able to have a single secret at any given time.
|
||||
|
||||
Note that authentik does treat a grant type of `password` the same as `client_credentials` to support applications which rely on a password grant.
|
||||
|
||||
### Static authentication
|
||||
|
||||
Hence identification is based on service-accounts, and authentication is based on App-password tokens. These objects can be created in a single step using the _Create Service account_ function.
|
||||
|
||||
An example request can look like this:
|
||||
|
||||
```
|
||||
POST /application/o/token/ HTTP/1.1
|
||||
Host: authentik.company
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
grant_type=client_credentials&
|
||||
client_id=application_client_id&
|
||||
username=my-service-account&
|
||||
password=my-token&
|
||||
scope=profile
|
||||
```
|
||||
|
||||
This will return a JSON response with an `access_token`, which is a signed JWT token. This token can be sent along requests to other hosts, which can then validate the JWT based on the signing key configured in authentik.
|
||||
|
||||
Starting with authentik 2024.4, it is also possible to encode the username and token of the user to authenticate with, separated with a colon, into a base64 string and pass it as `client_secret` value.
|
||||
|
||||
In addition to that, with authentik 2024.4 it is also possible to pass the configured `client_secret` value, which will automatically generate a service account user for which the JWT token will be issued.
|
||||
|
||||
### JWT-authentication
|
||||
|
||||
Starting with authentik 2022.4, you can authenticate and get a token using an existing JWT.
|
||||
|
||||
(For readability we will refer to the JWT issued by the external issuer/platform as input JWT, and the resulting JWT from authentik as the output JWT)
|
||||
|
||||
To configure this, the certificate used to sign the input JWT must be created in authentik. The certificate is enough, a private key is not required. Afterwards, configure the certificate in the OAuth2 provider settings under _Verification certificates_.
|
||||
|
||||
:::info
|
||||
Starting with authentik 2022.6, you can define a JWKS URL/raw JWKS data in OAuth Sources, and use those to verify the key instead of having to manually create a certificate in authentik for them. This method is still supported but will be removed in a later version.
|
||||
:::
|
||||
|
||||
With this configure, any JWT issued by the configured certificates can be used to authenticate:
|
||||
|
||||
```
|
||||
POST /application/o/token/ HTTP/1.1
|
||||
Host: authentik.company
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
grant_type=client_credentials&
|
||||
client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&
|
||||
client_assertion=$inputJWT&
|
||||
client_id=application_client_id
|
||||
```
|
||||
|
||||
Alternatively, you can set the `client_secret` parameter to the `$inputJWT`, for applications which can set the password from a file but not other parameters.
|
||||
|
||||
Input JWTs are checked to be signed by any of the selected _Verification certificates_, and their `exp` attribute must not be now or in the past.
|
||||
|
||||
To do additional checks, you can use _[Expression policies](../../../customize/policies/expression.mdx)_:
|
||||
|
||||
```python
|
||||
return request.context["oauth_jwt"]["iss"] == "https://my.issuer"
|
||||
```
|
||||
51
website/docs/add-secure-apps/providers/oauth2/device_code.md
Normal file
51
website/docs/add-secure-apps/providers/oauth2/device_code.md
Normal file
@ -0,0 +1,51 @@
|
||||
# Device code flow
|
||||
|
||||
(Also known as device flow and [RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628))
|
||||
|
||||
This type of authentication flow is useful for devices with limited input abilities and/or devices without browsers.
|
||||
|
||||
### Requirements
|
||||
|
||||
This device flow is only possible if the active brand has a device code flow setup. This device code flow is run _after_ the user logs in, and before the user authenticates.
|
||||
|
||||
authentik doesn't ship with a default flow for this usecase, so it is recommended to create a new flow for this usecase with the designation of _Stage configuration_
|
||||
|
||||
### Device-side
|
||||
|
||||
The flow is initiated by sending a POST request to the device authorization endpoint, `/application/o/device/` with the following contents:
|
||||
|
||||
```
|
||||
POST /application/o/device/ HTTP/1.1
|
||||
Host: authentik.company
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
client_id=application_client_id&
|
||||
scopes=openid email my-other-scope
|
||||
```
|
||||
|
||||
The response contains the following fields:
|
||||
|
||||
- `device_code`: Device code, which is the code kept on the device
|
||||
- `verification_uri`: The URL to be shown to the enduser to input the code
|
||||
- `verification_uri_complete`: The same URL as above except the code will be prefilled
|
||||
- `user_code`: The raw code for the enduser to input
|
||||
- `expires_in`: The total seconds after which this token will expire
|
||||
- `interval`: The interval in seconds for how often the device should check the token status
|
||||
|
||||
---
|
||||
|
||||
With this response, the device can start checking the status of the token by sending requests to the token endpoint like this:
|
||||
|
||||
```
|
||||
POST /application/o/token/ HTTP/1.1
|
||||
Host: authentik.company
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
grant_type=urn:ietf:params:oauth:grant-type:device_code&
|
||||
client_id=application_client_id&
|
||||
device_code=device_code_from_above
|
||||
```
|
||||
|
||||
If the user has not opened the link above yet, or has not finished the authentication and authorization yet, the response will contain an `error` element set to `authorization_pending`. The device should re-send the request in the interval set above.
|
||||
|
||||
If the user _has_ finished the authentication and authorization, the response will be similar to any other generic OAuth2 Token request, containing `access_token` and `id_token`.
|
||||
84
website/docs/add-secure-apps/providers/oauth2/index.md
Normal file
84
website/docs/add-secure-apps/providers/oauth2/index.md
Normal file
@ -0,0 +1,84 @@
|
||||
---
|
||||
title: OAuth2 Provider
|
||||
---
|
||||
|
||||
This provider supports both generic OAuth2 as well as OpenID Connect
|
||||
|
||||
Scopes can be configured using scope mappings, a type of [property mapping](../property-mappings/index.md#scope-mappings).
|
||||
|
||||
| Endpoint | URL |
|
||||
| -------------------- | -------------------------------------------------------------------- |
|
||||
| Authorization | `/application/o/authorize/` |
|
||||
| Token | `/application/o/token/` |
|
||||
| User Info | `/application/o/userinfo/` |
|
||||
| Token Revoke | `/application/o/revoke/` |
|
||||
| End Session | `/application/o/<application slug>/end-session/` |
|
||||
| JWKS | `/application/o/<application slug>/jwks/` |
|
||||
| OpenID Configuration | `/application/o/<application slug>/.well-known/openid-configuration` |
|
||||
|
||||
## GitHub Compatibility
|
||||
|
||||
This provider also exposes a GitHub-compatible endpoint. This endpoint can be used by applications, which support authenticating against GitHub Enterprise, but not generic OpenID Connect.
|
||||
|
||||
To use any of the GitHub Compatibility scopes, you have to use the GitHub Compatibility Endpoints.
|
||||
|
||||
| Endpoint | URL |
|
||||
| --------------- | --------------------------- |
|
||||
| Authorization | `/login/oauth/authorize` |
|
||||
| Token | `/login/oauth/access_token` |
|
||||
| User Info | `/user` |
|
||||
| User Teams Info | `/user/teams` |
|
||||
|
||||
To access the user's email address, a scope of `user:email` is required. To access their groups, `read:org` is required. Because these scopes are handled by a different endpoint, they are not customisable as a Scope Mapping.
|
||||
|
||||
## Grant types
|
||||
|
||||
### `authorization_code`:
|
||||
|
||||
This grant is used to convert an authorization code to an access token (and optionally refresh token). The authorization code is retrieved through the Authorization flow, and can only be used once, and expires quickly.
|
||||
|
||||
:::info
|
||||
Starting with authentik 2024.2, applications only receive an access token. To receive a refresh token, both applications and authentik must be configured to request the `offline_access` scope. In authentik this can be done by selecting the `offline_access` Scope mapping in the provider settings.
|
||||
:::
|
||||
|
||||
### `refresh_token`:
|
||||
|
||||
Refresh tokens can be used as long-lived tokens to access user data, and further renew the refresh token down the road.
|
||||
|
||||
:::info
|
||||
Starting with authentik 2024.2, this grant requires the `offline_access` scope.
|
||||
:::
|
||||
|
||||
### `client_credentials`:
|
||||
|
||||
See [Machine-to-machine authentication](./client_credentials.md)
|
||||
|
||||
## Scope authorization
|
||||
|
||||
By default, every user that has access to an application can request any of the configured scopes. Starting with authentik 2022.4, you can do additional checks for the scope in an expression policy (bound to the application):
|
||||
|
||||
```python
|
||||
# There are additional fields set in the context, use `ak_logger.debug(request.context)` to see them.
|
||||
if "my-admin-scope" in request.context["oauth_scopes"]:
|
||||
return ak_is_group_member(request.user, name="my-admin-group")
|
||||
return True
|
||||
```
|
||||
|
||||
## Special scopes
|
||||
|
||||
#### GitHub compatibility
|
||||
|
||||
- `user`: No-op, is accepted for compatibility but does not give access to any resources
|
||||
- `read:user`: Same as above
|
||||
- `user:email`: Allows read-only access to `/user`, including email address
|
||||
- `read:org`: Allows read-only access to `/user/teams`, listing all the user's groups as teams.
|
||||
|
||||
#### authentik
|
||||
|
||||
- `goauthentik.io/api`: This scope grants the refresh token access to the authentik API on behalf of the user
|
||||
|
||||
## Default scopes <span class="badge badge--version">authentik 2022.7+</span>
|
||||
|
||||
When a client does not request any scopes, authentik will treat the request as if all configured scopes were requested. Depending on the configured authorization flow, consent still needs to be given, and all scopes are listed there.
|
||||
|
||||
This does _not_ apply to special scopes, as those are not configurable in the provider.
|
||||
@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Expressions
|
||||
---
|
||||
|
||||
The property mapping should return a value that is expected by the provider. Supported types are documented in the individual provider. Returning `None` is always accepted and would simply skip the mapping for which `None` was returned.
|
||||
|
||||
## Available Functions
|
||||
|
||||
import Functions from "../../../expressions/_functions.md";
|
||||
|
||||
<Functions />
|
||||
|
||||
## Variables
|
||||
|
||||
import Objects from "../../../expressions/_objects.md";
|
||||
|
||||
<Objects />
|
||||
|
||||
import User from "../../../expressions/_user.md";
|
||||
|
||||
<User />
|
||||
|
||||
- `request`: The current request. This may be `None` if there is no contextual request. See ([Django documentation](https://docs.djangoproject.com/en/3.0/ref/request-response/#httprequest-objects))
|
||||
- Other arbitrary arguments given by the provider, this is documented on the provider.
|
||||
@ -0,0 +1,13 @@
|
||||
---
|
||||
title: Provider property mappings
|
||||
---
|
||||
|
||||
Property mappings allow you to pass information to external applications. For example, pass the current user's groups as a SAML parameter.
|
||||
|
||||
## SAML property mappings
|
||||
|
||||
SAML property mappings allow you embed information into the SAML authentication request. This information can then be used by the application to, for example, assign permissions to the object.
|
||||
|
||||
## Scope mappings
|
||||
|
||||
Scope mappings are used by the OAuth2 provider to map information from authentik to OAuth2/OpenID claims. Values returned by a scope mapping are added as custom claims to access and ID tokens.
|
||||
@ -0,0 +1,6 @@
|
||||
:::info
|
||||
_example-outpost_ is used as a placeholder for the outpost name.
|
||||
_authentik.company_ is used as a placeholder for the authentik install.
|
||||
_app.company_ is used as a placeholder for the external domain for the application.
|
||||
_outpost.company_ is used as a placeholder for the outpost. When using the embedded outpost, this can be the same as _authentik.company_
|
||||
:::
|
||||
@ -0,0 +1,33 @@
|
||||
Use the following configuration:
|
||||
|
||||
```
|
||||
app.company {
|
||||
# directive execution order is only as stated if enclosed with route.
|
||||
route {
|
||||
# always forward outpost path to actual outpost
|
||||
reverse_proxy /outpost.goauthentik.io/* http://outpost.company:9000
|
||||
|
||||
# forward authentication to outpost
|
||||
forward_auth http://outpost.company:9000 {
|
||||
uri /outpost.goauthentik.io/auth/caddy
|
||||
|
||||
# capitalization of the headers is important, otherwise they will be empty
|
||||
copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name X-Authentik-Uid X-Authentik-Jwt X-Authentik-Meta-Jwks X-Authentik-Meta-Outpost X-Authentik-Meta-Provider X-Authentik-Meta-App X-Authentik-Meta-Version
|
||||
|
||||
# optional, in this config trust all private ranges, should probably be set to the outposts IP
|
||||
trusted_proxies private_ranges
|
||||
}
|
||||
|
||||
# actual site configuration below, for example
|
||||
reverse_proxy localhost:1234
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If you're trying to proxy to an upstream over HTTPS, you need to set the `Host` header to the value they expect for it to work correctly.
|
||||
|
||||
```
|
||||
reverse_proxy /outpost.goauthentik.io/* https://outpost.company {
|
||||
header_up Host {http.reverse_proxy.upstream.hostport}
|
||||
}
|
||||
```
|
||||
51
website/docs/add-secure-apps/providers/proxy/_envoy_istio.md
Normal file
51
website/docs/add-secure-apps/providers/proxy/_envoy_istio.md
Normal file
@ -0,0 +1,51 @@
|
||||
Set the following settings on the _IstioOperator_ resource:
|
||||
|
||||
```yaml
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
metadata:
|
||||
name: istio
|
||||
namespace: istio-system
|
||||
spec:
|
||||
meshConfig:
|
||||
extensionProviders:
|
||||
- name: "authentik"
|
||||
envoyExtAuthzHttp:
|
||||
# Replace with <service-name>.<namespace>.svc.cluster.local
|
||||
service: "ak-outpost-authentik-embedded-outpost.authentik.svc.cluster.local"
|
||||
port: "9000"
|
||||
pathPrefix: "/outpost.goauthentik.io/auth/envoy"
|
||||
headersToDownstreamOnAllow:
|
||||
- cookie
|
||||
headersToUpstreamOnAllow:
|
||||
- set-cookie
|
||||
- x-authentik-*
|
||||
# Add authorization headers to the allow list if you need proxy providers which
|
||||
# send a custom HTTP-Basic Authentication header based on values from authentik
|
||||
# - authorization
|
||||
includeRequestHeadersInCheck:
|
||||
- cookie
|
||||
```
|
||||
|
||||
Afterwards, you can create _AuthorizationPolicy_ resources to protect your applications like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: authentik-policy
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
istio: ingressgateway
|
||||
action: CUSTOM
|
||||
provider:
|
||||
name: "authentik"
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
hosts:
|
||||
# You can create a single resource and list all Domain names here, or create multiple resources
|
||||
- "app.company"
|
||||
```
|
||||
@ -0,0 +1,46 @@
|
||||
Create a new ingress for the outpost
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: authentik-outpost
|
||||
spec:
|
||||
rules:
|
||||
- host: app.company
|
||||
http:
|
||||
paths:
|
||||
- path: /outpost.goauthentik.io
|
||||
pathType: Prefix
|
||||
backend:
|
||||
# Or, to use an external Outpost, create an ExternalName service and reference that here.
|
||||
# See https://kubernetes.io/docs/concepts/services-networking/service/#externalname
|
||||
service:
|
||||
name: ak-outpost-example-outpost
|
||||
port:
|
||||
number: 9000
|
||||
```
|
||||
|
||||
This ingress handles authentication requests, and the sign-in flow.
|
||||
|
||||
Add these annotations to the ingress you want to protect
|
||||
|
||||
:::warning
|
||||
This configuration requires that you enable [`allow-snippet-annotations`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#allow-snippet-annotations), for example by setting `controller.allowSnippetAnnotations` to `true` in your helm values for the ingress-nginx installation.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
annotations:
|
||||
# This should be the in-cluster DNS name for the authentik outpost service
|
||||
# as when the external URL is specified here, nginx will overwrite some crucial headers
|
||||
nginx.ingress.kubernetes.io/auth-url: |-
|
||||
http://ak-outpost-example.authentik.svc.cluster.local:9000/outpost.goauthentik.io/auth/nginx
|
||||
# If you're using domain-level auth, use the authentication URL instead of the application URL
|
||||
nginx.ingress.kubernetes.io/auth-signin: |-
|
||||
https://app.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$escaped_request_uri
|
||||
nginx.ingress.kubernetes.io/auth-response-headers: |-
|
||||
Set-Cookie,X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid
|
||||
nginx.ingress.kubernetes.io/auth-snippet: |
|
||||
proxy_set_header X-Forwarded-Host $http_host;
|
||||
```
|
||||
@ -0,0 +1,80 @@
|
||||
```
|
||||
# Upgrade WebSocket if requested, otherwise use keepalive
|
||||
map $http_upgrade $connection_upgrade_keepalive {
|
||||
default upgrade;
|
||||
'' '';
|
||||
}
|
||||
|
||||
# Increase buffer size for large headers
|
||||
# This is needed only if you get 'upstream sent too big header while reading response
|
||||
# header from upstream' error when trying to access an application protected by goauthentik
|
||||
proxy_buffers 8 16k;
|
||||
proxy_buffer_size 32k;
|
||||
|
||||
# Make sure not to redirect traffic to a port 4443
|
||||
port_in_redirect off;
|
||||
|
||||
location / {
|
||||
# Put your proxy_pass to your application here
|
||||
proxy_pass $forward_scheme://$server:$port;
|
||||
# Set any other headers your application might need
|
||||
# proxy_set_header Host $host;
|
||||
# proxy_set_header ...
|
||||
# Support for websocket
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade_keepalive;
|
||||
|
||||
##############################
|
||||
# authentik-specific config
|
||||
##############################
|
||||
auth_request /outpost.goauthentik.io/auth/nginx;
|
||||
error_page 401 = @goauthentik_proxy_signin;
|
||||
auth_request_set $auth_cookie $upstream_http_set_cookie;
|
||||
add_header Set-Cookie $auth_cookie;
|
||||
|
||||
# translate headers from the outposts back to the actual upstream
|
||||
auth_request_set $authentik_username $upstream_http_x_authentik_username;
|
||||
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
|
||||
auth_request_set $authentik_email $upstream_http_x_authentik_email;
|
||||
auth_request_set $authentik_name $upstream_http_x_authentik_name;
|
||||
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;
|
||||
|
||||
proxy_set_header X-authentik-username $authentik_username;
|
||||
proxy_set_header X-authentik-groups $authentik_groups;
|
||||
proxy_set_header X-authentik-email $authentik_email;
|
||||
proxy_set_header X-authentik-name $authentik_name;
|
||||
proxy_set_header X-authentik-uid $authentik_uid;
|
||||
|
||||
# This section should be uncommented when the "Send HTTP Basic authentication" option
|
||||
# is enabled in the proxy provider
|
||||
# auth_request_set $authentik_auth $upstream_http_authorization;
|
||||
# proxy_set_header Authorization $authentik_auth;
|
||||
}
|
||||
|
||||
# all requests to /outpost.goauthentik.io must be accessible without authentication
|
||||
location /outpost.goauthentik.io {
|
||||
# When using the embedded outpost, use:
|
||||
proxy_pass http://authentik.company:9000/outpost.goauthentik.io;
|
||||
# For manual outpost deployments:
|
||||
# proxy_pass http://outpost.company:9000;
|
||||
|
||||
# Note: ensure the Host header matches your external authentik URL:
|
||||
proxy_set_header Host $host;
|
||||
|
||||
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
|
||||
add_header Set-Cookie $auth_cookie;
|
||||
auth_request_set $auth_cookie $upstream_http_set_cookie;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
}
|
||||
|
||||
# Special location for when the /auth endpoint returns a 401,
|
||||
# redirect to the /start URL which initiates SSO
|
||||
location @goauthentik_proxy_signin {
|
||||
internal;
|
||||
add_header Set-Cookie $auth_cookie;
|
||||
return 302 /outpost.goauthentik.io/start?rd=$request_uri;
|
||||
# For domain level, use the below error_page to redirect to your authentik server with the full redirect path
|
||||
# return 302 https://authentik.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
|
||||
}
|
||||
```
|
||||
@ -0,0 +1,85 @@
|
||||
```
|
||||
# Upgrade WebSocket if requested, otherwise use keepalive
|
||||
map $http_upgrade $connection_upgrade_keepalive {
|
||||
default upgrade;
|
||||
'' '';
|
||||
}
|
||||
|
||||
server {
|
||||
# SSL and VHost configuration
|
||||
listen 443 ssl http2;
|
||||
server_name _;
|
||||
|
||||
ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
|
||||
ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;
|
||||
|
||||
# Increase buffer size for large headers
|
||||
# This is needed only if you get 'upstream sent too big header while reading response
|
||||
# header from upstream' error when trying to access an application protected by goauthentik
|
||||
proxy_buffers 8 16k;
|
||||
proxy_buffer_size 32k;
|
||||
|
||||
location / {
|
||||
# Put your proxy_pass to your application here, and all the other statements you'll need
|
||||
# proxy_pass http://localhost:5000;
|
||||
# proxy_set_header Host $host;
|
||||
# proxy_set_header ...
|
||||
# Support for websocket
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade_keepalive;
|
||||
|
||||
##############################
|
||||
# authentik-specific config
|
||||
##############################
|
||||
auth_request /outpost.goauthentik.io/auth/nginx;
|
||||
error_page 401 = @goauthentik_proxy_signin;
|
||||
auth_request_set $auth_cookie $upstream_http_set_cookie;
|
||||
add_header Set-Cookie $auth_cookie;
|
||||
|
||||
# translate headers from the outposts back to the actual upstream
|
||||
auth_request_set $authentik_username $upstream_http_x_authentik_username;
|
||||
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
|
||||
auth_request_set $authentik_email $upstream_http_x_authentik_email;
|
||||
auth_request_set $authentik_name $upstream_http_x_authentik_name;
|
||||
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;
|
||||
|
||||
proxy_set_header X-authentik-username $authentik_username;
|
||||
proxy_set_header X-authentik-groups $authentik_groups;
|
||||
proxy_set_header X-authentik-email $authentik_email;
|
||||
proxy_set_header X-authentik-name $authentik_name;
|
||||
proxy_set_header X-authentik-uid $authentik_uid;
|
||||
|
||||
# This section should be uncommented when the "Send HTTP Basic authentication" option
|
||||
# is enabled in the proxy provider
|
||||
# auth_request_set $authentik_auth $upstream_http_authorization;
|
||||
# proxy_set_header Authorization $authentik_auth;
|
||||
}
|
||||
|
||||
# all requests to /outpost.goauthentik.io must be accessible without authentication
|
||||
location /outpost.goauthentik.io {
|
||||
# When using the embedded outpost, use:
|
||||
proxy_pass http://authentik.company:9000/outpost.goauthentik.io;
|
||||
# For manual outpost deployments:
|
||||
# proxy_pass http://outpost.company:9000;
|
||||
|
||||
# Note: ensure the Host header matches your external authentik URL:
|
||||
proxy_set_header Host $host;
|
||||
|
||||
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
|
||||
add_header Set-Cookie $auth_cookie;
|
||||
auth_request_set $auth_cookie $upstream_http_set_cookie;
|
||||
proxy_pass_request_body off;
|
||||
proxy_set_header Content-Length "";
|
||||
}
|
||||
|
||||
# Special location for when the /auth endpoint returns a 401,
|
||||
# redirect to the /start URL which initiates SSO
|
||||
location @goauthentik_proxy_signin {
|
||||
internal;
|
||||
add_header Set-Cookie $auth_cookie;
|
||||
return 302 /outpost.goauthentik.io/start?rd=$request_uri;
|
||||
# For domain level, use the below error_page to redirect to your authentik server with the full redirect path
|
||||
# return 302 https://authentik.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -0,0 +1,45 @@
|
||||
```yaml
|
||||
services:
|
||||
traefik:
|
||||
image: traefik:v3.0
|
||||
container_name: traefik
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
ports:
|
||||
- 80:80
|
||||
command:
|
||||
- "--api"
|
||||
- "--providers.docker=true"
|
||||
- "--providers.docker.exposedByDefault=false"
|
||||
- "--entrypoints.web.address=:80"
|
||||
|
||||
authentik-proxy:
|
||||
image: ghcr.io/goauthentik/proxy
|
||||
ports:
|
||||
- 9000:9000
|
||||
- 9443:9443
|
||||
environment:
|
||||
AUTHENTIK_HOST: https://your-authentik.tld
|
||||
AUTHENTIK_INSECURE: "false"
|
||||
AUTHENTIK_TOKEN: token-generated-by-authentik
|
||||
# Starting with 2021.9, you can optionally set this too
|
||||
# when authentik_host for internal communication doesn't match the public URL
|
||||
# AUTHENTIK_HOST_BROWSER: https://external-domain.tld
|
||||
labels:
|
||||
traefik.enable: true
|
||||
traefik.port: 9000
|
||||
traefik.http.routers.authentik.rule: Host(`app.company`) && PathPrefix(`/outpost.goauthentik.io/`)
|
||||
# `authentik-proxy` refers to the service name in the compose file.
|
||||
traefik.http.middlewares.authentik.forwardauth.address: http://authentik-proxy:9000/outpost.goauthentik.io/auth/traefik
|
||||
traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: true
|
||||
traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version
|
||||
restart: unless-stopped
|
||||
|
||||
whoami:
|
||||
image: containous/whoami
|
||||
labels:
|
||||
traefik.enable: true
|
||||
traefik.http.routers.whoami.rule: Host(`app.company`)
|
||||
traefik.http.routers.whoami.middlewares: authentik@docker
|
||||
restart: unless-stopped
|
||||
```
|
||||
@ -0,0 +1,52 @@
|
||||
Create a middleware:
|
||||
|
||||
```yaml
|
||||
apiVersion: traefik.containo.us/v1alpha1
|
||||
kind: Middleware
|
||||
metadata:
|
||||
name: authentik
|
||||
spec:
|
||||
forwardAuth:
|
||||
address: http://outpost.company:9000/outpost.goauthentik.io/auth/traefik
|
||||
trustForwardHeader: true
|
||||
authResponseHeaders:
|
||||
- X-authentik-username
|
||||
- X-authentik-groups
|
||||
- X-authentik-email
|
||||
- X-authentik-name
|
||||
- X-authentik-uid
|
||||
- X-authentik-jwt
|
||||
- X-authentik-meta-jwks
|
||||
- X-authentik-meta-outpost
|
||||
- X-authentik-meta-provider
|
||||
- X-authentik-meta-app
|
||||
- X-authentik-meta-version
|
||||
```
|
||||
|
||||
Add the following settings to your IngressRoute
|
||||
|
||||
By default traefik does not allow cross-namespace references for middlewares:
|
||||
|
||||
See [here](https://doc.traefik.io/traefik/v2.4/providers/kubernetes-crd/#allowcrossnamespace) to enable it.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
routes:
|
||||
- kind: Rule
|
||||
match: "Host(`app.company`)"
|
||||
middlewares:
|
||||
- name: authentik
|
||||
namespace: authentik
|
||||
priority: 10
|
||||
services: # Unchanged
|
||||
# This part is only required for single-app setups
|
||||
- kind: Rule
|
||||
match: "Host(`app.company`) && PathPrefix(`/outpost.goauthentik.io/`)"
|
||||
priority: 15
|
||||
services:
|
||||
- kind: Service
|
||||
# Or, to use an external Outpost, create an ExternalName service and reference that here.
|
||||
# See https://kubernetes.io/docs/concepts/services-networking/service/#externalname
|
||||
name: ak-outpost-example-outpost
|
||||
port: 9000
|
||||
```
|
||||
@ -0,0 +1,40 @@
|
||||
```yaml
|
||||
http:
|
||||
middlewares:
|
||||
authentik:
|
||||
forwardAuth:
|
||||
address: http://outpost.company:9000/outpost.goauthentik.io/auth/traefik
|
||||
trustForwardHeader: true
|
||||
authResponseHeaders:
|
||||
- X-authentik-username
|
||||
- X-authentik-groups
|
||||
- X-authentik-email
|
||||
- X-authentik-name
|
||||
- X-authentik-uid
|
||||
- X-authentik-jwt
|
||||
- X-authentik-meta-jwks
|
||||
- X-authentik-meta-outpost
|
||||
- X-authentik-meta-provider
|
||||
- X-authentik-meta-app
|
||||
- X-authentik-meta-version
|
||||
routers:
|
||||
default-router:
|
||||
rule: "Host(`app.company`)"
|
||||
middlewares:
|
||||
- authentik
|
||||
priority: 10
|
||||
service: app
|
||||
default-router-auth:
|
||||
rule: "Host(`app.company`) && PathPrefix(`/outpost.goauthentik.io/`)"
|
||||
priority: 15
|
||||
service: authentik
|
||||
services:
|
||||
app:
|
||||
loadBalancer:
|
||||
servers:
|
||||
- url: http://ipp.internal
|
||||
authentik:
|
||||
loadBalancer:
|
||||
servers:
|
||||
- url: http://outpost.company:9000/outpost.goauthentik.io
|
||||
```
|
||||
@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Custom headers
|
||||
---
|
||||
|
||||
The proxy can send custom headers to your upstream application. These can be configured in one of two ways:
|
||||
|
||||
- Group attributes; this allows for inheritance, but only allows static values
|
||||
- Property mappings; this allows for dynamic values
|
||||
|
||||
## Group attributes
|
||||
|
||||
Edit the group or user you wish the header to be set for, and set these attributes:
|
||||
|
||||
```yaml
|
||||
additionalHeaders:
|
||||
X-My-Header: value
|
||||
```
|
||||
|
||||
You can the add users to this group or override the field in users.
|
||||
|
||||
## Property Mappings
|
||||
|
||||
For dynamic Header values (for example, your application requires X-App-User to contain the username), property mappings can be used.
|
||||
|
||||
Create a new Scope mapping with a name and scope of your choice, and use an expression like this:
|
||||
|
||||
```python
|
||||
return {
|
||||
"ak_proxy": {
|
||||
"user_attributes": {
|
||||
"additionalHeaders": {
|
||||
"X-App-User": request.user.username
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
After you've created this Scope mapping, make sure to edit the proxy provider and select the mapping.
|
||||
|
||||
As you can see by the similar structure, this just overrides any static attributes, so both of these methods can be combined.
|
||||
@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Forward auth
|
||||
---
|
||||
|
||||
Using forward auth uses your existing reverse proxy to do the proxying, and only uses the authentik outpost to check authentication and authorization.
|
||||
|
||||
To use forward auth instead of proxying, you have to change a couple of settings.
|
||||
In the Proxy Provider, make sure to use one of the Forward auth modes.
|
||||
|
||||
## Forward auth modes
|
||||
|
||||
The only configuration difference between single application mode and domain level mode is the host that you specify.
|
||||
|
||||
For single application, you'd use the domain that the application is running on, and only `/outpost.goauthentik.io` is redirected to the outpost.
|
||||
|
||||
For domain level, you'd use the same domain as authentik.
|
||||
|
||||
### Single application
|
||||
|
||||
Single application mode works for a single application hosted on its dedicated subdomain. This has the advantage that you can still do per-application access policies in authentik.
|
||||
|
||||
### Domain level
|
||||
|
||||
To use forward auth instead of proxying, you have to change a couple of settings.
|
||||
In the Proxy Provider, make sure to use the _Forward auth (domain level)_ mode.
|
||||
|
||||
This mode differs from the _Forward auth (single application)_ mode in the following points:
|
||||
|
||||
- You don't have to configure an application in authentik for each domain
|
||||
- Users don't have to authorize multiple times
|
||||
|
||||
There are, however, also some downsides, mainly the fact that you **can't** restrict individual applications to different users.
|
||||
|
||||
## Configuration templates
|
||||
|
||||
For configuration templates for each web server, refer to the following:
|
||||
|
||||
import DocCardList from "@theme/DocCardList";
|
||||
|
||||
<DocCardList />
|
||||
@ -0,0 +1,52 @@
|
||||
---
|
||||
title: Header authentication
|
||||
---
|
||||
|
||||
## Sending authentication
|
||||
|
||||
### Send HTTP Basic authentication
|
||||
|
||||
Proxy providers have the option to _Send HTTP-Basic Authentication_ to the upstream authentication. When the option in the provider is enabled, two attributes must be specified. These attributes are the keys of values which can be saved on a user or group level that contain the credentials.
|
||||
|
||||
For example, with _HTTP-Basic Username Key_ set to `app_username` and _HTTP-Basic Password Key_ set to `app_password`, these attributes would have to be set either on a user or a group the user is member of:
|
||||
|
||||
```yaml
|
||||
app_username: admin
|
||||
app_password: admin-password
|
||||
```
|
||||
|
||||
These credentials are only retrieved when the user authenticates to the proxy.
|
||||
|
||||
If the user does not have a matching attribute, authentik falls back to using the user's email address as username, and the password will be empty if not found.
|
||||
|
||||
## Receiving authentication
|
||||
|
||||
By default, when _Intercept header authentication_ is enabled, authentik will intercept the authorization header. If the authorization header value is invalid, an error response will be shown with a 401 status code. Requests without an authorization header will still be redirected to the standard login flow.
|
||||
|
||||
If the proxied application requires usage of the "Authorization" header, the setting should be disabled. When this setting is disabled, authentik will still attempt to interpret the "Authorization" header, and fall back to the default behaviour if it can't.
|
||||
|
||||
### Receiving HTTP Basic authentication <span class="badge badge--version">authentik 2023.1+</span>
|
||||
|
||||
Proxy providers can receive HTTP basic authentication credentials. The password is expected to be an _App password_, as the credentials are used internally with the [OAuth2 machine-to-machine authentication flow](../oauth2/client_credentials.md).
|
||||
|
||||
Access control is done with the policies bound to the application being accessed.
|
||||
|
||||
If the received credentials are invalid, a normal authentication flow is initiated. If the credentials are correct, the Authorization header is removed to prevent sending the credentials to the proxied application.
|
||||
|
||||
:::danger
|
||||
It is **strongly** recommended that the client sending requests with HTTP-Basic authentication persists the cookies returned by the outpost. If this is not the case, every request must be authenticated independently, which will increase load on the authentik server and encounter a performance hit.
|
||||
:::
|
||||
|
||||
Starting with authentik 2023.2, logging in with the reserved username `goauthentik.io/token` will behave as if a bearer token was used. All the same options as below apply. This is to allow token-based authentication for applications which might only support basic authentication.
|
||||
|
||||
### Receiving HTTP Bearer authentication <span class="badge badge--version">authentik 2023.1+</span>
|
||||
|
||||
Proxy providers can receive HTTP bearer authentication credentials. The token is expected to be a JWT token issued for the proxy provider. This is described [here](../oauth2/client_credentials.md), using the _client_id_ value shown in the admin interface. Both static and JWT authentication methods are supported.
|
||||
|
||||
Access control is done with the policies bound to the application being accessed.
|
||||
|
||||
If the received credentials are invalid, a normal authentication flow is initiated. If the credentials are correct, the Authorization header is removed to prevent sending the credentials to the proxied application.
|
||||
|
||||
:::caution
|
||||
It is recommended that the client sending requests with HTTP-Bearer authentication persists the cookies returned by the outpost. For bearer authentication this has a smaller impact than for Basic authentication, but each request is still verified with the authentik server.
|
||||
:::
|
||||
148
website/docs/add-secure-apps/providers/proxy/index.md
Normal file
148
website/docs/add-secure-apps/providers/proxy/index.md
Normal file
@ -0,0 +1,148 @@
|
||||
---
|
||||
title: Proxy Provider
|
||||
---
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant u as User accesses service
|
||||
participant rp as Reverse proxy
|
||||
participant ak as authentik
|
||||
participant s as Service
|
||||
|
||||
u->>rp: Initial request
|
||||
rp->>ak: Checks authentication
|
||||
alt User is authenticated
|
||||
ak ->> rp: Successful response
|
||||
rp ->> s: Initial request is forwarded
|
||||
else User needs to be authenticated
|
||||
ak ->> rp: Redirect to the login page
|
||||
rp ->> u: Redirect is passed to enduser
|
||||
end
|
||||
```
|
||||
|
||||
## Headers
|
||||
|
||||
The proxy outpost sets the following user-specific headers:
|
||||
|
||||
### `X-authentik-username`
|
||||
|
||||
Example value: `akadmin`
|
||||
|
||||
The username of the currently logged in user
|
||||
|
||||
### `X-authentik-groups`
|
||||
|
||||
Example value: `foo|bar|baz`
|
||||
|
||||
The groups the user is member of, separated by a pipe
|
||||
|
||||
### `X-authentik-email`
|
||||
|
||||
Example value: `root@localhost`
|
||||
|
||||
The email address of the currently logged in user
|
||||
|
||||
### `X-authentik-name`
|
||||
|
||||
Example value: `authentik Default Admin`
|
||||
|
||||
Full name of the current user
|
||||
|
||||
### `X-authentik-uid`
|
||||
|
||||
Example value: `900347b8a29876b45ca6f75722635ecfedf0e931c6022e3a29a8aa13fb5516fb`
|
||||
|
||||
The hashed identifier of the currently logged in user.
|
||||
|
||||
Besides these user-specific headers, some application specific headers are also set:
|
||||
|
||||
### `X-authentik-meta-outpost`
|
||||
|
||||
Example value: `authentik Embedded Outpost`
|
||||
|
||||
The authentik outpost's name.
|
||||
|
||||
### `X-authentik-meta-provider`
|
||||
|
||||
Example value: `test`
|
||||
|
||||
The authentik provider's name.
|
||||
|
||||
### `X-authentik-meta-app`
|
||||
|
||||
Example value: `test`
|
||||
|
||||
The authentik application's slug.
|
||||
|
||||
### `X-authentik-meta-version`
|
||||
|
||||
Example value: `goauthentik.io/outpost/1.2.3`
|
||||
|
||||
The authentik outpost's version.
|
||||
|
||||
### `X-Forwarded-Host`
|
||||
|
||||
:::info
|
||||
Only set in proxy mode
|
||||
:::
|
||||
|
||||
The original Host header sent by the client. This is set as the `Host` header is set to the host of the configured backend.
|
||||
|
||||
### Additional headers
|
||||
|
||||
Additionally, you can set `additionalHeaders` attribute on groups or users to set additional headers:
|
||||
|
||||
```yaml
|
||||
additionalHeaders:
|
||||
X-test-header: test-value
|
||||
```
|
||||
|
||||
## HTTPS
|
||||
|
||||
The outpost listens on both 9000 for HTTP and 9443 for HTTPS.
|
||||
|
||||
:::info
|
||||
If your upstream host is HTTPS, and you're not using forward auth, you need to access the outpost over HTTPS too.
|
||||
:::
|
||||
|
||||
## Logging out
|
||||
|
||||
Login is done automatically when you visit the domain without a valid cookie.
|
||||
|
||||
When using single-application mode, navigate to `app.domain.tld/outpost.goauthentik.io/sign_out`.
|
||||
|
||||
When using domain-level mode, navigate to `auth.domain.tld/outpost.goauthentik.io/sign_out`, where auth.domain.tld is the external host configured for the provider.
|
||||
|
||||
To log out, navigate to `/outpost.goauthentik.io/sign_out`.
|
||||
|
||||
Starting with authentik 2023.2, when logging out of a provider, all the users sessions within the respective outpost are invalidated.
|
||||
|
||||
## Allowing unauthenticated requests
|
||||
|
||||
To allow un-authenticated requests to certain paths/URLs, you can use the _Unauthenticated URLs_ / _Unauthenticated Paths_ field.
|
||||
|
||||
Each new line is interpreted as a regular expression, and is compiled and checked using the standard Golang regex parser.
|
||||
|
||||
The behaviour of this field changes depending on which mode you're in.
|
||||
|
||||
### Proxy and Forward auth (single application)
|
||||
|
||||
In this mode, the regular expressions are matched against the Request's Path.
|
||||
|
||||
### Forward auth (domain level)
|
||||
|
||||
In this mode, the regular expressions are matched against the Request's full URL.
|
||||
|
||||
## Dynamic backend selection
|
||||
|
||||
You can configure the backend the proxy should access dynamically via _Scope mappings_. To do so, create a new _Scope mapping_, with a name and scope of your choice. As expression, use this:
|
||||
|
||||
```python
|
||||
return {
|
||||
"ak_proxy": {
|
||||
"backend_override": f"http://foo.bar.baz/{request.user.username}"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Afterwards, edit the _Proxy provider_ and add this new mapping. The expression is only evaluated when the user logs into the application.
|
||||
@ -0,0 +1,24 @@
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
# Caddy <span class="badge badge--version">authentik 2022.8+</span>
|
||||
|
||||
The configuration template shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
|
||||
<Placeholders />
|
||||
|
||||
<Tabs
|
||||
defaultValue="caddy-standalone"
|
||||
values={[
|
||||
{label: 'Caddy (standalone)', value: 'caddy-standalone'},
|
||||
]}>
|
||||
<TabItem value="caddy-standalone">
|
||||
|
||||
import CaddyStandalone from "./_caddy_standalone.md";
|
||||
|
||||
<CaddyStandalone />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@ -0,0 +1,28 @@
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
# Envoy <span class="badge badge--version">authentik 2022.6+</span>
|
||||
|
||||
The configuration template shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
:::info
|
||||
If you are using Istio and Kubernetes, use the port number that is exposed for your cluster.
|
||||
:::
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
|
||||
<Placeholders />
|
||||
|
||||
<Tabs
|
||||
defaultValue="envoy-istio"
|
||||
values={[
|
||||
{label: 'Envoy (Istio)', value: 'envoy-istio'},
|
||||
]}>
|
||||
<TabItem value="envoy-istio">
|
||||
|
||||
import EnvoyIstio from "./_envoy_istio.md";
|
||||
|
||||
<EnvoyIstio />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@ -0,0 +1,40 @@
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
# nginx
|
||||
|
||||
The configuration templates shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
|
||||
<Placeholders />
|
||||
|
||||
<Tabs
|
||||
defaultValue="standalone-nginx"
|
||||
values={[
|
||||
{label: 'Standalone nginx', value: 'standalone-nginx'},
|
||||
{label: 'Ingress', value: 'ingress'},
|
||||
{label: 'Nginx Proxy Manager', value: 'proxy-manager'},
|
||||
]}>
|
||||
<TabItem value="standalone-nginx">
|
||||
|
||||
import NginxStandalone from "./_nginx_standalone.md";
|
||||
|
||||
<NginxStandalone />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="ingress">
|
||||
|
||||
import NginxIngress from "./_nginx_ingress.md";
|
||||
|
||||
<NginxIngress />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="proxy-manager">
|
||||
|
||||
import NginxProxyManager from "./_nginx_proxy_manager.md";
|
||||
|
||||
<NginxProxyManager />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@ -0,0 +1,40 @@
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
# Traefik
|
||||
|
||||
The configuration templates shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
|
||||
<Placeholders />
|
||||
|
||||
<Tabs
|
||||
defaultValue="standalone-traefik"
|
||||
values={[
|
||||
{label: 'Standalone traefik', value: 'standalone-traefik'},
|
||||
{label: 'docker-compose', value: 'docker-compose'},
|
||||
{label: 'Ingress', value: 'ingress'},
|
||||
]}>
|
||||
<TabItem value="standalone-traefik">
|
||||
|
||||
import TraefikStandalone from "./_traefik_standalone.md";
|
||||
|
||||
<TraefikStandalone />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="docker-compose">
|
||||
|
||||
import TraefikCompose from "./_traefik_compose.md";
|
||||
|
||||
<TraefikCompose />
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="ingress">
|
||||
|
||||
import TraefikIngress from "./_traefik_ingress.md";
|
||||
|
||||
<TraefikIngress />
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user