website: Bump prettier from 3.3.3 to 3.4.1 in /website (#12205)
* website: Bump prettier from 3.3.3 to 3.4.1 in /website Bumps [prettier](https://github.com/prettier/prettier) from 3.3.3 to 3.4.1. - [Release notes](https://github.com/prettier/prettier/releases) - [Changelog](https://github.com/prettier/prettier/blob/main/CHANGELOG.md) - [Commits](https://github.com/prettier/prettier/compare/3.3.3...3.4.1) --- updated-dependencies: - dependency-name: prettier dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> * update formatting Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sigh Signed-off-by: Jens Langhammer <jens@goauthentik.io> * disable flaky test Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
This commit is contained in:
@ -24,15 +24,15 @@ As detailed in the steps below, when you add an Entra ID provider in authentik y
|
||||
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".
|
||||
- **Name**: define a descriptive name, such as "Entra provider".
|
||||
|
||||
- **Protocol settings**
|
||||
- **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.
|
||||
- **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**
|
||||
|
||||
|
||||
@ -9,8 +9,8 @@ title: Microsoft Entra ID provider
|
||||
|
||||
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).
|
||||
- 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
|
||||
|
||||
@ -38,10 +38,10 @@ When a property mapping has an invalid expression, it will cause the sync to sto
|
||||
|
||||
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.
|
||||
- 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
|
||||
- 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
|
||||
|
||||
@ -9,8 +9,8 @@ title: Google Workspace provider
|
||||
|
||||
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).
|
||||
- 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
|
||||
|
||||
@ -38,13 +38,13 @@ When a property mapping has an invalid expression, it will cause the sync to sto
|
||||
|
||||
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 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.
|
||||
- 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.
|
||||
- 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
|
||||
- https://developers.google.com/admin-sdk/directory/reference/rest/v1/users#User
|
||||
- https://developers.google.com/admin-sdk/directory/reference/rest/v1/groups#Group
|
||||
|
||||
@ -36,9 +36,9 @@ For detailed instructions, refer to Google documentation.
|
||||
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.
|
||||
- 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
|
||||
|
||||
|
||||
@ -22,30 +22,30 @@ Note: Every LDAP provider needs to have a unique base DN. You can achieve this b
|
||||
|
||||
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"
|
||||
- `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"
|
||||
- `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.
|
||||
@ -78,9 +78,9 @@ 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)
|
||||
- [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.
|
||||
|
||||
@ -90,9 +90,9 @@ The following stages are supported:
|
||||
|
||||
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)
|
||||
- [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
|
||||
|
||||
|
||||
@ -25,12 +25,12 @@ 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
|
||||
- `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
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -68,14 +68,14 @@ return True
|
||||
|
||||
#### 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.
|
||||
- `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
|
||||
- `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>
|
||||
|
||||
|
||||
@ -20,5 +20,5 @@ 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.
|
||||
- `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.
|
||||
|
||||
@ -4,8 +4,8 @@ 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; this allows for inheritance, but only allows static values
|
||||
- Property mappings; this allows for dynamic values
|
||||
|
||||
## Group attributes
|
||||
|
||||
|
||||
@ -26,8 +26,8 @@ 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
|
||||
- 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.
|
||||
|
||||
|
||||
@ -56,6 +56,6 @@ A new connection is created every time an endpoint is selected in the [User Inte
|
||||
|
||||
The following features are currently supported:
|
||||
|
||||
- Bi-directional clipboard
|
||||
- Audio redirection (from remote machine to browser)
|
||||
- Resizing
|
||||
- Bi-directional clipboard
|
||||
- Audio redirection (from remote machine to browser)
|
||||
- Resizing
|
||||
|
||||
@ -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)
|
||||
- [Password](../../flows-stages/stages/password/index.md)
|
||||
- [Authenticator validation](../../flows-stages/stages/authenticator_validate/index.md)
|
||||
- [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.
|
||||
|
||||
@ -28,9 +28,9 @@ The following stages are supported:
|
||||
|
||||
SMS-based authenticators are not supported because 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)
|
||||
- [User Logout](../../flows-stages/stages/user_logout.md)
|
||||
- [User Login](../../flows-stages/stages/user_login/index.md)
|
||||
- [Deny](../../flows-stages/stages/deny.md)
|
||||
|
||||
### RADIUS attributes
|
||||
|
||||
|
||||
@ -22,11 +22,11 @@ The metadata download link can also be copied with a button on the provider over
|
||||
|
||||
You can select a custom SAML Property Mapping after which the NameID field will be generated. If left default, the following checks are done:
|
||||
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`, the NameID will be set to the hashed user ID.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:X509SubjectName`, the NameID will be set to the user's `distinguishedName` attribute. This attribute is set by the LDAP source by default. If the attribute does not exist, it will fall back the persistent identifier.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:WindowsDomainQualifiedName`, the NameID will be set to the user's UPN. This is also set by the LDAP source, and also falls back to the persistent identifier.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`, the NameID will be set based on the user's session ID.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`, the NameID will be set to the user's email address.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`, the NameID will be set to the hashed user ID.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:X509SubjectName`, the NameID will be set to the user's `distinguishedName` attribute. This attribute is set by the LDAP source by default. If the attribute does not exist, it will fall back the persistent identifier.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:WindowsDomainQualifiedName`, the NameID will be set to the user's UPN. This is also set by the LDAP source, and also falls back to the persistent identifier.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`, the NameID will be set based on the user's session ID.
|
||||
- When the request asks for `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`, the NameID will be set to the user's email address.
|
||||
|
||||
:::warning
|
||||
Keep in mind that with the default settings, users are free to change their email addresses. As such it is recommended to use `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`, as this cannot be changed.
|
||||
|
||||
@ -20,8 +20,8 @@ When adding the SCIM provider, you must define the **Backchannel provider using
|
||||
|
||||
Data is synchronized in multiple ways:
|
||||
|
||||
- When a user/group is created/modified/deleted, that action is sent to all SCIM providers
|
||||
- Periodically (once an hour), all SCIM providers are fully synchronized
|
||||
- When a user/group is created/modified/deleted, that action is sent to all SCIM providers
|
||||
- Periodically (once an hour), all SCIM providers are fully synchronized
|
||||
|
||||
The actual synchronization process is run in the authentik worker. To allow this process to better to scale, a task is started for each 100 users and groups, so when multiple workers are available the workload will be distributed.
|
||||
|
||||
@ -39,7 +39,7 @@ By default, service accounts are excluded from being synchronized. This can be c
|
||||
|
||||
SCIM defines multiple optional features, some of which are supported by the SCIM provider.
|
||||
|
||||
- Patch updates
|
||||
- Patch updates
|
||||
|
||||
If the service provider supports patch updates, authentik will use patch requests to add/remove members of groups. For all other updates, such as user updates and other group updates, PUT requests are used.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user