website: Use Docusaurus Frontmatter for badges (#12893)
website/docs: Reduce redundant usage of badges. Move badge logic to components. - Fix JSX class name warning. - Remove duplicate titles. - Flesh out `support_level` frontmatter.
This commit is contained in:
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Add an Entra ID provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
For more information about using an Entra ID provider, see the [Overview](./index.md) documentation.
|
||||
|
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Microsoft Entra ID provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
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.
|
||||
|
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Configure Entra ID
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
The configuration of your Microsoft Entra ID environment must be completed before you [add the new provider](./add-entra-provider.md) in authentik.
|
||||
|
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Create a Google Workspace provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
For more information about using a Google Workspace provider, see the [Overview](./index.md) documentation.
|
||||
|
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Google Workspace provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
With the Google Workspace provider, authentik serves as the single source of truth for all users and groups, when using Google products like Gmail.
|
||||
|
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Configure Google Workspace
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
The configuration and set up of your Google Workspace must be completed before you [add the new provider](./add-gws-provider.md) in authentik.
|
||||
|
@ -9,9 +9,9 @@ A Provider is an authentication method, a service that is used by authentik to a
|
||||
|
||||
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).
|
||||
Applications can use additional providers to augment the functionality of the main provider. For more information, see [Backchannel providers](../applications/manage_apps.mdx#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.
|
||||
You can create a new provider in the Admin interface, or you can use the [Application wizard](../applications/manage_apps.mdx#instructions) to create a new application and its provider at the same time.
|
||||
|
||||
When you create certain types of providers, you need to select specific [flows](../flows-stages/flow/index.md) to apply to users who access authentik via the provider. To learn more, refer to our [default flow documentation](../flows-stages/flow/examples/default_flows.md).
|
||||
|
||||
|
@ -78,9 +78,9 @@ All bind modes rely on flows.
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [Identification](../../flows-stages/stages/identification/index.md)
|
||||
- [Identification](../../flows-stages/stages/identification/index.mdx)
|
||||
- [Password](../../flows-stages/stages/password/index.md)
|
||||
- [Authenticator validation](../../flows-stages/stages/authenticator_validate/index.md)
|
||||
- [Authenticator validation](../../flows-stages/stages/authenticator_validate/index.mdx)
|
||||
|
||||
Note: Authenticator validation currently only supports DUO, TOTP and static authenticators.
|
||||
|
||||
|
@ -30,7 +30,7 @@ In addition to that, with authentik 2024.4 it is also possible to pass the confi
|
||||
|
||||
### JWT-authentication
|
||||
|
||||
#### Externally issued JWTs <span class="badge badge--version">authentik 2022.4+</span>
|
||||
#### Externally issued JWTs
|
||||
|
||||
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.
|
||||
|
||||
@ -59,7 +59,7 @@ To dynamically limit access based on the claims of the tokens, you can use _[Exp
|
||||
return request.context["oauth_jwt"]["iss"] == "https://my.issuer"
|
||||
```
|
||||
|
||||
#### authentik-issued JWTs <span class="badge badge--version">authentik 2024.12+</span>
|
||||
#### authentik-issued JWTs:ak-version[2024.12]
|
||||
|
||||
To allow federation between providers, modify the provider settings of the application (whose token will be used for authentication) to select the provider of the application to which you want to federate.
|
||||
|
@ -112,7 +112,7 @@ The Hybrid Flow is an OpenID Connect flow that incorporates traits of both the I
|
||||
|
||||
The client credentials flow and grant types are typically implemented for server-to-server scenarios, when code in a web application invokes a web API.
|
||||
|
||||
For more information, see [Machine-to-machine authentication](./client_credentials.md).
|
||||
For more information, see [Machine-to-machine authentication](./client_credentials.mdx).
|
||||
|
||||
### 3. Device code
|
||||
|
||||
@ -176,6 +176,6 @@ When a _Signing Key_ is selected in the provider, the JWT will be signed asymmet
|
||||
|
||||
When no _Signing Key_ is selected, the JWT will be signed symmetrically with the _Client secret_ of the provider, which can be seen in the provider settings.
|
||||
|
||||
### Encryption <span class="badge badge--version">authentik 2024.10+</span>
|
||||
### Encryption:ak-version[2024.10]
|
||||
|
||||
authentik can also encrypt JWTs (turning them into JWEs) it issues by selecting an _Encryption Key_ in the provider. When selected, all JWTs will be encrypted symmetrically using the selected certificate. authentik uses the `RSA-OAEP-256` algorithm with the `A256CBC-HS512` encryption method.
|
@ -6,7 +6,7 @@ The property mapping should return a value that is expected by the provider. Sup
|
||||
|
||||
## Available Functions
|
||||
|
||||
import Functions from "../../../expressions/_functions.md";
|
||||
import Functions from "../../../expressions/_functions.mdx";
|
||||
|
||||
<Functions />
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
Use the following configuration:
|
||||
|
||||
```
|
||||
```apacheconf
|
||||
app.company {
|
||||
# directive execution order is only as stated if enclosed with route.
|
||||
route {
|
||||
@ -26,7 +26,7 @@ app.company {
|
||||
|
||||
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.
|
||||
|
||||
```
|
||||
```conf
|
||||
reverse_proxy /outpost.goauthentik.io/* https://outpost.company {
|
||||
header_up Host {http.reverse_proxy.upstream.hostport}
|
||||
}
|
||||
|
@ -1,4 +1,4 @@
|
||||
```
|
||||
```nginx
|
||||
# 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
|
||||
|
@ -1,4 +1,4 @@
|
||||
```
|
||||
```nginx
|
||||
# Upgrade WebSocket if requested, otherwise use keepalive
|
||||
map $http_upgrade $connection_upgrade_keepalive {
|
||||
default upgrade;
|
||||
|
@ -25,9 +25,9 @@ By default, when _Intercept header authentication_ is enabled, authentik will in
|
||||
|
||||
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>
|
||||
### Receiving HTTP Basic authentication
|
||||
|
||||
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).
|
||||
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.mdx).
|
||||
|
||||
Access control is done with the policies bound to the application being accessed.
|
||||
|
||||
@ -39,9 +39,9 @@ It is **strongly** recommended that the client sending requests with HTTP-Basic
|
||||
|
||||
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>
|
||||
### Receiving HTTP Bearer authentication
|
||||
|
||||
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.
|
||||
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.mdx), 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.
|
||||
|
@ -1,17 +1,14 @@
|
||||
---
|
||||
title: Caddy
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
# Caddy <span class="badge badge--version">authentik 2022.8+</span>
|
||||
import Placeholders from "./__placeholders.md";
|
||||
import CaddyStandalone from "./_caddy_standalone.md";
|
||||
|
||||
The configuration template shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
import Placeholders from "./__placeholders.md";
|
||||
|
||||
<Placeholders />
|
||||
|
||||
<Tabs
|
||||
@ -21,8 +18,6 @@ import Placeholders from "./__placeholders.md";
|
||||
]}>
|
||||
<TabItem value="caddy-standalone">
|
||||
|
||||
import CaddyStandalone from "./_caddy_standalone.md";
|
||||
|
||||
<CaddyStandalone />
|
||||
|
||||
</TabItem>
|
||||
|
@ -1,12 +1,13 @@
|
||||
---
|
||||
title: Envoy
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
import Placeholders from "./__placeholders.md";
|
||||
import EnvoyIstio from "./_envoy_istio.md";
|
||||
|
||||
# Envoy <span class="badge badge--version">authentik 2022.6+</span>
|
||||
# Envoy
|
||||
|
||||
The configuration template shown below apply to both single-application and domain-level forward auth.
|
||||
|
||||
@ -14,20 +15,18 @@ The configuration template shown below apply to both single-application and doma
|
||||
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>
|
||||
defaultValue="envoy-istio"
|
||||
values={[
|
||||
{
|
||||
label: "Envoy (Istio)",
|
||||
value: "envoy-istio",
|
||||
},
|
||||
]}
|
||||
>
|
||||
<TabItem value="envoy-istio">
|
||||
<EnvoyIstio />
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
@ -26,7 +26,7 @@ The first step is to create the RAC app and provider.
|
||||
|
||||
2. In the Admin interface, navigate to **Applications -> Applications**.
|
||||
|
||||
3. Click **Create with Wizard**. Follow the [instructions](../../applications/manage_apps.md#instructions) to create your RAC application and provider.
|
||||
3. Click **Create with Wizard**. Follow the [instructions](../../applications/manage_apps.mdx#instructions) to create your RAC application and provider.
|
||||
|
||||
### Step 2. Create RAC property mapping
|
||||
|
||||
|
@ -1,9 +1,6 @@
|
||||
---
|
||||
title: Remote Access Control (RAC) Provider
|
||||
---
|
||||
|
||||
<span class="badge badge--primary">Enterprise</span>
|
||||
|
||||
authentik_enterprise: true
|
||||
---
|
||||
|
||||
:::info
|
||||
|
@ -18,9 +18,9 @@ Authentication requests against the Radius Server use a flow in the background.
|
||||
|
||||
The following stages are supported:
|
||||
|
||||
- [Identification](../../flows-stages/stages/identification/index.md)
|
||||
- [Identification](../../flows-stages/stages/identification/index.mdx)
|
||||
- [Password](../../flows-stages/stages/password/index.md)
|
||||
- [Authenticator validation](../../flows-stages/stages/authenticator_validate/index.md)
|
||||
- [Authenticator validation](../../flows-stages/stages/authenticator_validate/index.mdx)
|
||||
|
||||
Note: Authenticator validation currently only supports DUO, TOTP, and static authenticators.
|
||||
|
||||
|
Reference in New Issue
Block a user