website: format docs with prettier (#2833)
* run prettier Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add scim to comparison Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
This commit is contained in:
@ -9,42 +9,41 @@ Applications are used to configure and separate the authorization / access contr
|
||||
|
||||
## 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.
|
||||
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
|
||||
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)
|
||||
- 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)
|
||||
|
||||
## Appearance
|
||||
|
||||
The following aspects 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
|
||||
- _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
|
||||
|
||||
Starting with authentik 2022.2, you can use placeholders in the launch url to build them dynamically based on 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.
|
||||
|
||||
- *Icon (URL)*: Optionally configure an Icon for the application
|
||||
- _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`, 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
|
||||
- _Publisher_: Text shown below the application
|
||||
- _Description_: Subtext shown on the application card below the publisher
|
||||
|
||||
Applications are shown 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 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://
|
||||
|
||||
#### Hiding applications
|
||||
|
||||
To hide applications without modifying policy settings and without removing it, you can simply set the *Launch URL* to `blank://blank`, which will hide the application from users.
|
||||
To hide applications without modifying policy settings and without removing it, you can simply set the _Launch URL_ to `blank://blank`, which will hide the application from users.
|
||||
|
||||
Keep in mind, the users still have access, so they can still authorize access when the login process is started from the application.
|
||||
|
||||
|
||||
@ -4,15 +4,15 @@ title: Certificates
|
||||
|
||||
Certificates in authentik are used for the following use cases:
|
||||
|
||||
- Signing and verifying SAML Requests and Responses
|
||||
- Signing JSON Web Tokens for OAuth and OIDC
|
||||
- Connecting to remote docker hosts using the Docker integration
|
||||
- Verifying LDAP Servers' certificates
|
||||
- Encrypting outposts's endpoints
|
||||
- Signing and verifying SAML Requests and Responses
|
||||
- Signing JSON Web Tokens for OAuth and OIDC
|
||||
- Connecting to remote docker hosts using the Docker integration
|
||||
- Verifying LDAP Servers' certificates
|
||||
- Encrypting outposts's endpoints
|
||||
|
||||
## Default certificate
|
||||
|
||||
Every authentik install generates a self-signed certificate on the first start. The certificate is called *authentik Self-signed Certificate* and is valid for 1 year.
|
||||
Every authentik install generates a self-signed certificate on the first start. The certificate is called _authentik Self-signed Certificate_ and is valid for 1 year.
|
||||
|
||||
This certificate is generated to be used as a default for all OAuth2/OIDC providers, as these don't require the certificate to be configured on both sides (the signature of a JWT is validated using the [JWKS](https://auth0.com/docs/security/tokens/json-web-tokens/json-web-key-sets) URL).
|
||||
|
||||
@ -30,7 +30,7 @@ For Kubernetes, you can map custom secrets/volumes under `/certs`.
|
||||
|
||||
You can also bind mount single files into the folder, as long as they fall under this naming schema.
|
||||
|
||||
- Files in the root directory will be imported based on their filename.
|
||||
- Files in the root directory will be imported based on their filename.
|
||||
|
||||
`/foo.pem` Will be imported as the keypair `foo`. Based on its content its either imported as certificate or private key.
|
||||
|
||||
@ -38,9 +38,9 @@ You can also bind mount single files into the folder, as long as they fall under
|
||||
|
||||
Otherwise it will be imported as certificate.
|
||||
|
||||
- If the file is called `fullchain.pem` or `privkey.pem` (the output naming of certbot), they will get the name of the parent folder.
|
||||
- Files can be in any arbitrary file structure, and can have any extension.
|
||||
- If the path contains `archive`, the files will be ignored (to better support certbot setups).
|
||||
- If the file is called `fullchain.pem` or `privkey.pem` (the output naming of certbot), they will get the name of the parent folder.
|
||||
- Files can be in any arbitrary file structure, and can have any extension.
|
||||
- If the path contains `archive`, the files will be ignored (to better support certbot setups).
|
||||
|
||||
```
|
||||
certs/
|
||||
@ -66,29 +66,29 @@ Starting with authentik 2021.12.4, you can configure the certificate authentik u
|
||||
To use let's encrypt certificates with this setup, using certbot, you can use this compose override (create or edit a file called `docker-compose.override.yml` in the same folder as the authentik docker-compose file)
|
||||
|
||||
```yaml
|
||||
version: '3.2'
|
||||
version: "3.2"
|
||||
|
||||
services:
|
||||
certbot:
|
||||
image: certbot/dns-route53:v1.22.0
|
||||
volumes:
|
||||
- ./letsencrypt:/etc/letsencrypt
|
||||
- ../authentik/certs/:/etc/letsencrypt/live
|
||||
# Variables depending on DNS Plugin
|
||||
environment:
|
||||
AWS_ACCESS_KEY_ID: ...
|
||||
command:
|
||||
- certonly
|
||||
- --non-interactive
|
||||
- --agree-tos
|
||||
- -m your.email@company
|
||||
- -d authentik.company
|
||||
# Again, match with your provider
|
||||
- --dns-route53
|
||||
certbot:
|
||||
image: certbot/dns-route53:v1.22.0
|
||||
volumes:
|
||||
- ./letsencrypt:/etc/letsencrypt
|
||||
- ../authentik/certs/:/etc/letsencrypt/live
|
||||
# Variables depending on DNS Plugin
|
||||
environment:
|
||||
AWS_ACCESS_KEY_ID: ...
|
||||
command:
|
||||
- certonly
|
||||
- --non-interactive
|
||||
- --agree-tos
|
||||
- -m your.email@company
|
||||
- -d authentik.company
|
||||
# Again, match with your provider
|
||||
- --dns-route53
|
||||
```
|
||||
|
||||
Afterwards, run `docker-compose up -d`, which will start certbot and generate your certificate. Within a few minutes, you'll see the certificate in your authentik interface. (If the certificate does not appear, restart the worker container. This is caused by incompatible permissions set by certbot).
|
||||
|
||||
Navigate to *System -> Tenants*, edit any tenant and select the certificate of your choice.
|
||||
Navigate to _System -> Tenants_, edit any tenant and select the certificate of your choice.
|
||||
|
||||
Keep in mind this certbot container will only run once, but there are a variety of ways to schedule regular renewals.
|
||||
|
||||
Reference in New Issue
Block a user