Compare commits

..

1 Commits

Author SHA1 Message Date
James Elliott c7cc70d6a8
refactor: move auth_request_set in nginx
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
2023-05-01 13:36:25 +10:00
376 changed files with 9404 additions and 24986 deletions

View File

@ -6,9 +6,9 @@ DIVERGED=$(git merge-base --fork-point origin/master > /dev/null; echo $?)
if [[ "${DIVERGED}" == 0 ]]; then
if [[ "${BUILDKITE_TAG}" == "" ]]; then
if [[ "${BUILDKITE_BRANCH}" == "master" ]]; then
CI_BYPASS=$(git diff --name-only HEAD~1 | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|cmd\/authelia-gen\/templates\/.*|examples\/.*)/!{q1}' && echo true || echo false)
CI_BYPASS=$(git diff --name-only HEAD~1 | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|examples\/.*)/!{q1}' && echo true || echo false)
else
CI_BYPASS=$(git diff --name-only `git merge-base --fork-point origin/master` | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|cmd\/authelia-gen\/templates\/.*|examples\/.*)/!{q1}' && echo true || echo false)
CI_BYPASS=$(git diff --name-only `git merge-base --fork-point origin/master` | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|examples\/.*)/!{q1}' && echo true || echo false)
fi
else
CI_BYPASS="false"

View File

@ -9,12 +9,12 @@ if [[ "${DIVERGED}" == 0 ]]; then
BUILD_DUO=$(git diff --name-only HEAD~1 | grep -q ^internal/suites/example/compose/duo-api/Dockerfile && echo true || echo false)
BUILD_HAPROXY=$(git diff --name-only HEAD~1 | grep -q ^internal/suites/example/compose/haproxy/Dockerfile && echo true || echo false)
BUILD_SAMBA=$(git diff --name-only HEAD~1 | grep -q ^internal/suites/example/compose/samba/Dockerfile && echo true || echo false)
CI_BYPASS=$(git diff --name-only HEAD~1 | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|cmd\/authelia-gen\/templates\/.*|examples\/.*)/!{q1}' && echo true || echo false)
CI_BYPASS=$(git diff --name-only HEAD~1 | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|examples\/.*)/!{q1}' && echo true || echo false)
else
BUILD_DUO=$(git diff --name-only `git merge-base --fork-point origin/master` | grep -q ^internal/suites/example/compose/duo-api/Dockerfile && echo true || echo false)
BUILD_HAPROXY=$(git diff --name-only `git merge-base --fork-point origin/master` | grep -q ^internal/suites/example/compose/haproxy/Dockerfile && echo true || echo false)
BUILD_SAMBA=$(git diff --name-only `git merge-base --fork-point origin/master` | grep -q ^internal/suites/example/compose/samba/Dockerfile && echo true || echo false)
CI_BYPASS=$(git diff --name-only `git merge-base --fork-point origin/master` | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|cmd\/authelia-gen\/templates\/.*|examples\/.*)/!{q1}' && echo true || echo false)
CI_BYPASS=$(git diff --name-only `git merge-base --fork-point origin/master` | sed -rn '/^(CODE_OF_CONDUCT\.md|CONTRIBUTING\.md|README\.md|SECURITY\.md|crowdin\.yml|\.all-contributorsrc|\.editorconfig|\.github\/.*|docs\/.*|examples\/.*)/!{q1}' && echo true || echo false)
fi
if [[ "${CI_BYPASS}" == "true" ]]; then

View File

@ -7,4 +7,3 @@
!entrypoint.sh
!healthcheck.sh
!.healthcheck.env
!dist/public_html/

2
.github/FUNDING.yml vendored
View File

@ -3,7 +3,7 @@
# github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
# patreon: # Replace with a single Patreon username
open_collective: 'authelia-sponsors'
open_collective: authelia-sponsors
# ko_fi: # Replace with a single Ko-fi username
# tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
# community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry

View File

@ -1,12 +1,12 @@
---
name: 'Bug Report'
description: 'Report a bug'
name: Bug Report
description: Report a bug
labels:
- 'type/bug/unconfirmed'
- 'status/needs-triage'
- 'priority/4/normal'
- type/bug/unconfirmed
- status/needs-triage
- priority/4/normal
body:
- type: 'markdown'
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this bug report. If you are unsure if this is actually a bug and you still need some form of support we generally recommend creating a [Question and Answer Discussion](https://github.com/authelia/authelia/discussions/new?category=q-a) first.
@ -17,198 +17,161 @@ body:
2. Please try to give as much information as possible for us to be able to reproduce the issue and provide a quick fix.
3. Please ensure an issue does not already exist for this potential bug.
4. Please only provide specific versions. Latest is not a version.
5. Please only report bugs with Authelia itself. Issues which match one of the following criteria should not be reported here but should be a [discussion](https://github.com/authelia/authelia/discussions/new/choose) instead:
- Bugs with third-party software.
- Mistakes in the documentation.
- Potential bugs where it is not somewhat clear that it's a bug with Authelia itself.
6. Please read the [Troubleshooting](https://www.authelia.com/r/troubleshooting) reference guide:
- Do not truncate any logs unless you are complying with the specific instructions in the [Logs](https://www.authelia.com/r/troubleshooting#logs) section.
- If you plan on sanitizing, removing, or adjusting any values for the logs or configuration files please read the [Sanitization](https://www.authelia.com/r/troubleshooting#sanitization) section.
7. Please consider including a [HTTP Archive File](https://www.authelia.com/r/har) if you're having redirection issues.
- type: 'dropdown'
id: 'version'
5. Please read the [Troubleshooting Sanitization](https://www.authelia.com/r/sanitize) reference guide if you plan on sanitizing, removing, or adjusting any values for the logs or configuration files.
6. Please consider including a [HTTP Archive File](https://www.authelia.com/r/har) if you're having redirection issues.
- type: dropdown
id: version
attributes:
label: |
Version
description: |
What version(s) of Authelia can you reproduce this bug on?
label: Version
description: What version(s) of Authelia can you reproduce this bug on?
multiple: true
options:
- 'v4.37.5'
- 'v4.37.4'
- 'v4.37.3'
- 'v4.37.2'
- 'v4.37.1'
- 'v4.37.0'
- 'v4.36.9'
- 'v4.36.8'
- 'v4.36.7'
- 'v4.36.6'
- 'v4.36.5'
- 'v4.36.4'
- 'v4.36.3'
- 'v4.36.2'
- 'v4.36.1'
- 'v4.36.0'
- 'v4.35.6'
- 'v4.35.5'
- 'v4.35.4'
- 'v4.35.3'
- 'v4.35.2'
- 'v4.35.1'
- 'v4.35.0'
- 'v4.34.6'
- 'v4.34.5'
- 'v4.34.4'
- 'v4.34.3'
- 'v4.34.2'
- 'v4.34.1'
- 'v4.34.0'
- 'v4.33.2'
- 'v4.33.1'
- 'v4.33.0'
- 'v4.32.2'
- 'v4.32.1'
- 'v4.32.0'
- v4.37.5
- v4.37.4
- v4.37.3
- v4.37.2
- v4.37.1
- v4.37.0
- v4.36.9
- v4.36.8
- v4.36.7
- v4.36.6
- v4.36.5
- v4.36.4
- v4.36.3
- v4.36.2
- v4.36.1
- v4.36.0
- v4.35.6
- v4.35.5
- v4.35.4
- v4.35.3
- v4.35.2
- v4.35.1
- v4.35.0
- v4.34.6
- v4.34.5
- v4.34.4
- v4.34.3
- v4.34.2
- v4.34.1
- v4.34.0
- v4.33.2
- v4.33.1
- v4.33.0
- v4.32.2
- v4.32.1
- v4.32.0
validations:
required: true
- type: 'dropdown'
id: 'deployment'
- type: dropdown
id: deployment
attributes:
label: |
Deployment Method
description: |
How are you deploying Authelia?
label: Deployment Method
description: How are you deploying Authelia?
options:
- 'Docker'
- 'Kubernetes'
- 'Bare-metal'
- 'Other'
- Docker
- Kubernetes
- Bare-metal
- Other
validations:
required: true
- type: 'dropdown'
id: 'proxy'
- type: dropdown
id: proxy
attributes:
label: |
Reverse Proxy
description: |
What reverse proxy are you using?
label: Reverse Proxy
description: What reverse proxy are you using?
options:
- 'Caddy'
- 'Traefik'
- 'Envoy'
- 'Istio'
- 'NGINX'
- 'SWAG'
- 'NGINX Proxy Manager'
- 'HAProxy'
- Caddy
- Traefik
- Envoy
- Istio
- NGINX
- SWAG
- NGINX Proxy Manager
- HAProxy
validations:
required: true
- type: 'input'
id: 'proxy-version'
- type: input
id: proxy-version
attributes:
label: |
Reverse Proxy Version
description: |
What is the version of your reverse proxy?
placeholder: 'x.x.x'
label: Reverse Proxy Version
description: What is the version of your reverse proxy?
placeholder: x.x.x
validations:
required: false
- type: 'textarea'
id: 'description'
- type: textarea
id: description
attributes:
label: |
Description
description: |
Describe the bug.
label: Description
description: Describe the bug
validations:
required: true
- type: 'textarea'
id: 'reproduction'
- type: textarea
id: reproduction
attributes:
label: |
Reproduction
description: |
Describe how we can reproduce this issue. This should be step by step and should include detailed and specific information. Abstract or generic information should be avoided. For example this should include specific application names and versions if relevant. Reproducing the issue is important so we can verify it exists, add relevant tests, and verify it is solved.
label: Reproduction
description: Describe how we can reproduce this issue
validations:
required: true
- type: 'textarea'
id: 'expectations'
- type: textarea
id: expectations
attributes:
label: |
Expectations
description: |
Describe the desired or expected results.
label: Expectations
description: Describe the desired or expected results
validations:
required: false
- type: 'textarea'
id: 'configuration'
- type: textarea
id: configuration
attributes:
label: |
Configuration (Authelia)
description: |
Provide a complete configuration file (the template will automatically put this content in a code block).
render: 'yaml'
label: Configuration (Authelia)
description: Provide a complete configuration file (the template will automatically put this content in a code block)
render: yaml
validations:
required: false
- type: 'textarea'
id: 'logs'
- type: textarea
id: logs
attributes:
label: |
Logs (Authelia)
label: Logs (Authelia)
description: |
Provide complete logs with the log level set to debug or trace. Complete means from application start until the issue occurring. This is clearly explained in the [Logs](https://www.authelia.com/r/troubleshooting#logs) section of the troubleshooting guide.
The template will automatically put this content in a code block so you can just paste it.
render: 'shell'
Provide complete logs with the log level set to debug or trace. Complete means from application start until the
issue occurring. The template will automatically put this content in a code block so you can just paste it.
render: shell
validations:
required: true
- type: 'textarea'
id: 'logs-other'
- type: textarea
id: logs-other
attributes:
label: |
Logs (Proxy / Application)
description: |
Provide complete debug logs for the affected proxy and/or application if available and relevant (the template will automatically put this content in a code block).
render: 'shell'
label: Logs (Proxy / Application)
description: Provide complete debug logs for the affected proxy and/or application if available and relevant (the template will automatically put this content in a code block)
render: shell
validations:
required: false
- type: 'textarea'
id: 'documentation'
- type: textarea
id: documentation
attributes:
label: |
Documentation
description: |
Provide any relevant specification or other documentation if applicable.
label: Documentation
description: Provide any relevant specification or other documentation if applicable
validations:
required: false
- type: 'checkboxes'
id: 'checklist'
- type: checkboxes
id: checklist
attributes:
label: |
Pre-Submission Checklist
description: |
By submitting this issue confirm all of the following.
label: Pre-Submission Checklist
description: By submitting this issue confirm all of the following
options:
- label: |
I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
- label: I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
required: true
- label: |
This is a bug report and not a support request
- label: This is a bug report and not a support request
required: true
- label: |
I have read the security policy and this bug report is not a security issue or security related issue
- label: I have read the security policy and this bug report is not a security issue or security related issue
required: true
- label: |
I have either included the complete configuration file or I am sure it's unrelated to the configuration
- label: I have either included the complete configuration file or I am sure it's unrelated to the configuration
required: true
- label: |
I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the [Troubleshooting Sanitization](https://www.authelia.com/r/sanitize) reference guide
- label: I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the [Troubleshooting Sanitization](https://www.authelia.com/r/sanitize) reference guide
required: true
- label: |
I have checked for related proxy or application logs and included them if available
- label: I have checked for related proxy or application logs and included them if available
required: true
- label: |
I have checked for related issues and checked the documentation
- label: I have checked for related issues and checked the documentation
required: true
...

View File

@ -1,22 +1,22 @@
---
blank_issues_enabled: false
contact_links:
- name: 'Idea'
url: 'https://github.com/authelia/authelia/discussions/new?category=ideas'
about: 'Submit an Idea for Voting'
- name: 'Question'
url: 'https://github.com/authelia/authelia/discussions/new?category=q-a'
about: 'Ask a Question'
- name: 'Discussion'
url: 'https://github.com/authelia/authelia/discussions/new'
about: 'Start a Discussion related to Ideas, Polls, Show and Tell, or General Topics'
- name: 'Documentation'
url: 'https://www.authelia.com/'
about: 'Read the Documentation'
- name: 'Matrix'
url: 'https://matrix.to/#/#community:authelia.com'
about: 'Discuss Authelia with the Developers on Matrix which is the preferred method of contact'
- name: 'Discord'
url: 'https://discord.authelia.com'
about: 'Discuss Authelia with the Developers on Discord which is bridged to Matrix'
- name: Idea
url: https://github.com/authelia/authelia/discussions/new?category=ideas
about: Submit an Idea for Voting
- name: Question
url: https://github.com/authelia/authelia/discussions/new?category=q-a
about: Ask a Question
- name: Discussion
url: https://github.com/authelia/authelia/discussions/new
about: Start a Discussion related to Ideas, Polls, Show and Tell, or General Topics
- name: Documentation
url: https://www.authelia.com/
about: Read the Documentation
- name: Matrix
url: https://matrix.to/#/#community:authelia.com
about: Discuss Authelia with the Developers on Matrix which is the preferred method of contact
- name: Discord
url: https://discord.authelia.com
about: Discuss Authelia with the Developers on Discord which is bridged to Matrix
...

View File

@ -1,12 +1,12 @@
---
name: 'Feature Request'
description: 'Submit a Feature Request'
name: Feature Request
description: Submit a Feature Request
labels:
- 'type/feature'
- 'status/needs-design'
- 'priority/4/normal'
- type/feature
- status/needs-design
- priority/4/normal
body:
- type: 'markdown'
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this feature request. A feature request is created as issue for the purpose of tracking the design and implementation of a feature.
@ -16,54 +16,42 @@ body:
1. Ensure there are no other similar feature requests.
2. Make sure you've checked the [Documentation](https://www.authelia.com) doesn't clearly document the features existence already.
3. Consider creating an [Idea Discussion](https://github.com/authelia/authelia/discussions/new?category=ideas) which can be voted on instead if one doesn't exist.
- type: 'textarea'
id: 'description'
- type: textarea
id: description
attributes:
label: |
Description
description: |
Describe the feature
label: Description
description: Describe the feature
validations:
required: true
- type: 'textarea'
id: 'use-case'
- type: textarea
id: use-case
attributes:
label: |
Use Case
description: |
Provide a use case
label: Use Case
description: Provide a use case
validations:
required: true
- type: 'textarea'
id: 'details'
- type: textarea
id: details
attributes:
label: |
Details
description: |
Describe the feature in detail
label: Details
description: Describe the feature in detail
validations:
required: false
- type: 'textarea'
id: 'documentation'
- type: textarea
id: documentation
attributes:
label: |
Documentation
description: |
Provide any relevant specification or other documentation if applicable
label: Documentation
description: Provide any relevant specification or other documentation if applicable
validations:
required: false
- type: 'checkboxes'
id: 'checklist'
- type: checkboxes
id: checklist
attributes:
label: |
Pre-Submission Checklist
description: |
By submitting this issue confirm all of the following
label: Pre-Submission Checklist
description: By submitting this issue confirm all of the following
options:
- label: |
I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
- label: I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
required: true
- label: |
I have checked for related issues and checked the documentation
- label: I have checked for related issues and checked the documentation
required: true
...

View File

@ -11,7 +11,6 @@ yaml-files:
ignore: |
api/openapi.yml
docs/pnpm-lock.yaml
docs/node_modules/
internal/configuration/test_resources/config_bad_quoting.yml
web/pnpm-lock.yaml
web/node_modules/

View File

@ -1,7 +1,7 @@
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.18.2
FROM alpine:3.17.3
ARG TARGETOS
ARG TARGETARCH

View File

@ -15,7 +15,7 @@ RUN yarn global add pnpm && \
# =======================================
# ===== Build image for the backend =====
# =======================================
FROM golang:1.20.5-alpine AS builder-backend
FROM golang:1.20.3-alpine AS builder-backend
WORKDIR /go/src/app
@ -46,7 +46,7 @@ RUN \
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.18.2
FROM alpine:3.17.3
RUN apk --no-cache add ca-certificates tzdata

View File

@ -13,7 +13,7 @@ RUN yarn install --frozen-lockfile && yarn build
# =======================================
# ===== Build image for the backend =====
# =======================================
FROM golang:1.20.5-alpine AS builder-backend
FROM golang:1.20.3-alpine AS builder-backend
WORKDIR /go/src/app
@ -43,7 +43,7 @@ RUN \
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.18.2
FROM alpine:3.17.3
WORKDIR /app

View File

@ -1,95 +0,0 @@
# Ausführen
Um die Anwendung lokal auszuführen, können die folgenden Befehle verwendet werden.
```
export GOPATH=/tmp
source bootstrap.sh
authelia-scripts suites setup Standalone
```
Nun sollte der "Haupt-Enpunkt" unter `https://home.example.com:8080` und die API unter `https://authelia.example.com:9091` erreichbar sein. Achtung: es wird ein selbstsigniertes Zertifikat verwendet!
Mithilfe der Hot-Reload kann jetzt gecoded werden.
---
Nach der Entwicklung kann die Testumgebung durch den folgenden Befehl wieder zurückgesetzt werden.
```
go run ./cmd/authelia-scripts/ suites teardown Standalone
```
## Benutzerdefinierte Zertifikate
Um ein benutzerdefiniertes Zertifikat für die Ausführung zu verwenden, muss die Datai `public.backend.crt` und `private.bakend.pem` unter [diesem](/internal/suites/common/pki/) Verzeichnis abgeändert werden.
Um die Gültigkeit zu testen, kann der folgendende Befehl ausgeführt werden.
```
curl https://auth.rpjosh.de:9091 --connect-to 'auth.rpjosh.de:9091:authelia.example.com:9091'
```
## Externe erreichbarkeit
Im aktuellen Zustand sind die Endpunkte nur unter den Docker internen IP-Adressen erreichbar. Daher muss noch ein NAT Regel angelegt werden.
```
ip=$(ping -c 1 authelia.example.com | gawk -F'[()]' '/PING/{print $2}')
sudo iptables -t nat -A PREROUTING -p tcp --dport 9091 -d 192.168.0.15 -j DNAT --to-destination 192.168.240.50:9091 -m comment --comment "Authelia-Test"
sudo iptables -t nat -A PREROUTING -p tcp --dport 9092 -d 192.168.0.15 -j DNAT --to-destination 192.168.240.50:9092 -m comment --comment "Authelia-Test"
sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 9091 -j DNAT --to-destination 192.168.240.50:9091
```
# Customizations
Für das Starten des *gRPC* Servers müssen die folgenden Abhängigkeiten installiert werden.
```
go get github.com/envoyproxy/go-control-plane
go get github.com/envoyproxy/go-control-plane/envoy/config/core/v3
go get github.com/gogo/googleapis/google/rpc
go get google.golang.org/grpc
```
## Konfiguration ändern
Wenn die Konfiguration geändert wurde, müssen die Keys zur Validierung wieder erneut gebaut werden.
```
go run ./cmd/authelia-gen code keys
```
## Mocks abgeändert
Wenn interfaces von den Mocks geändert werden, muss folgendes wieder ausgeführt werden:
```
export PATH=$PATH:$(go env GOPATH)/bin
go generate ./...
```
## Bauen
Um ein Docker Image für authelia zu bauen, müssen die folgenden Befehle ausgeführt werden.
```sh
# Dieser Befehle funktionieren aktuell nicht
authelia-scripts docker build
authelia-scripts build
# => Manuell bauen
export CC=musl-gcc
authelia-scripts build
cp -r dist/public_html internal/server/
go build -buildmode=pie -ldflags "-linkmode=external -s -w" -trimpath -buildmode=pie -o authelia ./cmd/authelia
mv authelia authelia-linux-amd64-musl
# Build docker image
docker build --tag git.rpjosh.de/rpjosh/authelia/authelia:4.38.0-dev .
docker push git.rpjosh.de/rpjosh/authelia/authelia:4.38.0-dev
# Cleanup
rm -rf internal/server/public_html/ ./authelia-linux-amd64-musl
```
# gRCP
Um einen gRCP Endpunkt nutzen zu können, brauch mein eine *.proto* Datei. Für Envoy sieht diese wie in [dieser Datei](/ext-auth.proto) folgendermaßen aus.

View File

@ -200,9 +200,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -213,9 +210,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -279,9 +273,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -292,9 +283,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -354,9 +342,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -367,9 +352,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:
@ -429,9 +411,6 @@ paths:
location:
description: Redirect Location for user authorization
example: '{{ $redir }}'
schema:
type: string
format: uri
set-cookie:
description: Sets a new cookie value
schema:

View File

@ -13,7 +13,7 @@ import (
"github.com/spf13/cobra"
"github.com/valyala/fasthttp"
yaml "gopkg.in/yaml.v3"
"gopkg.in/yaml.v3"
)
func newDocsDateCmd() *cobra.Command {
@ -87,17 +87,7 @@ func docsDateRunE(cmd *cobra.Command, args []string) (err error) {
)
if value, ok := frontmatter["date"]; ok {
date, ok = value.(time.Time)
if !ok {
var abspath string
if abspath, err = filepath.Abs(path); err != nil {
abspath = path
}
return fmt.Errorf("frontmatter for %s has an invalid date value: is %T with a value of %s", abspath, value, value)
}
date = value.(time.Time)
}
dateGit := getDateFromGit(cwd, abs, commitFilter)

View File

@ -61,24 +61,6 @@ func rootSubCommandsRunE(cmd *cobra.Command, args []string) (err error) {
return err
}
subCmds := sortCmds(cmd)
for _, subCmd := range subCmds {
if subCmd.Use == cmdUseCompletion || strings.HasPrefix(subCmd.Use, "help ") || utils.IsStringSliceContainsAny([]string{resolveCmdName(subCmd), subCmd.Use}, exclude) {
continue
}
rootCmd.SetArgs(rootCmdGetArgs(subCmd, args))
if err = rootCmd.Execute(); err != nil {
return err
}
}
return nil
}
func sortCmds(cmd *cobra.Command) []*cobra.Command {
subCmds := cmd.Commands()
switch cmd.Use {
@ -108,7 +90,19 @@ func sortCmds(cmd *cobra.Command) []*cobra.Command {
})
}
return subCmds
for _, subCmd := range subCmds {
if subCmd.Use == cmdUseCompletion || strings.HasPrefix(subCmd.Use, "help ") || utils.IsStringSliceContainsAny([]string{resolveCmdName(subCmd), subCmd.Use}, exclude) {
continue
}
rootCmd.SetArgs(rootCmdGetArgs(subCmd, args))
if err = rootCmd.Execute(); err != nil {
return err
}
}
return nil
}
func resolveCmdName(cmd *cobra.Command) string {
@ -123,7 +117,7 @@ func resolveCmdName(cmd *cobra.Command) string {
func rootCmdGetArgs(cmd *cobra.Command, args []string) []string {
for {
if cmd == nil || cmd == rootCmd {
if cmd == rootCmd {
break
}

View File

@ -1,125 +0,0 @@
package main
import (
"testing"
"github.com/spf13/cobra"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestResolveCmdName(t *testing.T) {
testCases := []struct {
name string
have *cobra.Command
expected string
}{
{
"ShouldResolveRootCmd",
newRootCmd(),
"authelia-gen",
},
{
"ShouldResolveDocsCmd",
newDocsCmd(),
"docs",
},
{
"ShouldResolveDocsSubCmd",
newRootCmd().Commands()[0].Commands()[0],
"code.keys",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, resolveCmdName(tc.have))
})
}
}
func TestRootCmdGetArgs(t *testing.T) {
testCases := []struct {
name string
have func() *cobra.Command
args []string
expected []string
}{
{
"ShouldReturnRootCmdArgs",
func() *cobra.Command {
cmd := newRootCmd()
cmd.SetArgs([]string{"a", "b"})
return cmd.Commands()[0]
},
[]string{"c", "d"},
[]string{"authelia-gen", "code", "c", "d"},
},
{
"ShouldReturnRootCmdWithoutArgs",
func() *cobra.Command {
cmd := newRootCmd()
return cmd.Commands()[0]
},
nil,
[]string{"authelia-gen", "code"},
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, rootCmdGetArgs(tc.have(), tc.args))
})
}
}
func TestSortCmds(t *testing.T) {
testCases := []struct {
name string
have *cobra.Command
expected []string
}{
{
"ShouldSortRootCmd",
newRootCmd(),
[]string{"code", "commit-lint", "github", "locales", "docs"},
},
{
"ShouldSortDocsCmd",
newDocsCmd(),
[]string{"cli", "data", "date"},
},
{
"ShouldSortGitHubCmd",
newGitHubCmd(),
[]string{"issue-templates"},
},
{
"ShouldSortLocalesCmd",
newLocalesCmd(),
nil,
},
{
"ShouldSortDocsDataCmd",
newDocsDataCmd(),
[]string{"keys", "misc"},
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
actual := sortCmds(tc.have)
n := len(tc.expected)
require.Len(t, actual, n)
for i := 0; i < n; i++ {
assert.Equal(t, tc.expected[i], actual[i].Use)
}
})
}
}

View File

@ -62,10 +62,6 @@ var decodedTypes = []reflect.Type{
reflect.TypeOf(url.URL{}),
reflect.TypeOf(time.Duration(0)),
reflect.TypeOf(schema.Address{}),
reflect.TypeOf(schema.AddressTCP{}),
reflect.TypeOf(schema.AddressUDP{}),
reflect.TypeOf(schema.AddressLDAP{}),
reflect.TypeOf(schema.AddressSMTP{}),
reflect.TypeOf(schema.X509CertificateChain{}),
reflect.TypeOf(schema.PasswordDigest{}),
reflect.TypeOf(rsa.PrivateKey{}),

View File

@ -1,145 +0,0 @@
package main
import (
"net/mail"
"reflect"
"testing"
"github.com/spf13/pflag"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
"github.com/authelia/authelia/v4/internal/configuration/schema"
)
func TestGetPFlagPath(t *testing.T) {
testCases := []struct {
name string
have func(t *testing.T) *pflag.FlagSet
names []string
expected string
err string
}{
{
"ShouldFailEmptyFlagSet",
func(t *testing.T) *pflag.FlagSet {
return pflag.NewFlagSet("example", pflag.ContinueOnError)
},
[]string{"abc", "123"},
"",
"failed to lookup flag 'abc': flag accessed but not defined: abc",
},
{
"ShouldFailEmptyFlagNames",
func(t *testing.T) *pflag.FlagSet {
return pflag.NewFlagSet("example", pflag.ContinueOnError)
},
nil,
"",
"no flag names",
},
{
"ShouldLookupFlagNames",
func(t *testing.T) *pflag.FlagSet {
flagset := pflag.NewFlagSet("example", pflag.ContinueOnError)
flagset.String("dir.one", "", "")
flagset.String("dir.two", "", "")
flagset.String("file.name", "", "")
require.NoError(t, flagset.Parse([]string{"--dir.one=abc", "--dir.two=123", "--file.name=path.txt"}))
return flagset
},
[]string{"dir.one", "dir.two", "file.name"},
"abc/123/path.txt",
"",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
actual, theError := getPFlagPath(tc.have(t), tc.names...)
if tc.err == "" {
assert.NoError(t, theError)
assert.Equal(t, tc.expected, actual)
} else {
assert.EqualError(t, theError, tc.err)
assert.Equal(t, "", actual)
}
})
}
}
func TestBuildCSP(t *testing.T) {
testCases := []struct {
name string
have string
ruleSets [][]CSPValue
expected string
}{
{
"ShouldParseDefault",
codeCSPProductionDefaultSrc,
[][]CSPValue{
codeCSPValuesCommon,
codeCSPValuesProduction,
},
"default-src 'self'; frame-src 'none'; object-src 'none'; style-src 'self' 'nonce-%s'; frame-ancestors 'none'; base-uri 'self'",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, buildCSP(tc.have, tc.ruleSets...))
})
}
}
func TestContainsType(t *testing.T) {
astring := ""
testCases := []struct {
name string
have any
expected bool
}{
{
"ShouldContainMailAddress",
mail.Address{},
true,
},
{
"ShouldContainSchemaAddressPtr",
&schema.Address{},
true,
},
{
"ShouldNotContainString",
astring,
false,
},
{
"ShouldNotContainStringPtr",
&astring,
false,
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expected, containsType(reflect.TypeOf(tc.have), decodedTypes))
})
}
}
func TestReadTags(t *testing.T) {
assert.NotPanics(t, func() {
readTags("", reflect.TypeOf(schema.Configuration{}), false)
})
assert.NotPanics(t, func() {
readTags("", reflect.TypeOf(schema.Configuration{}), true)
})
}

View File

@ -1,12 +1,12 @@
---
name: 'Bug Report'
description: 'Report a bug'
name: Bug Report
description: Report a bug
labels:
{{- range .Labels }}
- '{{ . }}'
- {{ . }}
{{- end }}
body:
- type: 'markdown'
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this bug report. If you are unsure if this is actually a bug and you still need some form of support we generally recommend creating a [Question and Answer Discussion](https://github.com/authelia/authelia/discussions/new?category=q-a) first.
@ -17,160 +17,123 @@ body:
2. Please try to give as much information as possible for us to be able to reproduce the issue and provide a quick fix.
3. Please ensure an issue does not already exist for this potential bug.
4. Please only provide specific versions. Latest is not a version.
5. Please only report bugs with Authelia itself. Issues which match one of the following criteria should not be reported here but should be a [discussion](https://github.com/authelia/authelia/discussions/new/choose) instead:
- Bugs with third-party software.
- Mistakes in the documentation.
- Potential bugs where it is not somewhat clear that it's a bug with Authelia itself.
6. Please read the [Troubleshooting](https://www.authelia.com/r/troubleshooting) reference guide:
- Do not truncate any logs unless you are complying with the specific instructions in the [Logs](https://www.authelia.com/r/troubleshooting#logs) section.
- If you plan on sanitizing, removing, or adjusting any values for the logs or configuration files please read the [Sanitization](https://www.authelia.com/r/troubleshooting#sanitization) section.
7. Please consider including a [HTTP Archive File](https://www.authelia.com/r/har) if you're having redirection issues.
- type: 'dropdown'
id: 'version'
5. Please read the [Troubleshooting Sanitization](https://www.authelia.com/r/sanitize) reference guide if you plan on sanitizing, removing, or adjusting any values for the logs or configuration files.
6. Please consider including a [HTTP Archive File](https://www.authelia.com/r/har) if you're having redirection issues.
- type: dropdown
id: version
attributes:
label: |
Version
description: |
What version(s) of Authelia can you reproduce this bug on?
label: Version
description: What version(s) of Authelia can you reproduce this bug on?
multiple: true
options:
{{- range .Versions }}
- '{{ . }}'
- {{ . }}
{{- end }}
validations:
required: true
- type: 'dropdown'
id: 'deployment'
- type: dropdown
id: deployment
attributes:
label: |
Deployment Method
description: |
How are you deploying Authelia?
label: Deployment Method
description: How are you deploying Authelia?
options:
- 'Docker'
- 'Kubernetes'
- 'Bare-metal'
- 'Other'
- Docker
- Kubernetes
- Bare-metal
- Other
validations:
required: true
- type: 'dropdown'
id: 'proxy'
- type: dropdown
id: proxy
attributes:
label: |
Reverse Proxy
description: |
What reverse proxy are you using?
label: Reverse Proxy
description: What reverse proxy are you using?
options:
{{- range .Proxies }}
- '{{ . }}'
- {{ . }}
{{- end }}
validations:
required: true
- type: 'input'
id: 'proxy-version'
- type: input
id: proxy-version
attributes:
label: |
Reverse Proxy Version
description: |
What is the version of your reverse proxy?
placeholder: 'x.x.x'
label: Reverse Proxy Version
description: What is the version of your reverse proxy?
placeholder: x.x.x
validations:
required: false
- type: 'textarea'
id: 'description'
- type: textarea
id: description
attributes:
label: |
Description
description: |
Describe the bug.
label: Description
description: Describe the bug
validations:
required: true
- type: 'textarea'
id: 'reproduction'
- type: textarea
id: reproduction
attributes:
label: |
Reproduction
description: |
Describe how we can reproduce this issue. This should be step by step and should include detailed and specific information. Abstract or generic information should be avoided. For example this should include specific application names and versions if relevant. Reproducing the issue is important so we can verify it exists, add relevant tests, and verify it is solved.
label: Reproduction
description: Describe how we can reproduce this issue
validations:
required: true
- type: 'textarea'
id: 'expectations'
- type: textarea
id: expectations
attributes:
label: |
Expectations
description: |
Describe the desired or expected results.
label: Expectations
description: Describe the desired or expected results
validations:
required: false
- type: 'textarea'
id: 'configuration'
- type: textarea
id: configuration
attributes:
label: |
Configuration (Authelia)
description: |
Provide a complete configuration file (the template will automatically put this content in a code block).
render: 'yaml'
label: Configuration (Authelia)
description: Provide a complete configuration file (the template will automatically put this content in a code block)
render: yaml
validations:
required: false
- type: 'textarea'
id: 'logs'
- type: textarea
id: logs
attributes:
label: |
Logs (Authelia)
label: Logs (Authelia)
description: |
Provide complete logs with the log level set to debug or trace. Complete means from application start until the issue occurring. This is clearly explained in the [Logs](https://www.authelia.com/r/troubleshooting#logs) section of the troubleshooting guide.
The template will automatically put this content in a code block so you can just paste it.
render: 'shell'
Provide complete logs with the log level set to debug or trace. Complete means from application start until the
issue occurring. The template will automatically put this content in a code block so you can just paste it.
render: shell
validations:
required: true
- type: 'textarea'
id: 'logs-other'
- type: textarea
id: logs-other
attributes:
label: |
Logs (Proxy / Application)
description: |
Provide complete debug logs for the affected proxy and/or application if available and relevant (the template will automatically put this content in a code block).
render: 'shell'
label: Logs (Proxy / Application)
description: Provide complete debug logs for the affected proxy and/or application if available and relevant (the template will automatically put this content in a code block)
render: shell
validations:
required: false
- type: 'textarea'
id: 'documentation'
- type: textarea
id: documentation
attributes:
label: |
Documentation
description: |
Provide any relevant specification or other documentation if applicable.
label: Documentation
description: Provide any relevant specification or other documentation if applicable
validations:
required: false
- type: 'checkboxes'
id: 'checklist'
- type: checkboxes
id: checklist
attributes:
label: |
Pre-Submission Checklist
description: |
By submitting this issue confirm all of the following.
label: Pre-Submission Checklist
description: By submitting this issue confirm all of the following
options:
- label: |
I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
- label: I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
required: true
- label: |
This is a bug report and not a support request
- label: This is a bug report and not a support request
required: true
- label: |
I have read the security policy and this bug report is not a security issue or security related issue
- label: I have read the security policy and this bug report is not a security issue or security related issue
required: true
- label: |
I have either included the complete configuration file or I am sure it's unrelated to the configuration
- label: I have either included the complete configuration file or I am sure it's unrelated to the configuration
required: true
- label: |
I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the [Troubleshooting Sanitization](https://www.authelia.com/r/sanitize) reference guide
- label: I have provided all of the required information in full with the only alteration being reasonable sanitization in accordance with the [Troubleshooting Sanitization](https://www.authelia.com/r/sanitize) reference guide
required: true
- label: |
I have checked for related proxy or application logs and included them if available
- label: I have checked for related proxy or application logs and included them if available
required: true
- label: |
I have checked for related issues and checked the documentation
- label: I have checked for related issues and checked the documentation
required: true
...

View File

@ -1,12 +1,12 @@
---
name: 'Feature Request'
description: 'Submit a Feature Request'
name: Feature Request
description: Submit a Feature Request
labels:
{{- range .Labels }}
- '{{ . }}'
- {{ . }}
{{- end }}
body:
- type: 'markdown'
- type: markdown
attributes:
value: |
Thanks for taking the time to fill out this feature request. A feature request is created as issue for the purpose of tracking the design and implementation of a feature.
@ -16,54 +16,42 @@ body:
1. Ensure there are no other similar feature requests.
2. Make sure you've checked the [Documentation](https://www.authelia.com) doesn't clearly document the features existence already.
3. Consider creating an [Idea Discussion](https://github.com/authelia/authelia/discussions/new?category=ideas) which can be voted on instead if one doesn't exist.
- type: 'textarea'
id: 'description'
- type: textarea
id: description
attributes:
label: |
Description
description: |
Describe the feature
label: Description
description: Describe the feature
validations:
required: true
- type: 'textarea'
id: 'use-case'
- type: textarea
id: use-case
attributes:
label: |
Use Case
description: |
Provide a use case
label: Use Case
description: Provide a use case
validations:
required: true
- type: 'textarea'
id: 'details'
- type: textarea
id: details
attributes:
label: |
Details
description: |
Describe the feature in detail
label: Details
description: Describe the feature in detail
validations:
required: false
- type: 'textarea'
id: 'documentation'
- type: textarea
id: documentation
attributes:
label: |
Documentation
description: |
Provide any relevant specification or other documentation if applicable
label: Documentation
description: Provide any relevant specification or other documentation if applicable
validations:
required: false
- type: 'checkboxes'
id: 'checklist'
- type: checkboxes
id: checklist
attributes:
label: |
Pre-Submission Checklist
description: |
By submitting this issue confirm all of the following
label: Pre-Submission Checklist
description: By submitting this issue confirm all of the following
options:
- label: |
I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
- label: I agree to follow the [Code of Conduct](http://www.authelia.com/code-of-conduct)
required: true
- label: |
I have checked for related issues and checked the documentation
- label: I have checked for related issues and checked the documentation
required: true
...

View File

@ -1,13 +0,0 @@
package main
import (
"testing"
"github.com/stretchr/testify/assert"
)
func TestShouldFailToLoadBadTemplate(t *testing.T) {
assert.Panics(t, func() {
mustLoadTmplFS("bad tmpl")
})
}

View File

@ -120,11 +120,6 @@ const (
labelAreaPrefixStatus = "status"
)
type label interface {
String() string
LabelDescription() string
}
type labelPriority int
//nolint:deadcode,varcheck // Kept for future use.
@ -134,7 +129,6 @@ const (
labelPriorityMedium
labelPriorityNormal
labelPriorityLow
labelPriorityVeryLow
)
var labelPriorityDescriptions = [...]string{
@ -143,15 +137,14 @@ var labelPriorityDescriptions = [...]string{
"Medium",
"Normal",
"Low",
"Very Low",
}
func (l labelPriority) String() string {
return fmt.Sprintf("%s/%d/%s", labelAreaPrefixPriority, l+1, labelFormatString(labelPriorityDescriptions[l]))
func (p labelPriority) String() string {
return fmt.Sprintf("%s/%d/%s", labelAreaPrefixPriority, p+1, strings.ToLower(labelPriorityDescriptions[p]))
}
func (l labelPriority) LabelDescription() string {
return labelPriorityDescriptions[l]
func (p labelPriority) Description() string {
return labelPriorityDescriptions[p]
}
type labelStatus int
@ -162,16 +155,12 @@ const (
)
var labelStatusDescriptions = [...]string{
"Needs Design",
"Needs Triage",
"needs-design",
"needs-triage",
}
func (l labelStatus) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixStatus, labelFormatString(labelStatusDescriptions[l]))
}
func (l labelStatus) LabelDescription() string {
return labelStatusDescriptions[l]
func (s labelStatus) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixStatus, labelStatusDescriptions[s])
}
type labelType int
@ -184,24 +173,13 @@ const (
)
var labelTypeDescriptions = [...]string{
"Feature",
"Bug: Unconfirmed",
"Bug",
"feature",
"bug/unconfirmed",
"bug",
}
func (l labelType) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixType, labelFormatString(labelTypeDescriptions[l]))
}
func (l labelType) LabelDescription() string {
return labelTypeDescriptions[l]
}
func labelFormatString(in string) string {
in = strings.ReplaceAll(in, ": ", "/")
in = strings.ReplaceAll(in, " ", "-")
return strings.ToLower(in)
func (t labelType) String() string {
return fmt.Sprintf("%s/%s", labelAreaPrefixType, labelTypeDescriptions[t])
}
// CSPValue represents individual CSP values.

View File

@ -1,90 +0,0 @@
package main
import (
"testing"
"github.com/stretchr/testify/assert"
)
func TestLabels(t *testing.T) {
testCases := []struct {
name string
have label
expectedDescription string
expectedString string
}{
{
"ShouldShowCorrectPriorityCriticalValues",
labelPriorityCritical,
"Critical",
"priority/1/critical",
},
{
"ShouldShowCorrectPriorityHighValues",
labelPriorityHigh,
"High",
"priority/2/high",
},
{
"ShouldShowCorrectPriorityMediumValues",
labelPriorityMedium,
"Medium",
"priority/3/medium",
},
{
"ShouldShowCorrectPriorityNormalValues",
labelPriorityNormal,
"Normal",
"priority/4/normal",
},
{
"ShouldShowCorrectPriorityLowValues",
labelPriorityLow,
"Low",
"priority/5/low",
},
{
"ShouldShowCorrectPriorityVeryLowValues",
labelPriorityVeryLow,
"Very Low",
"priority/6/very-low",
},
{
"ShouldShowCorrectStatusNeedsDesignValues",
labelStatusNeedsDesign,
"Needs Design",
"status/needs-design",
},
{
"ShouldShowCorrectStatusNeedsTriageValues",
labelStatusNeedsTriage,
"Needs Triage",
"status/needs-triage",
},
{
"ShouldShowCorrectTypeFeatureValues",
labelTypeFeature,
"Feature",
"type/feature",
},
{
"ShouldShowCorrectTypeBugUnconfirmedValues",
labelTypeBugUnconfirmed,
"Bug: Unconfirmed",
"type/bug/unconfirmed",
},
{
"ShouldShowCorrectTypeBugValues",
labelTypeBug,
"Bug",
"type/bug",
},
}
for _, tc := range testCases {
t.Run(tc.name, func(t *testing.T) {
assert.Equal(t, tc.expectedString, tc.have.String())
assert.Equal(t, tc.expectedDescription, tc.have.LabelDescription())
})
}
}

View File

@ -7,5 +7,5 @@
package cmd
const (
versionSwaggerUI = "5.0.0"
versionSwaggerUI = "4.18.2"
)

File diff suppressed because it is too large Load Diff

View File

@ -1,9 +1,9 @@
---
pull_request_title: 'i18n: update translations'
commit_message: 'i18n: update translation for %original_file_name% (%language%)'
pull_request_title: "i18n: update translations"
commit_message: "i18n: update translation for %original_file_name% (%language%)"
append_commit_message: false
files:
- source: '/internal/server/locales/en/*'
translation: '/internal/server/locales/%locale%/%original_file_name%'
- source: /internal/server/locales/en/*
translation: /internal/server/locales/%locale%/%original_file_name%
skip_untranslated_files: true
...

View File

@ -1 +1 @@
baseurl = "https://authelia-next.netlify.app/"
baseurl = "https://authelia-staging.netlify.app/"

View File

@ -31,14 +31,14 @@ with all major proxies supported excluding Microsoft IIS.
[Envoy]: https://www.envoyproxy.io/
[Istio]: https://istio.io/
## OpenID Connect 1.0 Improvements
## OpenID Connect Improvements
Several items from the [OpenID Connect 1.0 Roadmap](../../roadmap/active/openid-connect.md) are being checked off in this
Several items from the [OpenID Connect Roadmap](../../roadmap/active/openid-connect.md) are being checked off in this
release.
### Hashed Client Secrets
We'll be supporting hashed OpenID Connect 1.0 client secrets in this release. People will still be able to use plaintext
We'll be supporting hashed OpenID Connect client secrets in this release. People will still be able to use plaintext
secrets if they wish however we'll be recommending people utilize PBKDF2, BCrypt or SHA512 SHA2CRYPT (see
[Password Algorithms](#password-algorithms) for a full compatibility list). This doesn't change anything for OpenID
Connect Relying Parties, it only requires a change in the Authelia configuration.

View File

@ -16,20 +16,18 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
authentication_backend:
file:
path: '/config/users.yml'
path: /config/users.yml
watch: false
search:
email: false
case_insensitive: false
password:
algorithm: 'argon2'
algorithm: argon2
argon2:
variant: 'argon2id'
variant: argon2id
iterations: 3
memory: 65536
parallelism: 4
@ -42,22 +40,20 @@ authentication_backend:
key_length: 32
salt_length: 16
pbkdf2:
variant: 'sha512'
variant: sha512
iterations: 310000
salt_length: 16
sha2crypt:
variant: 'sha512'
variant: sha512
iterations: 50000
salt_length: 16
bcrypt:
variant: 'standard'
variant: standard
cost: 12
```
## Options
This section describes the individual configuration options.
### path
{{< confkey type="string" required="yes" >}}

View File

@ -23,8 +23,6 @@ There are two ways to integrate *Authelia* with an authentication backend:
## Configuration
{{< config-alert-example >}}
```yaml
authentication_backend:
refresh_interval: 5m
@ -35,15 +33,10 @@ authentication_backend:
## Options
This section describes the individual configuration options.
### refresh_interval
{{< confkey type="duration" default="5m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
This setting controls the interval at which details are refreshed from the backend. Particularly useful for
[LDAP](#ldap).

View File

@ -17,20 +17,18 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
authentication_backend:
ldap:
address: 'ldap://127.0.0.1'
implementation: 'custom'
timeout: '5s'
implementation: custom
url: ldap://127.0.0.1
timeout: 5s
start_tls: false
tls:
server_name: 'ldap.example.com'
server_name: ldap.example.com
skip_verify: false
minimum_version: 'TLS1.2'
maximum_version: 'TLS1.3'
minimum_version: TLS1.2
maximum_version: TLS1.3
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
@ -98,58 +96,23 @@ authentication_backend:
27GoE2i5mh6Yez6VAYbUuns3FcwIsMyWLq043Tu2DNkx9ijOOAuQzw^invalid..
DO NOT USE==
-----END RSA PRIVATE KEY-----
base_dn: 'DC=example,DC=com'
additional_users_dn: 'OU=users'
users_filter: '(&({username_attribute}={input})(objectClass=person))'
additional_groups_dn: 'OU=groups'
groups_filter: '(&(member={dn})(objectClass=groupOfNames))'
group_search_mode: 'filter'
base_dn: DC=example,DC=com
additional_users_dn: OU=users
users_filter: (&({username_attribute}={input})(objectClass=person))
username_attribute: uid
mail_attribute: mail
display_name_attribute: displayName
additional_groups_dn: OU=groups
groups_filter: (&(member={dn})(objectClass=groupOfNames))
group_name_attribute: cn
permit_referrals: false
permit_unauthenticated_bind: false
user: 'CN=admin,DC=example,DC=com'
password: 'password'
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
display_name: 'displayName'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
user: CN=admin,DC=example,DC=com
password: password
```
## Options
This section describes the individual configuration options.
### address
{{< confkey type="string" required="yes" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
The LDAP URL which consists of a scheme, hostname, and port. Format is `[<scheme>://]<hostname>[:<port>]`. The default
scheme is `ldapi` if the path is absolute otherwise it's `ldaps`, and the permitted schemes are `ldap`, `ldaps`, or
`ldapi` (a unix domain socket).
If the scheme is `ldapi` it must be followed by an absolute path to an existing unix domain socket that the
user/group the Authelia process is running as has the appropriate permissions to access. For example if the socket is
located at `/var/run/slapd.sock` the address should be `ldapi:///var/run/slapd.sock`.
__Examples:__
```yaml
authentication_backend:
ldap:
address: 'ldaps://dc1.example.com'
```
```yaml
authentication_backend:
ldap:
address: 'ldap://[fd00:1111:2222:3333::1]'
```
### implementation
{{< confkey type="string" default="custom" required="no" >}}
@ -158,13 +121,31 @@ Configures the LDAP implementation used by Authelia.
See the [Implementation Guide](../../reference/guides/ldap.md#implementation-guide) for information.
### url
{{< confkey type="string" required="yes" >}}
The LDAP URL which consists of a scheme, address, and port. Format is `<scheme>://<address>:<port>` or
`<scheme>://<address>` where scheme is either `ldap` or `ldaps`.
```yaml
authentication_backend:
ldap:
url: ldaps://dc1.example.com
```
If utilising an IPv6 literal address it must be enclosed by square brackets:
```yaml
authentication_backend:
ldap:
url: ldap://[fd00:1111:2222:3333::1]
```
### timeout
{{< confkey type="duration" default="5s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The timeout for dialing an LDAP connection.
### start_tls
@ -177,11 +158,8 @@ URL's are slightly more secure.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
Controls the TLS connection validation parameters for either StartTLS or the TLS socket.
Controls the TLS connection validation process. You can see how to configure the tls
section [here](../prologue/common.md#tls-configuration).
### base_dn
@ -213,33 +191,66 @@ The LDAP filter to narrow down which users are valid. This is important to set c
The default value is dependent on the [implementation](#implementation), refer to the
[attribute defaults](../../reference/guides/ldap.md#attribute-defaults) for more information.
### username_attribute
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](../../reference/guides/ldap.md#attribute-defaults)
for more information.*
The LDAP attribute that maps to the username in *Authelia*. This must contain the `{username_attribute}`
[placeholder](../../reference/guides/ldap.md#users-filter-replacements).
### mail_attribute
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](../../reference/guides/ldap.md#attribute-defaults)
for more information.*
The attribute to retrieve which contains the users email addresses. This is important for the device registration and
password reset processes. The user must have an email address in order for Authelia to perform identity verification
when a user attempts to reset their password or register a second factor device.
### display_name_attribute
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](#attribute-defaults) for more information.*
The attribute to retrieve which is shown on the Web UI to the user when they log in.
### additional_groups_dn
{{< confkey type="string" required="no" >}}
Similar to [additional_users_dn](#additionalusersdn) but it applies to group searches.
Similar to [additional_users_dn](#additional_users_dn) but it applies to group searches.
### groups_filter
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [filter defaults](../../reference/guides/ldap.md#filter-defaults) for
more information.*
default negating this requirement. Refer to the [filter defaults](#filter-defaults) for more information.*
Similar to [users_filter](#usersfilter) but it applies to group searches. In order to include groups the member is not
Similar to [users_filter](#users_filter) but it applies to group searches. In order to include groups the member is not
a direct member of, but is a member of another group that is a member of those (i.e. recursive groups), you may try
using the following filter which is currently only tested against Microsoft Active Directory:
`(&(member:1.2.840.113556.1.4.1941:={dn})(objectClass=group)(objectCategory=group))`
### group_search_mode
### group_name_attribute
{{< confkey type="string" default="filter" required="no" >}}
{{< confkey type="string" required="situational" >}}
The group search mode controls how user groups are discovered. The default of `filter` directly uses the filter to
determine the result. The `memberof` experimental mode does another special filtered search. See the
[Reference Documentation](../../reference/guides/ldap.md#group-search-modes) for more information.
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults](#attribute-defaults) for more
information.*
The LDAP attribute that is used by Authelia to determine the group name.
### permit_referrals
@ -284,71 +295,6 @@ It's __strongly recommended__ this is a
[Random Alphanumeric String](../../reference/guides/generating-secure-values.md#generating-a-random-alphanumeric-string) with 64 or more
characters and the user password is changed to this value.
### attributes
The following options configure The directory server attribute mappings.
#### distinguished_name
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically not required however it is required when using the group search mode
`memberof` replacement `{memberof:dn}`.*
The directory server attribute which contains the distinguished name, primarily used to perform filtered searches. There
is a clear distinction between the actual distinguished name and a distinguished name attribute, all directories have
distinguished names for objects, but not all have an attribute representing this that can be searched on.
The only known support at this time is with Active Directory.
#### username
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute that maps to the username in *Authelia*. This must contain the `{username_attribute}` [placeholder].
#### display_name
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute to retrieve which is shown on the Web UI to the user when they log in.
#### mail
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute to retrieve which contains the users email addresses. This is important for the device
registration and password reset processes. The user must have an email address in order for Authelia to perform
identity verification when a user attempts to reset their password or register a second factor device.
#### member_of
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute which contains the groups a user is a member of. This is currently only used for the
`memberof` group search mode.
#### group_name
{{< confkey type="string" required="situational" >}}
*__Note:__ This option is technically required however the [implementation](#implementation) option can implicitly set a
default negating this requirement. Refer to the [attribute defaults] for more information.*
The directory server attribute that is used by Authelia to determine the group name.
## Refresh Interval
It's recommended you either use the default [refresh interval](introduction.md#refreshinterval) or configure this to
@ -368,8 +314,6 @@ for your users.
- [LDAP Reference Guide](../../reference/guides/ldap.md)
[username attribute]: #username
[username attribute]: #usernameattribute
[TechNet wiki]: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx
[RFC2307]: https://datatracker.ietf.org/doc/html/rfc2307
[attribute defaults]: ../../reference/guides/ldap.md#attribute-defaults
[placeholder]: ../../reference/guides/ldap.md#users-filter-replacements

View File

@ -14,6 +14,6 @@ aliases:
- /docs/configuration/identity-providers/
---
## OpenID Connect 1.0
## OpenID Connect
The only identity provider implementation supported at this time is [OpenID Connect 1.0](openid-connect/provider.md).
The only identity provider implementation supported at this time is [OpenID Connect 1.0](open-id-connect.md).

View File

@ -0,0 +1,599 @@
---
title: "OpenID Connect"
description: "OpenID Connect Configuration"
lead: "Authelia can operate as an OpenID Connect 1.0 Provider. This section describes how to configure this."
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
menu:
configuration:
parent: "identity-providers"
weight: 190200
toc: true
aliases:
- /c/oidc
- /docs/configuration/identity-providers/oidc.html
---
__Authelia__ currently supports the [OpenID Connect 1.0] Provider role as an open
[__beta__](../../roadmap/active/openid-connect.md) feature. We currently do not support the [OpenID Connect 1.0] Relying
Party role. This means other applications that implement the [OpenID Connect 1.0] Relying Party role can use Authelia as
an [OpenID Connect 1.0] Provider similar to how you may use social media or development platforms for login.
The [OpenID Connect 1.0] Relying Party role is the role which allows an application to use GitHub, Google, or other
[OpenID Connect 1.0] Providers for authentication and authorization. We do not intend to support this functionality at
this moment in time.
More information about the beta can be found in the [roadmap](../../roadmap/active/openid-connect.md).
## Configuration
The following snippet provides a sample-configuration for the OIDC identity provider explaining each field in detail.
```yaml
identity_providers:
oidc:
hmac_secret: this_is_a_secret_abc123abc123abc
issuer_certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
EzERMA8GA1UEChMIQXV0aGVsaWEwHhcNNzAwMTAxMDAwMDAwWhcNNzEwMTAxMDAw
MDAwWjATMREwDwYDVQQKEwhBdXRoZWxpYTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAPKv3pSyP4ozGEiVLJ14dIWFCEGEgq7WUMI0SZZqQA2ID0L59U/Q
/Usyy7uC9gfMUzODTpANtkOjFQcQAsxlR1FOjVBrX5QgjSvXwbQn3DtwMA7XWSl6
LuYx2rBYSlMSN5UZQm/RxMtXfLK2b51WgEEYDFi+nECSqKzR4R54eOPkBEWRfvuY
91AMjlhpivg8e4JWkq4LVQUKbmiFYwIdK8XQiN4blY9WwXwJFYs5sQ/UYMwBFi0H
kWOh7GEjfxgoUOPauIueZSMSlQp7zqAH39N0ZSYb6cS0Npj57QoWZSY3ak87ebcR
Nf4rCvZLby7LoN7qYCKxmCaDD3x2+NYpWH8CAwEAAaM1MDMwDgYDVR0PAQH/BAQD
AgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN
AQELBQADggEBAHSITqIQSNzonFl3DzxHPEzr2hp6peo45buAAtu8FZHoA+U7Icfh
/ZXjPg7Xz+hgFwM/DTNGXkMWacQA/PaNWvZspgRJf2AXvNbMSs2UQODr7Tbv+Fb4
lyblmMUNYFMCFVAMU0eIxXAFq2qcwv8UMcQFT0Z/35s6PVOakYnAGGQjTfp5Ljuq
wsdc/xWmM0cHWube6sdRRUD7SY20KU/kWzl8iFO0VbSSrDf1AlEhnLEkp1SPaxXg
OdBnl98MeoramNiJ7NT6Jnyb3zZ578fjaWfThiBpagItI8GZmG4s4Ovh2JbheN8i
ZsjNr9jqHTjhyLVbDRlmJzcqoj4JhbKs6/I^invalid DO NOT USE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDBDCCAeygAwIBAgIRALJsPg21kA0zY4F1wUCIuoMwDQYJKoZIhvcNAQELBQAw
EzERMA8GA1UEChMIQXV0aGVsaWEwHhcNNzAwMTAxMDAwMDAwWhcNNzEwMTAxMDAw
MDAwWjATMREwDwYDVQQKEwhBdXRoZWxpYTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMXHBvVxUzYk0u34/DINMSF+uiOekKOAjOrC6Mi9Ww8ytPVO7t2S
zfTvM+XnEJqkFQFgimERfG/eGhjF9XIEY6LtnXe8ATvOK4nTwdufzBaoeQu3Gd50
5VXr6OHRo//ErrGvFXwP3g8xLePABsi/fkH3oDN+ztewOBMDzpd+KgTrk8ysv2ou
kNRMKFZZqASvCgv0LD5KWvUCnL6wgf1oTXG7aztduA4oSkUP321GpOmBC5+5ElU7
ysoRzvD12o9QJ/IfEaulIX06w9yVMo60C/h6A3U6GdkT1SiyTIqR7v7KU/IWd/Qi
Lfftcj91VhCmJ73Meff2e2S2PrpjdXbG5FMCAwEAAaNTMFEwDgYDVR0PAQH/BAQD
AgKkMA8GA1UdJQQIMAYGBFUdJQAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU
Z7AtA3mzFc0InSBA5fiMfeLXA3owDQYJKoZIhvcNAQELBQADggEBAEE5hm1mtlk/
kviCoHH4evbpw7rxPxDftIQlqYTtvMM4eWY/6icFoSZ4fUHEWYyps8SsPu/8f2tf
71LGgZn0FdHi1QU2H8m0HHK7TFw+5Q6RLrLdSyk0PItJ71s9en7r8pX820nAFEHZ
HkOSfJZ7B5hFgUDkMtVM6bardXAhoqcMk4YCU96e9d4PB4eI+xGc+mNuYvov3RbB
D0s8ICyojeyPVLerz4wHjZu68Z5frAzhZ68YbzNs8j2fIBKKHkHyLG1iQyF+LJVj
2PjCP+auJsj6fQQpMGoyGtpLcSDh+ptcTngUD8JsWipzTCjmaNqdPHAOYmcgtf4b
qocikt3WAdU^invalid DO NOT USE=
-----END CERTIFICATE-----
issuer_private_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA8q/elLI/ijMYSJUsnXh0hYUIQYSCrtZQwjRJlmpADYgPQvn1
T9D9SzLLu4L2B8xTM4NOkA22Q6MVBxACzGVHUU6NUGtflCCNK9fBtCfcO3AwDtdZ
KXou5jHasFhKUxI3lRlCb9HEy1d8srZvnVaAQRgMWL6cQJKorNHhHnh44+QERZF+
+5j3UAyOWGmK+Dx7glaSrgtVBQpuaIVjAh0rxdCI3huVj1bBfAkVizmxD9RgzAEW
LQeRY6HsYSN/GChQ49q4i55lIxKVCnvOoAff03RlJhvpxLQ2mPntChZlJjdqTzt5
txE1/isK9ktvLsug3upgIrGYJoMPfHb41ilYfwIDAQABAoIBAQDTOdFf2JjHH1um
aPgRAvNf9v7Nj5jytaRKs5nM6iNf46ls4QPreXnMhqSeSwj6lpNgBYxOgzC9Q+cc
Y4ob/paJJPaIJTxmP8K/gyWcOQlNToL1l+eJ20eQoZm23NGr5fIsunSBwLEpTrdB
ENqqtcwhW937K8Pxy/Q1nuLyU2bc6Tn/ivLozc8n27dpQWWKh8537VY7ancIaACr
LJJLYxKqhQpjtBWAyCDvZQirnAOm9KnvIHaGXIswCZ4Xbsu0Y9NL+woARPyRVQvG
jfxy4EmO9s1s6y7OObSukwKDSNihAKHx/VIbvVWx8g2Lv5fGOa+J2Y7o9Qurs8t5
BQwMTt0BAoGBAPUw5Z32EszNepAeV3E2mPFUc5CLiqAxagZJuNDO2pKtyN29ETTR
Ma4O1cWtGb6RqcNNN/Iukfkdk27Q5nC9VJSUUPYelOLc1WYOoUf6oKRzE72dkMQV
R4bf6TkjD+OVR17fAfkswkGahZ5XA7j48KIQ+YC4jbnYKSxZTYyKPjH/AoGBAP1i
tqXt36OVlP+y84wWqZSjMelBIVa9phDVGJmmhz3i1cMni8eLpJzWecA3pfnG6Tm9
ze5M4whASleEt+M00gEvNaU9ND+z0wBfi+/DwJYIbv8PQdGrBiZFrPhTPjGQUldR
lXccV2meeLZv7TagVxSi3DO6dSJfSEHyemd5j9mBAoGAX8Hv+0gOQZQCSOTAq8Nx
6dZcp9gHlNaXnMsP9eTDckOSzh636JPGvj6m+GPJSSbkURUIQ3oyokMNwFqvlNos
fTaLhAOfjBZI9WnDTTQxpugWjphJ4HqbC67JC/qIiw5S6FdaEvGLEEoD4zoChywZ
9oGAn+fz2d/0/JAH/FpFPgsCgYEAp/ipZgPzziiZ9ov1wbdAQcWRj7RaWnssPFpX
jXwEiXT3CgEMO4MJ4+KWIWOChrti3qFBg6i6lDyyS6Qyls7sLFbUdC7HlTcrOEMe
rBoTcCI1GqZNlqWOVQ65ZIEiaI7o1vPBZo2GMQEZuq8mDKFsOMThvvTrM5cAep84
n6HJR4ECgYABWcbsSnr0MKvVth/inxjbKapbZnp2HUCuw87Ie5zK2Of/tbC20wwk
yKw3vrGoE3O1t1g2m2tn8UGGASeZ842jZWjIODdSi5+icysQGuULKt86h/woz2SQ
27GoE2i5mh6Yez6VAYbUuns3FcwIsMyWLq043Tu2DNkx9ijOOAuQzw^invalid..
DO NOT USE==
-----END RSA PRIVATE KEY-----
access_token_lifespan: 1h
authorize_code_lifespan: 1m
id_token_lifespan: 1h
refresh_token_lifespan: 90m
enable_client_debug_messages: false
enforce_pkce: public_clients_only
cors:
endpoints:
- authorization
- token
- revocation
- introspection
allowed_origins:
- https://example.com
allowed_origins_from_client_redirect_uris: false
clients:
- id: myapp
description: My Application
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
sector_identifier: ''
public: false
authorization_policy: two_factor
consent_mode: explicit
pre_configured_consent_duration: 1w
audience: []
scopes:
- openid
- groups
- email
- profile
redirect_uris:
- https://oidc.example.com:8080/oauth2/callback
grant_types:
- refresh_token
- authorization_code
response_types:
- code
response_modes:
- form_post
- query
- fragment
userinfo_signing_algorithm: none
```
## Options
### hmac_secret
{{< confkey type="string" required="yes" >}}
*__Important Note:__ This can also be defined using a [secret](../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
The HMAC secret used to sign the [JWT]'s. The provided string is hashed to a SHA256 ([RFC6234]) byte string for the
purpose of meeting the required format.
It's __strongly recommended__ this is a
[Random Alphanumeric String](../../reference/guides/generating-secure-values.md#generating-a-random-alphanumeric-string)
with 64 or more characters.
### issuer_certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [issuer_private_key](#issuer_private_key) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When configured it enables the [x5c] and [x5t]
JSON key's in the JWKs [Discoverable Endpoint](../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://datatracker.ietf.org/doc/html/rfc7517
[x5c]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
[x5t]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.8
The first certificate in the chain must have the public key for the [issuer_private_key](#issuerprivatekey), each
certificate in the chain must be valid for the current date, and each certificate in the chain should be signed by the
certificate immediately following it if present.
### issuer_private_key
{{< confkey type="string" required="yes" >}}
*__Important Note:__ This can also be defined using a [secret](../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
The private key used to sign/encrypt the [OpenID Connect 1.0] issued [JWT]'s. The key must be generated by the administrator
and can be done by following the
[Generating an RSA Keypair](../../reference/guides/generating-secure-values.md#generating-an-rsa-keypair) guide.
The private key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be an RSA Key.
* Have a key size of at least 2048 bits.
If the [issuer_certificate_chain](#issuercertificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
### access_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
The maximum lifetime of an access token. It's generally recommended keeping this short similar to the default.
For more information read these docs about [token lifespan].
### authorize_code_lifespan
{{< confkey type="duration" default="1m" required="no" >}}
The maximum lifetime of an authorize code. This can be rather short, as the authorize code should only be needed to
obtain the other token types. For more information read these docs about [token lifespan].
### id_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
The maximum lifetime of an ID token. For more information read these docs about [token lifespan].
### refresh_token_lifespan
{{< confkey type="string" default="90m" required="no" >}}
The maximum lifetime of a refresh token. The
refresh token can be used to obtain new refresh tokens as well as access tokens or id tokens with an
up-to-date expiration. For more information read these docs about [token lifespan].
A good starting point is 50% more or 30 minutes more (which ever is less) time than the highest lifespan out of the
[access token lifespan](#access_token_lifespan), the [authorize code lifespan](#authorize_code_lifespan), and the
[id token lifespan](#id_token_lifespan). For instance the default for all of these is 60 minutes, so the default refresh
token lifespan is 90 minutes.
### enable_client_debug_messages
{{< confkey type="boolean" default="false" required="no" >}}
Allows additional debug messages to be sent to the clients.
### minimum_parameter_entropy
{{< confkey type="integer" default="8" required="no" >}}
This controls the minimum length of the `nonce` and `state` parameters.
*__Security Notice:__* Changing this value is generally discouraged, reducing it from the default can theoretically
make certain scenarios less secure. It is highly encouraged that if your OpenID Connect RP does not send these
parameters or sends parameters with a lower length than the default that they implement a change rather than changing
this value.
### enforce_pkce
{{< confkey type="string" default="public_clients_only" required="no" >}}
[Proof Key for Code Exchange](https://datatracker.ietf.org/doc/html/rfc7636) enforcement policy: if specified, must be
either `never`, `public_clients_only` or `always`.
If set to `public_clients_only` (default), [PKCE] will be required for public clients using the
[Authorization Code Flow].
When set to `always`, [PKCE] will be required for all clients using the Authorization Code flow.
*__Security Notice:__* Changing this value to `never` is generally discouraged, reducing it from the default can
theoretically make certain client-side applications (mobile applications, SPA) vulnerable to CSRF and authorization code
interception attacks.
### enable_pkce_plain_challenge
{{< confkey type="boolean" default="false" required="no" >}}
Allows [PKCE] `plain` challenges when set to `true`.
*__Security Notice:__* Changing this value is generally discouraged. Applications should use the `S256` [PKCE] challenge
method instead.
### pushed_authorizations
Controls the behaviour of [Pushed Authorization Requests].
#### enforce
{{< confkey type="boolean" default="false" required="no" >}}
When enabled all authorization requests must use the [Pushed Authorization Requests] flow.
#### context_lifespan
{{< confkey type="duration" default="5m" required="no" >}}
The maximum amount of time between the [Pushed Authorization Requests] flow being initiated and the generated
`request_uri` being utilized by a client.
### cors
Some [OpenID Connect 1.0] Endpoints need to allow cross-origin resource sharing, however some are optional. This section allows
you to configure the optional parts. We reply with CORS headers when the request includes the Origin header.
#### endpoints
{{< confkey type="list(string)" required="no" >}}
A list of endpoints to configure with cross-origin resource sharing headers. It is recommended that the `userinfo`
option is at least in this list. The potential endpoints which this can be enabled on are as follows:
* authorization
* pushed-authorization-request
* token
* revocation
* introspection
* userinfo
#### allowed_origins
{{< confkey type="list(string)" required="no" >}}
A list of permitted origins.
Any origin with https is permitted unless this option is configured or the
[allowed_origins_from_client_redirect_uris](#allowed_origins_from_client_redirect_uris) option is enabled. This means
you must configure this option manually if you want http endpoints to be permitted to make cross-origin requests to the
[OpenID Connect 1.0] endpoints, however this is not recommended.
Origins must only have the scheme, hostname and port, they may not have a trailing slash or path.
In addition to an Origin URI, you may specify the wildcard origin in the allowed_origins. It MUST be specified by itself
and the [allowed_origins_from_client_redirect_uris](#allowedoriginsfromclientredirecturis) MUST NOT be enabled. The
wildcard origin is denoted as `*`. Examples:
```yaml
identity_providers:
oidc:
cors:
allowed_origins: "*"
```
```yaml
identity_providers:
oidc:
cors:
allowed_origins:
- "*"
```
#### allowed_origins_from_client_redirect_uris
{{< confkey type="boolean" default="false" required="no" >}}
Automatically adds the origin portion of all redirect URI's on all clients to the list of
[allowed_origins](#allowed_origins), provided they have the scheme http or https and do not have the hostname of
localhost.
### clients
{{< confkey type="list" required="yes" >}}
A list of clients to configure. The options for each client are described below.
#### id
{{< confkey type="string" required="yes" >}}
The Client ID for this client. It must exactly match the Client ID configured in the application
consuming this client.
#### description
{{< confkey type="string" default="*same as id*" required="no" >}}
A friendly description for this client shown in the UI. This defaults to the same as the ID.
#### secret
{{< confkey type="string" required="situational" >}}
The shared secret between Authelia and the application consuming this client. This secret must match the secret
configured in the application.
This secret must be generated by the administrator and can be done by following the
[How Do I Generate Client Secrets](../../integration/openid-connect/frequently-asked-questions.md#how-do-i-generate-client-secrets) FAQ.
This must be provided when the client is a confidential client type, and must be blank when using the public client
type. To set the client type to public see the [public](#public) configuration option.
#### sector_identifier
{{< confkey type="string" required="no" >}}
*__Important Note:__ because adjusting this option will inevitably change the `sub` claim of all tokens generated for
the specified client, changing this should cause the relying party to detect all future authorizations as completely new
users.*
Must be an empty string or the host component of a URL. This is commonly just the domain name, but may also include a
port.
Authelia utilizes UUID version 4 subject identifiers. By default the public [Subject Identifier Type] is utilized for
all clients. This means the subject identifiers will be the same for all clients. This configuration option enables
[Pairwise Identifier Algorithm] for this client, and configures the sector identifier utilized for both the storage and
the lookup of the subject identifier.
1. All clients who do not have this configured will generate the same subject identifier for a particular user
regardless of which client obtains the ID token.
2. All clients which have the same sector identifier will:
1. have the same subject identifier for a particular user when compared to clients with the same sector identifier.
2. have a completely different subject identifier for a particular user whe compared to:
1. any client with the public subject identifier type.
2. any client with a differing sector identifier.
In specific but limited scenarios this option is beneficial for privacy reasons. In particular this is useful when the
party utilizing the *Authelia* [OpenID Connect 1.0] Authorization Server is foreign and not controlled by the user. It would
prevent the third party utilizing the subject identifier with another third party in order to track the user.
Keep in mind depending on the other claims they may still be able to perform this tracking and it is not a silver
bullet. There are very few benefits when utilizing this in a homelab or business where no third party is utilizing
the server.
#### public
{{< confkey type="bool" default="false" required="no" >}}
This enables the public client type for this client. This is for clients that are not capable of maintaining
confidentiality of credentials, you can read more about client types in [RFC6749 Section 2.1]. This is particularly
useful for SPA's and CLI tools. This option requires setting the [client secret](#secret) to a blank string.
#### redirect_uris
{{< confkey type="list(string)" required="yes" >}}
A list of valid callback URIs this client will redirect to. All other callbacks will be considered unsafe. The URIs are
case-sensitive and they differ from application to application - the community has provided
[a list of URL´s for common applications](../../integration/openid-connect/introduction.md).
Some restrictions that have been placed on clients and
their redirect URIs are as follows:
1. If a client attempts to authorize with Authelia and its redirect URI is not listed in the client configuration the
attempt to authorize will fail and an error will be generated.
2. The redirect URIs are case-sensitive.
3. The URI must include a scheme and that scheme must be one of `http` or `https`.
#### audience
{{< confkey type="list(string)" required="no" >}}
A list of audiences this client is allowed to request.
#### scopes
{{< confkey type="list(string)" default="openid, groups, profile, email" required="no" >}}
A list of scopes to allow this client to consume. See
[scope definitions](../../integration/openid-connect/introduction.md#scope-definitions) for more information. The
documentation for the application you are trying to configure [OpenID Connect 1.0] for will likely have a list of scopes
or claims required which can be matched with the above guide.
#### response_types
{{< confkey type="list(string)" default="code" required="no" >}}
*__Security Note:__ It is recommended that only the `code` response type (i.e. the default) is used. The other response
types are not as secure as this response type.*
A list of response types this client supports. If a response type not in this list is requested by a client then an
error will be returned to the client. The response type indicates the types of values that are returned to the client.
See the [Response Types](../../integration/openid-connect/introduction.md#response-types) section of the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md#response-types) for more information.
#### response_modes
{{< confkey type="list(string)" default="form_post, query" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
A list of response modes this client supports. If a response mode not in this list is requested by a client then an
error will be returned to the client. The response mode controls how the response type is returned to the client.
See the [Response Modes](../../integration/openid-connect/introduction.md#response-modes) section of the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md#response-modes) for more
information.
The default values are based on the [response_types](#responsetypes) values. When the [response_types](#responsetypes)
values include the `code` type then the `query` response mode will be included. When any other type is included the
`fragment` response mode will be included. It's important to note at this time we do not support the `none` response
type, but when it is supported it will include the `query` response mode.
#### grant_types
{{< confkey type="list(string)" default="authorization_code" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
The list of grant types this client is permitted to use in order to obtain access to the relevant tokens.
See the [Grant Types](../../integration/openid-connect/introduction.md#grant-types) section of the
[OpenID Connect 1.0 Integration Guide](../../integration/openid-connect/introduction.md#grant-types) for more information.
#### authorization_policy
{{< confkey type="string" default="two_factor" required="no" >}}
The authorization policy for this client: either `one_factor` or `two_factor`.
#### enforce_par
{{< confkey type="boolean" default="false" required="no" >}}
Enforces the use of a [Pushed Authorization Requests] flow for this client.
#### enforce_pkce
{{< confkey type="bool" default="false" required="no" >}}
This setting enforces the use of [PKCE] for this individual client. To enforce it for all clients see the global
[enforce_pkce](#enforcepkce) setting.
#### pkce_challenge_method
{{< confkey type="string" default="" required="no" >}}
This setting enforces the use of the specified [PKCE] challenge method for this individual client. This setting also
effectively enables the [enforce_pkce](#enforcepkce-1) option for this client.
Valid values are an empty string, `plain`, or `S256`. It should be noted that `S256` is strongly recommended if the
relying party supports it.
#### userinfo_signing_algorithm
{{< confkey type="string" default="none" required="no" >}}
The algorithm used to sign the userinfo endpoint responses. This can either be `none` or `RS256`.
See the [integration guide](../../integration/openid-connect/introduction.md#user-information-signing-algorithm) for
more information.
#### token_endpoint_auth_method
{{< confkey type="string" default="" required="no" >}}
The registered client authentication mechanism used by this client for the [Token Endpoint]. If no method is defined
the confidential client type will accept any supported method. The public client type defaults to `none` as this
is required by the specification. This may be required as a breaking change in future versions.
Supported values are `client_secret_basic`, `client_secret_post`, and `none`.
See the [integration guide](../../integration/openid-connect/introduction.md#client-authentication-method) for
more information.
#### consent_mode
{{< confkey type="string" default="auto" required="no" >}}
*__Important Note:__ the `implicit` consent mode is not technically part of the specification. It theoretically could be
misused in certain conditions specifically with the public client type or when the client credentials (i.e. client
secret) has been exposed to an attacker. For these reasons this mode is discouraged.*
Configures the consent mode. The following table describes the different modes:
| Value | Description |
|:--------------:|:----------------------------------------------------------------------------------------------------------------------------------------------:|
| auto | Automatically determined (default). Uses `explicit` unless [pre_configured_consent_duration] is specified in which case uses `pre-configured`. |
| explicit | Requires the user provide unique explicit consent for every authorization. |
| implicit | Automatically assumes consent for every authorization, never asking the user if they wish to give consent. |
| pre-configured | Allows the end-user to remember their consent for the [pre_configured_consent_duration]. |
[pre_configured_consent_duration]: #preconfiguredconsentduration
#### pre_configured_consent_duration
{{< confkey type="duration" default="1w" required="no" >}}
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
Specifying this in the configuration without a consent [consent_mode] enables the `pre-configured` mode. If this is
specified as well as the [consent_mode] then it only has an effect if the [consent_mode] is `pre-configured` or `auto`.
The period of time dictates how long a users choice to remember the pre-configured consent lasts.
Pre-configured consents are only valid if the subject, client id are exactly the same and the requested scopes/audience
match exactly with the granted scopes/audience.
[consent_mode]: #consentmode
## Integration
To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party please see the
[integration docs](../../integration/openid-connect/introduction.md).
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[Token Endpoint]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[JWT]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC6234]: https://datatracker.ietf.org/doc/html/rfc6234
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
[RFC7468]: https://datatracker.ietf.org/doc/html/rfc7468
[RFC6749 Section 2.1]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
[PKCE]: https://datatracker.ietf.org/doc/html/rfc7636
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Subject Identifier Type]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Pairwise Identifier Algorithm]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -1,15 +0,0 @@
---
title: "OpenID Connect 1.0"
description: ""
lead: ""
date: 2023-05-15T10:32:10+10:00
lastmod: 2022-01-18T20:07:56+01:00
draft: false
images: []
menu:
docs:
parent: "identity-providers"
identifier: "openid-connect"
weight: 190120
toc: true
---

View File

@ -1,469 +0,0 @@
---
title: "OpenID Connect 1.0 Clients"
description: "OpenID Connect 1.0 Registered Clients Configuration"
lead: "Authelia can operate as an OpenID Connect 1.0 Provider. This section describes how to configure the registered clients."
date: 2023-05-15T10:32:10+10:00
draft: false
images: []
menu:
configuration:
parent: "openid-connect"
weight: 190220
toc: true
---
This section covers specifics regarding configuring the providers registered clients for [OpenID Connect 1.0]. For the
provider specific configuration and information not related to clients see the [OpenID Connect 1.0 Provider](provider.md)
documentation.
More information about OpenID Connect 1.0 can be found in the [roadmap](../../../roadmap/active/openid-connect.md) and
in the [integration](../../../integration/openid-connect/introduction.md) documentation.
## Configuration
The following snippet provides a configuration example for the [OpenID Connect 1.0] Registered Clients. This is not
intended for production use it's used to provide context and an indentation example.
```yaml
identity_providers:
oidc:
clients:
- id: 'myapp'
description: 'My Application'
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
sector_identifier: ''
public: false
redirect_uris:
- 'https://oidc.example.com:8080/oauth2/callback'
audience: []
scopes:
- 'openid'
- 'groups'
- 'email'
- 'profile'
grant_types:
- 'refresh_token'
- 'authorization_code'
response_types:
- 'code'
response_modes:
- 'form_post'
- 'query'
- 'fragment'
authorization_policy: 'two_factor'
consent_mode: 'explicit'
pre_configured_consent_duration: '1 week'
enforce_par: false
enforce_pkce: false
pkce_challenge_method: 'S256'
id_token_signing_alg: 'RS256'
id_token_signing_key_id: ''
userinfo_signing_alg: 'none'
userinfo_signing_key_id: ''
request_object_signing_alg: 'RS256'
token_endpoint_auth_signing_alg: 'RS256'
token_endpoint_auth_method: ''
```
## Options
### id
{{< confkey type="string" required="yes" >}}
The Client ID for this client. It must exactly match the Client ID configured in the application consuming this client.
### description
{{< confkey type="string" default="*same as id*" required="no" >}}
A friendly description for this client shown in the UI. This defaults to the same as the ID.
### secret
{{< confkey type="string" required="situational" >}}
The shared secret between Authelia and the application consuming this client. This secret must match the secret
configured in the application.
This secret must be generated by the administrator and can be done by following the
[How Do I Generate Client Secrets](../../../integration/openid-connect/frequently-asked-questions.md#how-do-i-generate-client-secrets) FAQ.
This must be provided when the client is a confidential client type, and must be blank when using the public client
type. To set the client type to public see the [public](#public) configuration option.
### sector_identifier
{{< confkey type="string" required="no" >}}
*__Important Note:__ because adjusting this option will inevitably change the `sub` claim of all tokens generated for
the specified client, changing this should cause the relying party to detect all future authorizations as completely new
users.*
Must be an empty string or the host component of a URL. This is commonly just the domain name, but may also include a
port.
Authelia utilizes UUID version 4 subject identifiers. By default the public [Subject Identifier Type] is utilized for
all clients. This means the subject identifiers will be the same for all clients. This configuration option enables
[Pairwise Identifier Algorithm] for this client, and configures the sector identifier utilized for both the storage and
the lookup of the subject identifier.
1. All clients who do not have this configured will generate the same subject identifier for a particular user
regardless of which client obtains the ID token.
2. All clients which have the same sector identifier will:
1. have the same subject identifier for a particular user when compared to clients with the same sector identifier.
2. have a completely different subject identifier for a particular user whe compared to:
1. any client with the public subject identifier type.
2. any client with a differing sector identifier.
In specific but limited scenarios this option is beneficial for privacy reasons. In particular this is useful when the
party utilizing the *Authelia* [OpenID Connect 1.0] Authorization Server is foreign and not controlled by the user. It would
prevent the third party utilizing the subject identifier with another third party in order to track the user.
Keep in mind depending on the other claims they may still be able to perform this tracking and it is not a silver
bullet. There are very few benefits when utilizing this in a homelab or business where no third party is utilizing
the server.
### public
{{< confkey type="bool" default="false" required="no" >}}
This enables the public client type for this client. This is for clients that are not capable of maintaining
confidentiality of credentials, you can read more about client types in [RFC6749 Section 2.1]. This is particularly
useful for SPA's and CLI tools. This option requires setting the [client secret](#secret) to a blank string.
### redirect_uris
{{< confkey type="list(string)" required="yes" >}}
A list of valid callback URIs this client will redirect to. All other callbacks will be considered unsafe. The URIs are
case-sensitive and they differ from application to application - the community has provided
[a list of URL´s for common applications](../../../integration/openid-connect/introduction.md).
Some restrictions that have been placed on clients and
their redirect URIs are as follows:
1. If a client attempts to authorize with Authelia and its redirect URI is not listed in the client configuration the
attempt to authorize will fail and an error will be generated.
2. The redirect URIs are case-sensitive.
3. The URI must include a scheme and that scheme must be one of `http` or `https`.
### audience
{{< confkey type="list(string)" required="no" >}}
A list of audiences this client is allowed to request.
### scopes
{{< confkey type="list(string)" default="openid, groups, profile, email" required="no" >}}
A list of scopes to allow this client to consume. See
[scope definitions](../../../integration/openid-connect/introduction.md#scope-definitions) for more information. The
documentation for the application you are trying to configure [OpenID Connect 1.0] for will likely have a list of scopes
or claims required which can be matched with the above guide.
### grant_types
{{< confkey type="list(string)" default="authorization_code" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
The list of grant types this client is permitted to use in order to obtain access to the relevant tokens.
See the [Grant Types](../../../integration/openid-connect/introduction.md#grant-types) section of the
[OpenID Connect 1.0 Integration Guide](../../../integration/openid-connect/introduction.md#grant-types) for more information.
### response_types
{{< confkey type="list(string)" default="code" required="no" >}}
*__Security Note:__ It is recommended that only the `code` response type (i.e. the default) is used. The other response
types are not as secure as this response type.*
A list of response types this client supports. If a response type not in this list is requested by a client then an
error will be returned to the client. The response type indicates the types of values that are returned to the client.
See the [Response Types](../../../integration/openid-connect/introduction.md#response-types) section of the
[OpenID Connect 1.0 Integration Guide](../../../integration/openid-connect/introduction.md#response-types) for more information.
### response_modes
{{< confkey type="list(string)" default="form_post, query" required="no" >}}
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
A list of response modes this client supports. If a response mode not in this list is requested by a client then an
error will be returned to the client. The response mode controls how the response type is returned to the client.
See the [Response Modes](../../../integration/openid-connect/introduction.md#response-modes) section of the
[OpenID Connect 1.0 Integration Guide](../../../integration/openid-connect/introduction.md#response-modes) for more
information.
The default values are based on the [response_types](#responsetypes) values. When the [response_types](#responsetypes)
values include the `code` type then the `query` response mode will be included. When any other type is included the
`fragment` response mode will be included. It's important to note at this time we do not support the `none` response
type, but when it is supported it will include the `query` response mode.
### authorization_policy
{{< confkey type="string" default="two_factor" required="no" >}}
The authorization policy for this client: either `one_factor` or `two_factor`.
### consent_mode
{{< confkey type="string" default="auto" required="no" >}}
*__Important Note:__ the `implicit` consent mode is not technically part of the specification. It theoretically could be
misused in certain conditions specifically with the public client type or when the client credentials (i.e. client
secret) has been exposed to an attacker. For these reasons this mode is discouraged.*
Configures the consent mode. The following table describes the different modes:
| Value | Description |
|:--------------:|:----------------------------------------------------------------------------------------------------------------------------------------------:|
| auto | Automatically determined (default). Uses `explicit` unless [pre_configured_consent_duration] is specified in which case uses `pre-configured`. |
| explicit | Requires the user provide unique explicit consent for every authorization. |
| implicit | Automatically assumes consent for every authorization, never asking the user if they wish to give consent. |
| pre-configured | Allows the end-user to remember their consent for the [pre_configured_consent_duration]. |
[pre_configured_consent_duration]: #preconfiguredconsentduration
### pre_configured_consent_duration
{{< confkey type="duration" default="1w" required="no" >}}
*__Note:__ This setting uses the [duration notation format](../../prologue/common.md#duration-notation-format). Please see
the [common options](../../prologue/common.md#duration-notation-format) documentation for information on this format.*
Specifying this in the configuration without a consent [consent_mode] enables the `pre-configured` mode. If this is
specified as well as the [consent_mode] then it only has an effect if the [consent_mode] is `pre-configured` or `auto`.
The period of time dictates how long a users choice to remember the pre-configured consent lasts.
Pre-configured consents are only valid if the subject, client id are exactly the same and the requested scopes/audience
match exactly with the granted scopes/audience.
[consent_mode]: #consentmode
### enforce_par
{{< confkey type="boolean" default="false" required="no" >}}
This configuration option enforces the use of a [Pushed Authorization Requests] flow for this registered client.
To enforce it for all clients see the global [pushed_authorizations enforce](provider.md#enforce) provider configuration
option.
### enforce_pkce
{{< confkey type="bool" default="false" required="no" >}}
This configuration option enforces the use of [PKCE] for this registered client. To enforce it for all clients see the
global [enforce_pkce](provider.md#enforcepkce) provider configuration option.
### pkce_challenge_method
{{< confkey type="string" default="" required="no" >}}
This setting enforces the use of the specified [PKCE] challenge method for this individual client. This setting also
effectively enables the [enforce_pkce](#enforcepkce) option for this client.
Valid values are an empty string, `plain`, or `S256`. It should be noted that `S256` is strongly recommended if the
relying party supports it.
### id_token_signing_alg
{{< confkey type="string" default="RS256" required="no" >}}
The algorithm used to sign the ID Tokens in the token responses.
See the response object section of the
[integration guide](../../../integration/openid-connect/introduction.md#response-object) for more information including
the algorithm column for supported values. In addition to the values listed we also support `none` as a value for this
endpoint.
The algorithm chosen must have a key configured in the [issuer_private_keys](provider.md#issuerprivatekeys) section to
be considered valid.
This option has no effect if the [id_token_signing_key_id](#idtokensigningkid) is specified as the algorithm is
automatically assumed by the configured key.
### id_token_signing_key_id
{{< confkey type="string" required="no" >}}
The key id of the JWK used to sign the ID Tokens in the token responses. This option takes precedence over
[id_token_signing_alg](#idtokensigningalg). The value of this must one of those provided or calculated in the
[issuer_private_keys](provider.md#issuerprivatekeys).
### userinfo_signing_alg
{{< confkey type="string" default="none" required="no" >}}
The algorithm used to sign the userinfo endpoint responses.
See the response object section of the [integration guide](../../../integration/openid-connect/introduction.md#response-object)
for more information including the algorithm column for supported values. In addition to the values listed we also
support `none` as a value for this endpoint.
The algorithm chosen must have a key configured in the [issuer_private_keys](provider.md#issuerprivatekeys) section to
be considered valid.
This option has no effect if the [userinfo_signing_key_id](#userinfosigningkeyid) is specified as the algorithm is
automatically assumed by the configured key.
### userinfo_signing_key_id
{{< confkey type="string" required="no" >}}
The key id of the JWK used to sign the userinfo endpoint responses in the token responses. This option takes precedence
over [userinfo_signing_alg](#userinfosigningalg). The value of this must one of those provided or calculated in the
[issuer_private_keys](provider.md#issuerprivatekeys).
### request_object_signing_alg
{{< confkey type="string" default="RSA256" required="no" >}}
The JWT signing algorithm accepted for request objects.
See the request object section of the
[integration guide](../../../integration/openid-connect/introduction.md#request-object) for more information including
the algorithm column for supported values.
### token_endpoint_auth_method
{{< confkey type="string" default="" required="no" >}}
The registered client authentication mechanism used by this client for the [Token Endpoint]. If no method is defined
the confidential client type will accept any supported method. The public client type defaults to `none` as this
is required by the specification. This may be required as a breaking change in future versions.
Supported values are `client_secret_basic`, `client_secret_post`, `client_secret_jwt`, `private_key_jwt`, and `none`.
See the [integration guide](../../../integration/openid-connect/introduction.md#client-authentication-method) for
more information.
### token_endpoint_auth_signing_alg
{{< confkey type="string" default="RS256" required="no" >}}
The JWT signing algorithm accepted when the [token_endpoint_auth_method](#tokenendpointauthmethod) is configured as
`client_secret_jwt` or `private_key_jwt`.
See the request object section of the [integration guide](../../../integration/openid-connect/introduction.md#request-object)
for more information including the algorithm column for supported values.
It's recommended that you specifically configure this when the following options are configured to specific values
otherwise we assume the default value:
| Configuration Option | Value | Default |
|:----------------------------------------------------------:|:-------------------:|:-------:|
| [token_endpoint_auth_method](#tokenendpointauthsigningalg) | `private_key_jwt` | `RS256` |
| [token_endpoint_auth_method](#tokenendpointauthsigningalg) | `client_secret_jwt` | `HS256` |
### public_keys
This section configures the trusted JSON Web Keys or JWKS for this registered client. This can either be static values
(recommended) or a URI using the `https` scheme. This section is situational required. These are used to validate the
[JWT] assertions from clients.
Required when the following options are configured:
- [request_object_signing_alg](#requestobjectsigningalg)
- [token_endpoint_auth_signing_alg](#tokenendpointauthsigningalg)
Required when the following options are configured to specific values:
- [token_endpoint_auth_method](#tokenendpointauthsigningalg): `private_key_jwt`
#### uri
{{< confkey type="string" required="no" >}}
The fully qualified, `https` scheme, and appropriately signed URI for the JWKS endpoint that implements
[RFC7517 Section 5](https://datatracker.ietf.org/doc/html/rfc7517#section-5). Must not be configured at the same time
as [values](#values). It's recommended that you do not configure this option, but statically configure [values](#values)
instead.
*__Important Note:__ the URL given in this value MUST be resolvable by Authelia and MUST present a certificate signed by
a certificate trusted by your environment. It is beyond our intentions to support anything other than this.*
#### values
{{< confkey type="list(object)" required="situational" >}}
A list of static keys.
##### key_id
{{< confkey type="string" required="yes" >}}
The Key ID used to match the request object's JWT header `kid` value against.
##### use
{{< confkey type="string" default="sig" required="no" >}}
The key usage. Defaults to `sig` which is the only available option at this time.
##### algorithm
{{< confkey type="string" default="RS256" required="situational" >}}
The algorithm for this key. This value typically optional as it can be automatically detected based on the type of key
in some situations. It is however strongly recommended this is set.
See the request object table in the [integration guide](../../../integration/openid-connect/introduction.md#request-object)
for more information. The `Algorithm` column lists supported values, the `Key` column references the required
[key](#key) type constraints that exist for the algorithm, and the `JWK Default Conditions` column briefly explains the
conditions under which it's the default algorithm.
##### key
{{< confkey type="string" required="yes" >}}
The public key portion of the JSON Web Key.
The public key the clients use to sign/encrypt the [OpenID Connect 1.0] asserted [JWT]'s. The key is generated by the
client application or the administrator of the client application.
The key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be either:
* An RSA public key:
* With a key size of at least 2048 bits.
* An ECDSA public key with one of:
* A P-256 elliptical curve.
* A P-384 elliptical curve.
* A P-512 elliptical curve.
If the [certificate_chain](#certificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
##### certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [key](#key) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s.
## Integration
To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party please see the
[integration docs](../../../integration/openid-connect/introduction.md).
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[Token Endpoint]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[JWT]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC6234]: https://datatracker.ietf.org/doc/html/rfc6234
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
[RFC7468]: https://datatracker.ietf.org/doc/html/rfc7468
[RFC6749 Section 2.1]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
[PKCE]: https://datatracker.ietf.org/doc/html/rfc7636
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Subject Identifier Type]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Pairwise Identifier Algorithm]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -1,432 +0,0 @@
---
title: "OpenID Connect 1.0 Provider"
description: "OpenID Connect 1.0 Provider Configuration"
lead: "Authelia can operate as an OpenID Connect 1.0 Provider. This section describes how to configure this."
date: 2023-05-15T10:32:10+10:00
draft: false
images: []
menu:
configuration:
parent: "openid-connect"
weight: 190200
toc: true
aliases:
- /c/oidc
- /docs/configuration/identity-providers/oidc.html
---
__Authelia__ currently supports the [OpenID Connect 1.0] Provider role as an open
[__beta__](../../../roadmap/active/openid-connect.md) feature. We currently do not support the [OpenID Connect 1.0] Relying
Party role. This means other applications that implement the [OpenID Connect 1.0] Relying Party role can use Authelia as
an [OpenID Connect 1.0] Provider similar to how you may use social media or development platforms for login.
The [OpenID Connect 1.0] Relying Party role is the role which allows an application to use GitHub, Google, or other
[OpenID Connect 1.0] Providers for authentication and authorization. We do not intend to support this functionality at
this moment in time.
This section covers the [OpenID Connect 1.0] Provider configuration. For information on configuring individual
registered clients see the [OpenID Connect 1.0 Clients](clients.md) documentation.
More information about the beta can be found in the [roadmap](../../../roadmap/active/openid-connect.md) and in the
[integration](../../../integration/openid-connect/introduction.md) documentation.
## Configuration
The following snippet provides a configuration example for the [OpenID Connect 1.0] Provider. This is not
intended for production use it's used to provide context and an indentation example.
```yaml
identity_providers:
oidc:
hmac_secret: this_is_a_secret_abc123abc123abc
issuer_private_keys:
- key_id: example
algorithm: RS256
use: sig
key: |
-----BEGIN RSA PUBLIC KEY-----
MEgCQQDAwV26ZA1lodtOQxNrJ491gWT+VzFum9IeZ+WTmMypYWyW1CzXKwsvTHDz
9ec+jserR3EMQ0Rr24lj13FL1ib5AgMBAAE=
-----END RSA PUBLIC KEY----
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
issuer_private_key: |
-----BEGIN RSA PUBLIC KEY-----
MEgCQQDAwV26ZA1lodtOQxNrJ491gWT+VzFum9IeZ+WTmMypYWyW1CzXKwsvTHDz
9ec+jserR3EMQ0Rr24lj13FL1ib5AgMBAAE=
-----END RSA PUBLIC KEY----
issuer_certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBWzCCAQWgAwIBAgIQYAKsXhJOXKfyySlmpKicTzANBgkqhkiG9w0BAQsFADAT
MREwDwYDVQQKEwhBdXRoZWxpYTAeFw0yMzA0MjEwMDA3NDRaFw0yNDA0MjAwMDA3
NDRaMBMxETAPBgNVBAoTCEF1dGhlbGlhMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB
AK2i7RlJEYo/Xa6mQmv9zmT0XUj3DcEhRJGPVw2qMyadUFxNg/ZFp7aTcToHMf00
z6T3b7mwdBkCFQOL3Kb7WRcCAwEAAaM1MDMwDgYDVR0PAQH/BAQDAgWgMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADQQB8
Of2iM7fPadmtChCMna8lYWH+lEplj6BxOJlRuGRawxszLwi78bnq0sCR33LU6xMx
1oAPwIHNaJJwC4z6oG9E_DO_NOT_USE=
-----END CERTIFICATE-----
access_token_lifespan: 1h
authorize_code_lifespan: 1m
id_token_lifespan: 1h
refresh_token_lifespan: 90m
enable_client_debug_messages: false
minimum_parameter_entropy: 8
enforce_pkce: public_clients_only
enable_pkce_plain_challenge: false
pushed_authorizations:
enforce: false
context_lifespan: 5m
cors:
endpoints:
- authorization
- token
- revocation
- introspection
allowed_origins:
- https://example.com
allowed_origins_from_client_redirect_uris: false
```
## Options
### hmac_secret
{{< confkey type="string" required="yes" >}}
*__Important Note:__ This can also be defined using a [secret](../../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
The HMAC secret used to sign the [JWT]'s. The provided string is hashed to a SHA256 ([RFC6234]) byte string for the
purpose of meeting the required format.
It's __strongly recommended__ this is a
[Random Alphanumeric String](../../../reference/guides/generating-secure-values.md#generating-a-random-alphanumeric-string)
with 64 or more characters.
### issuer_private_keys
{{< confkey type="list(object" required="no" >}}
The list of JWKS instead of or in addition to the [issuer_private_key](#issuerprivatekey) and
[issuer_certificate_chain](#issuercertificatechain). Can also accept ECDSA Private Key's and Certificates.
The default key for each algorithm is is decided based on the order of this list. The first key for each algorithm is
considered the default if a client is not configured to use a specific key id. For example if a client has
[id_token_signing_alg](clients.md#idtokensigningalg) `ES256` and [id_token_signing_key_id](clients.md#idtokensigningkid) is
not specified then the first `ES256` key in this list is used.
#### key_id
{{< confkey type="string" default="<thumbprint of public key>" required="no" >}}
Completely optional, and generally discouraged unless there is a collision between the automatically generated key id's.
If provided must be a unique string with 100 or less characters, with a recommendation to use a length less
than 10. In addition it must meet the following rules:
- Match the regular expression `^[a-zA-Z0-9](([a-zA-Z0-9._~-]*)([a-zA-Z0-9]))?$` which should enforce the following rules:
- Start with an alphanumeric character.
- End with an alphanumeric character.
- Only contain the [RFC3986 Unreserved Characters](https://datatracker.ietf.org/doc/html/rfc3986#section-2.3).
The default if this value is omitted is the first 7 characters of the public key SHA256 thumbprint encoded into
hexadecimal.
#### use
{{< confkey type="string" default="sig" required="no" >}}
The key usage. Defaults to `sig` which is the only available option at this time.
#### algorithm
{{< confkey type="string" default="RS256" required="situational" >}}
The algorithm for this key. This value typically optional as it can be automatically detected based on the type of key
in some situations.
See the response object table in the [integration guide](../../../integration/openid-connect/introduction.md#response-object)
for more information. The `Algorithm` column lists supported values, the `Key` column references the required
[key](#key) type constraints that exist for the algorithm, and the `JWK Default Conditions` column briefly explains the
conditions under which it's the default algorithm.
At least one `RSA256` key must be provided.
#### key
{{< confkey type="string" required="yes" >}}
The private key associated with this key entry.
The private key used to sign/encrypt the [OpenID Connect 1.0] issued [JWT]'s. The key must be generated by the
administrator and can be done by following the
[Generating an RSA Keypair](../../../reference/guides/generating-secure-values.md#generating-an-rsa-keypair) guide.
The private key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be one of:
* An RSA key with a key size of at least 2048 bits.
* An ECDSA private key with one of the P-256, P-384, or P-521 elliptical curves.
If the [certificate_chain](#certificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
#### certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [key](#key) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When configured it enables the [x5c] and [x5t]
JSON key's in the JWKs [Discoverable Endpoint](../../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://datatracker.ietf.org/doc/html/rfc7517
[x5c]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
[x5t]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.8
The first certificate in the chain must have the public key for the [key](#key), each certificate in the chain must be
valid for the current date, and each certificate in the chain should be signed by the certificate immediately following
it if present.
### issuer_private_key
{{< confkey type="string" required="yes" >}}
The private key used to sign/encrypt the [OpenID Connect 1.0] issued [JWT]'s. The key must be generated by the
administrator and can be done by following the
[Generating an RSA Keypair](../../../reference/guides/generating-secure-values.md#generating-an-rsa-keypair) guide.
This private key is automatically appended to the [issuer_private_keys](#issuerprivatekeys) and assumed to be for the
`RS256` algorithm. If provided it is always the first key in this list. As such this key is assumed to be the default
for `RS256` if provided.
The issuer private key *__MUST__*:
* Be a PEM block encoded in the DER base64 format ([RFC4648]).
* Be an RSA private key:
* With a key size of at least 2048 bits.
If the [issuer_certificate_chain](#issuercertificatechain) is provided the private key must include matching public
key data for the first certificate in the chain.
### issuer_certificate_chain
{{< confkey type="string" required="no" >}}
The certificate chain/bundle to be used with the [issuer_private_key](#issuerprivatekey) DER base64 ([RFC4648])
encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When configured it enables the [x5c] and [x5t]
JSON key's in the JWKs [Discoverable Endpoint](../../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://datatracker.ietf.org/doc/html/rfc7517
[x5c]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7
[x5t]: https://datatracker.ietf.org/doc/html/rfc7517#section-4.8
The first certificate in the chain must have the public key for the [issuer_private_key](#issuerprivatekey), each
certificate in the chain must be valid for the current date, and each certificate in the chain should be signed by the
certificate immediately following it if present.
### access_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
The maximum lifetime of an access token. It's generally recommended keeping this short similar to the default.
For more information read these docs about [token lifespan].
### authorize_code_lifespan
{{< confkey type="duration" default="1m" required="no" >}}
The maximum lifetime of an authorize code. This can be rather short, as the authorize code should only be needed to
obtain the other token types. For more information read these docs about [token lifespan].
### id_token_lifespan
{{< confkey type="duration" default="1h" required="no" >}}
The maximum lifetime of an ID token. For more information read these docs about [token lifespan].
### refresh_token_lifespan
{{< confkey type="string" default="90m" required="no" >}}
The maximum lifetime of a refresh token. The
refresh token can be used to obtain new refresh tokens as well as access tokens or id tokens with an
up-to-date expiration. For more information read these docs about [token lifespan].
A good starting point is 50% more or 30 minutes more (which ever is less) time than the highest lifespan out of the
[access token lifespan](#accesstokenlifespan), the [authorize code lifespan](#authorizecodelifespan), and the
[id token lifespan](#idtokenlifespan). For instance the default for all of these is 60 minutes, so the default refresh
token lifespan is 90 minutes.
### enable_client_debug_messages
{{< confkey type="boolean" default="false" required="no" >}}
Allows additional debug messages to be sent to the clients.
### minimum_parameter_entropy
{{< confkey type="integer" default="8" required="no" >}}
This controls the minimum length of the `nonce` and `state` parameters.
*__Security Notice:__* Changing this value is generally discouraged, reducing it from the default can theoretically
make certain scenarios less secure. It is highly encouraged that if your OpenID Connect 1.0 Relying Party does not send
these parameters or sends parameters with a lower length than the default that they implement a change rather than
changing this value.
This restriction can also be disabled entirely when set to `-1`.
### enforce_pkce
{{< confkey type="string" default="public_clients_only" required="no" >}}
[Proof Key for Code Exchange](https://datatracker.ietf.org/doc/html/rfc7636) enforcement policy: if specified, must be
either `never`, `public_clients_only` or `always`.
If set to `public_clients_only` (default), [PKCE] will be required for public clients using the
[Authorization Code Flow].
When set to `always`, [PKCE] will be required for all clients using the Authorization Code flow.
*__Security Notice:__* Changing this value to `never` is generally discouraged, reducing it from the default can
theoretically make certain client-side applications (mobile applications, SPA) vulnerable to CSRF and authorization code
interception attacks.
### enable_pkce_plain_challenge
{{< confkey type="boolean" default="false" required="no" >}}
Allows [PKCE] `plain` challenges when set to `true`.
*__Security Notice:__* Changing this value is generally discouraged. Applications should use the `S256` [PKCE] challenge
method instead.
### pushed_authorizations
Controls the behaviour of [Pushed Authorization Requests].
#### enforce
{{< confkey type="boolean" default="false" required="no" >}}
When enabled all authorization requests must use the [Pushed Authorization Requests] flow.
#### context_lifespan
{{< confkey type="duration" default="5m" required="no" >}}
The maximum amount of time between the [Pushed Authorization Requests] flow being initiated and the generated
`request_uri` being utilized by a client.
### cors
Some [OpenID Connect 1.0] Endpoints need to allow cross-origin resource sharing, however some are optional. This section allows
you to configure the optional parts. We reply with CORS headers when the request includes the Origin header.
#### endpoints
{{< confkey type="list(string)" required="no" >}}
A list of endpoints to configure with cross-origin resource sharing headers. It is recommended that the `userinfo`
option is at least in this list. The potential endpoints which this can be enabled on are as follows:
* authorization
* pushed-authorization-request
* token
* revocation
* introspection
* userinfo
#### allowed_origins
{{< confkey type="list(string)" required="no" >}}
A list of permitted origins.
Any origin with https is permitted unless this option is configured or the
[allowed_origins_from_client_redirect_uris](#allowedoriginsfromclientredirecturis) option is enabled. This means
you must configure this option manually if you want http endpoints to be permitted to make cross-origin requests to the
[OpenID Connect 1.0] endpoints, however this is not recommended.
Origins must only have the scheme, hostname and port, they may not have a trailing slash or path.
In addition to an Origin URI, you may specify the wildcard origin in the allowed_origins. It MUST be specified by itself
and the [allowed_origins_from_client_redirect_uris](#allowedoriginsfromclientredirecturis) MUST NOT be enabled. The
wildcard origin is denoted as `*`. Examples:
```yaml
identity_providers:
oidc:
cors:
allowed_origins: "*"
```
```yaml
identity_providers:
oidc:
cors:
allowed_origins:
- "*"
```
#### allowed_origins_from_client_redirect_uris
{{< confkey type="boolean" default="false" required="no" >}}
Automatically adds the origin portion of all redirect URI's on all clients to the list of
[allowed_origins](#allowed_origins), provided they have the scheme http or https and do not have the hostname of
localhost.
### clients
See the [OpenID Connect 1.0 Registered Clients](clients.md) documentation for configuring clients.
## Integration
To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party please see the
[integration docs](../../../integration/openid-connect/introduction.md).
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[Token Endpoint]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[JWT]: https://datatracker.ietf.org/doc/html/rfc7519
[RFC6234]: https://datatracker.ietf.org/doc/html/rfc6234
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
[RFC7468]: https://datatracker.ietf.org/doc/html/rfc7468
[RFC6749 Section 2.1]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.1
[PKCE]: https://datatracker.ietf.org/doc/html/rfc7636
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Subject Identifier Type]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Pairwise Identifier Algorithm]: https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -16,7 +16,7 @@ Environment variables are applied after the configuration file meaning anything
overrides the configuration files.
*__Please Note:__ It is not possible to configure several sections at this time, these include but may not be
limited to the rules section in access control, the clients section in the OpenID Connect 1.0 Provider, the cookies
limited to the rules section in access control, the clients section in the OpenID Connect identity provider, the cookies
section of in session, and the authz section in the server endpoints.*
## Prefix
@ -39,7 +39,7 @@ For example this YAML configuration:
```yaml
log:
level: 'info'
level: info
server:
buffers:
read: 4096

View File

@ -63,9 +63,9 @@ authelia --config configuration.yml,config-acl.yml,config-other.yml
Authelia's configuration files use the YAML format. A template with all possible options can be found at the root of the
repository {{< github-link name="here" path="config.template.yml" >}}.
*__Important Note:__ You should not have configuration sections such as Access Control Rules or OpenID Connect 1.0
clients configured in multiple files. If you wish to split these into their own files that is fine, but if you have two
files that specify these sections and expect them to merge properly you are asking for trouble.*
*__Important Note:__ You should not have configuration sections such as Access Control Rules or OpenID Connect clients
configured in multiple files. If you wish to split these into their own files that is fine, but if you have two files that
specify these sections and expect them to merge properly you are asking for trouble.*
### Container

View File

@ -77,9 +77,9 @@ other configuration using the environment but instead of loading a file the valu
[authentication_backend.ldap.password]: ../first-factor/ldap.md#password
[authentication_backend.ldap.tls.certificate_chain]: ../first-factor/ldap.md#tls
[authentication_backend.ldap.tls.private_key]: ../first-factor/ldap.md#tls
[identity_providers.oidc.issuer_certificate_chain]: ../identity-providers/openid-connect.md#issuercertificatechain
[identity_providers.oidc.issuer_private_key]: ../identity-providers/openid-connect.md#issuerprivatekey
[identity_providers.oidc.hmac_secret]: ../identity-providers/openid-connect.md#hmacsecret
[identity_providers.oidc.issuer_certificate_chain]: ../identity-providers/open-id-connect.md#issuercertificatechain
[identity_providers.oidc.issuer_private_key]: ../identity-providers/open-id-connect.md#issuerprivatekey
[identity_providers.oidc.hmac_secret]: ../identity-providers/open-id-connect.md#hmacsecret
## Secrets in configuration file

View File

@ -17,19 +17,15 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
certificates_directory: '/config/certs/'
default_redirection_url: 'https://home.example.com:8080/'
jwt_secret: 'v3ry_important_s3cr3t'
theme: 'light'
certificates_directory: /config/certs/
default_redirection_url: https://home.example.com:8080/
jwt_secret: v3ry_important_s3cr3t
theme: light
```
## Options
This section describes the individual configuration options.
### certificates_directory
This option defines the location of additional certificates to load into the trust chain specifically for Authelia.

View File

@ -18,20 +18,16 @@ The logging section tunes the logging settings.
## Configuration
{{< config-alert-example >}}
```yaml
log:
level: 'info'
format: 'text'
file_path: ''
level: info
format: text
file_path: ""
keep_stdout: false
```
## Options
This section describes the individual configuration options.
### level
{{< confkey type="string" default="info" required="no" >}}

View File

@ -23,21 +23,17 @@ unless configured otherwise.
## Configuration
{{< config-alert-example >}}
```yaml
ntp:
address: 'udp://time.cloudflare.com:123'
address: "time.cloudflare.com:123"
version: 3
max_desync: '3s'
max_desync: 3s
disable_startup_check: false
disable_failure: false
```
## Options
This section describes the individual configuration options.
### address
{{< confkey type="string" default="time.cloudflare.com:123" required="no" >}}
@ -45,28 +41,6 @@ This section describes the individual configuration options.
Determines the address of the NTP server to retrieve the time from. The format is `<host>:<port>`, and both of these are
required.
### address
{{< confkey type="address" default="udp://time.cloudflare.com:123" required="no" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
Configures the address for the NTP Server. The address itself is a connector and the scheme must be `udp`,
`udp4`, or `udp6`.
__Examples:__
```yaml
ntp:
address: 'udp://127.0.0.1:123'
```
```yaml
ntp:
address: 'udp6://[fd00:1111:2222:3333::1]:123'
```
### version
{{< confkey type="integer" default="4" required="no" >}}
@ -77,8 +51,8 @@ Determines the NTP version supported. Valid values are 3 or 4.
{{< confkey type="duration" default="3s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
This is used to tune the acceptable desync from the time reported from the NTP server.

View File

@ -14,8 +14,6 @@ toc: true
## Configuration
{{< config-alert-example >}}
```yaml
privacy_policy:
enabled: false
@ -25,8 +23,6 @@ privacy_policy:
## Options
This section describes the individual configuration options.
### enabled
{{< confkey type="boolean" default="false" required="no" >}}
@ -44,7 +40,7 @@ accepted is recorded and checked in the browser
If the user has not accepted the policy they should not be able to interact with the Authelia UI via normal means.
Administrators who are required to abide by the [GDPR] or other privacy laws should be advised that
[OpenID Connect 1.0](../identity-providers/openid-connect.md) clients configured with the `implicit` consent mode are
[OpenID Connect 1.0](../identity-providers/open-id-connect.md) clients configured with the `implicit` consent mode are
unlikely to trigger the display of the Authelia UI if the user is already authenticated.
We wont be adding checks like this to the `implicit` consent mode when that mode in particular is unlikely to be

View File

@ -16,32 +16,22 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
server:
endpoints:
authz:
forward-auth:
implementation: 'ForwardAuth'
authn_strategies:
- name: 'HeaderProxyAuthorization'
- name: 'CookieSession'
implementation: ForwardAuth
authn_strategies: []
ext-authz:
implementation: 'ExtAuthz'
authn_strategies:
- name: 'HeaderProxyAuthorization'
- name: 'CookieSession'
implementation: ExtAuthz
authn_strategies: []
auth-request:
implementation: 'AuthRequest'
authn_strategies:
- name: 'HeaderAuthRequestProxyAuthorization'
- name: 'CookieSession'
implementation: AuthRequest
authn_strategies: []
legacy:
implementation: 'Legacy'
authn_strategies:
- name: 'HeaderLegacy'
- name: 'CookieSession'
implementation: Legacy
authn_strategies: []
```
## Name

View File

@ -17,72 +17,91 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
server:
address: 'tcp://:9091/'
host: 0.0.0.0
port: 9091
path: ""
disable_healthcheck: false
tls:
key: ''
certificate: ''
key: ""
certificate: ""
client_certificates: []
headers:
csp_template: ''
csp_template: ""
buffers:
read: 4096
write: 4096
timeouts:
read: '6s'
write: '6s'
idle: '30s'
read: 6s
write: 6s
idle: 30s
endpoints:
enable_pprof: false
enable_expvars: false
authz:
forward-auth:
implementation: 'ForwardAuth'
implementation: ForwardAuth
authn_strategies: []
ext-authz:
implementation: 'ExtAuthz'
implementation: ExtAuthz
authn_strategies: []
auth-request:
implementation: 'AuthRequest'
implementation: AuthRequest
authn_strategies: []
legacy:
implementation: 'Legacy'
implementation: Legacy
authn_strategies: []
```
## Options
### address
## host
{{< confkey type="address" default="tcp://:9091/" required="no" >}}
{{< confkey type="string" default="0.0.0.0" required="no" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
Defines the address to listen on. See also [port](#port). Should typically be `0.0.0.0` or `127.0.0.1`, the former for
containerized environments and the later for daemonized environments like init.d and systemd.
Configures the listener address for the Main HTTP Server. The address itself is a listener and the scheme must either be
the `unix` scheme or one of the `tcp` schemes. It can configure the host, port, and path the listener responds to. If
the path is configured to anything other than `/` Authelia will handle requests for both `/` and the configured path.
Note: If utilising an IPv6 literal address it must be enclosed by square brackets and quoted:
__Examples:__
```yaml
host: "[fd00:1111:2222:3333::1]"
```
### port
{{< confkey type="integer" default="9091" required="no" >}}
Defines the port to listen on. See also [host](#host).
### path
{{< confkey type="string " required="no" >}}
Authelia by default is served from the root `/` location, either via its own domain or subdomain.
Modifying this setting will allow you to serve Authelia out from a specified base path. Please note
that currently only a single level path is supported meaning slashes are not allowed, and only
alphanumeric characters are supported.
__Example:__
```yaml
server:
address: tcp://127.0.0.1:9091/
path: ""
```
*Works for https://auth.example.com/, https://example.com/, etc*.
__Example:__
```yaml
server:
address: tcp://127.0.0.1:9091/subpath
path: authelia
```
```yaml
server:
address: unix:///var/run/authelia.sock
```
*Works for https://auth.example.com/authelia/, https://example.com/authelia/, etc*.
### asset_path
@ -152,19 +171,13 @@ research about how browsers utilize and understand this header before attempting
### buffers
*__Reference Note:__ This configuration option uses the
[Server buffers common structure](../prologue/common.md#server-buffers). Please see the
[documentation](../prologue/common.md#server-buffers) on this structure for more information.*
Configures the server buffers.
Configures the server buffers. See the [Server Buffers](../prologue/common.md#server-buffers) documentation for more
information.
### timeouts
*__Reference Note:__ This configuration option uses the
[Server timeouts common structure](../prologue/common.md#server-timeouts). Please see the
[documentation](../prologue/common.md#server-timeouts) on this structure for more information.*
Configures the server timeouts.
Configures the server timeouts. See the [Server Timeouts](../prologue/common.md#server-timeouts) documentation for more
information.
### endpoints
@ -179,11 +192,11 @@ Enables the go [pprof](https://pkg.go.dev/net/http/pprof) endpoints.
#### enable_expvars
{{< confkey type="boolean" default="false" required="no" >}}
*__Security Note:__ This is a developer endpoint. __DO NOT__ enable it unless you know why you're enabling it.
__DO NOT__ enable this in production.*
{{< confkey type="boolean" default="false" required="no" >}}
Enables the go [expvar](https://pkg.go.dev/expvar) endpoints.
#### authz

View File

@ -21,19 +21,15 @@ This method will use the plain text email template for readability purposes.
## Configuration
{{< config-alert-example >}}
```yaml
notifier:
disable_startup_check: false
filesystem:
filename: '/config/notification.txt'
filename: /config/notification.txt
```
## Options
This section describes the individual configuration options.
### filename
{{< confkey type="string" required="yes" >}}

View File

@ -16,8 +16,6 @@ Authelia sends messages to users in order to verify their identity.
## Configuration
{{< config-alert-example >}}
```yaml
notifier:
disable_startup_check: false
@ -28,8 +26,6 @@ notifier:
## Options
This section describes the individual configuration options.
### disable_startup_check
{{< confkey type="boolean" default="false" required="no" >}}

View File

@ -17,28 +17,27 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
notifier:
disable_startup_check: false
smtp:
address: 'smtp://127.0.0.1:25'
timeout: '5s'
username: 'test'
password: 'password'
host: 127.0.0.1
port: 1025
timeout: 5s
username: test
password: password
sender: "Authelia <admin@example.com>"
identifier: 'localhost'
identifier: localhost
subject: "[Authelia] {title}"
startup_check_address: 'test@authelia.com'
startup_check_address: test@authelia.com
disable_require_tls: false
disable_starttls: false
disable_html_emails: false
tls:
server_name: 'smtp.example.com'
server_name: smtp.example.com
skip_verify: false
minimum_version: 'TLS1.2'
maximum_version: 'TLS1.3'
minimum_version: TLS1.2
maximum_version: TLS1.3
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
@ -110,43 +109,35 @@ notifier:
## Options
This section describes the individual configuration options.
### host
### address
{{< confkey type="integer" required="yes" >}}
{{< confkey type="address" required="yes" >}}
The hostname of the SMTP server.
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
If utilising an IPv6 literal address it must be enclosed by square brackets and quoted:
Configures the address for the SMTP Server. The address itself is a connector and the scheme must be `smtp`,
`submission`, or `submissions`. The only difference between these schemes are the default ports and `submissions`
requires a TLS transport per [SMTP Ports Security Measures][docs-security-smtp-port], whereas `submission` and `smtp`
use a standard TCP transport and typically enforce StartTLS.
```yaml
host: "[fd00:1111:2222:3333::1]"
```
### port
{{< confkey type="integer" required="yes" >}}
The port the SMTP service is listening on.
A connection is securely established with TLS after a succesful STARTTLS negotiation.
[Port 465 is an exception][docs-security-smtp-port] when supported by the mail server as a `submissions` service port.
STARTTLS negotiation is not required for this port, the connection is implicitly established with TLS.
[docs-security-smtp-port]: ../../overview/security/measures.md#smtp-ports
__Examples:__
```yaml
notifier:
smtp:
address: 'smtp://127.0.0.1:25'
```
```yaml
notifier:
smtp:
address: 'submissions://[fd00:1111:2222:3333::1]:465'
```
### timeout
{{< confkey type="duration" default="5s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The SMTP connection timeout.
### username
@ -232,11 +223,8 @@ mixed emails which contain both HTML and text so this option is rarely necessary
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
Controls the TLS connection validation parameters for either StartTLS or the TLS socket.
Controls the TLS connection validation process. You can see how to configure the tls section
[here](../prologue/common.md#tls-configuration).
## Using Gmail
@ -246,10 +234,10 @@ You need to generate an app password in order to use Gmail SMTP servers. The pro
```yaml
notifier:
smtp:
username: 'myaccount@gmail.com'
username: myaccount@gmail.com
# Password can also be set using a secret: https://www.authelia.com/configuration/methods/secrets/
password: 'yourapppassword'
sender: 'admin@example.com'
host: 'smtp.gmail.com'
password: yourapppassword
sender: admin@example.com
host: smtp.gmail.com
port: 587
```

View File

@ -14,184 +14,103 @@ aliases:
- /c/common
---
## Syntax
## Duration Notation Format
The following represent common syntax used within the configuration which have specific format requirements that are
used in multiple areas. This is intended on assisting in understanding these specific values, and not as a specific
guide on configuring any particular instance.
We have implemented a string/integer based notation for configuration options that take a duration of time. This section
describes the implementation of this. You can use this implementation in various areas of configuration such as:
### Duration
* session:
* expiration
* inactivity
* remember_me
* regulation:
* ban_time
* find_time
* ntp:
* max_desync
* webauthn:
* timeout
The base type for this syntax is a string, and it also handles integers however this is discouraged.
The way this format works is you can either configure an integer or a string in the specific configuration areas. If you
supply an integer, it is considered a representation of seconds. If you supply a string, it parses the string in blocks
of quantities and units (number followed by a unit letter). For example `5h` indicates a quantity of 5 units of `h`.
If you supply an integer, it is considered a representation of seconds. If you supply a string, it parses the string in
blocks of quantities and units (number followed by a unit letter). For example `5h` indicates a quantity of 5 units
of `h`.
The following is ignored or stripped from the input:
The following is ignored:
- all spaces
- leading zeros
- the word `and`
While you can use multiple of these blocks in combination, we suggest keeping it simple and use a single value. In
addition it's important to note that the format while somewhat human readable still requires you closely follow the
expected formats.
While you can use multiple of these blocks in combination, we suggest keeping it simple and use a single value.
#### Unit Legend
### Unit Legend
The following is a legend for the unit formats available in this syntax. The long form units are only available from
v4.38.0 or newer.
#### Short Units
| Unit | Short Unit | Human Readable Long Unit |
|:------------:|:----------:|:-----------------------------:|
| Years | `y` | `year`, `years` |
| Months | `M` | `month`, `months` |
| Weeks | `w` | `week`, `weeks` |
| Days | `d` | `day`, `days` |
| Hours | `h` | `hour`, `hours` |
| Minutes | `m` | `minute`, `minutes` |
| Seconds | `s` | `second`, `seconds` |
| Milliseconds | `ms` | `millisecond`, `milliseconds` |
These values have been available for a long time.
#### Examples
| Unit | Associated Letter |
|:-------:|:-----------------:|
| Years | y |
| Months | M |
| Weeks | w |
| Days | d |
| Hours | h |
| Minutes | m |
| Seconds | s |
| Desired Value | Configuration Examples (Short) | Configuration Examples (Long) |
|:---------------------:|:-------------------------------------:|:--------------------------------------:|
| 1 hour and 30 minutes | `90m` or `1h30m` or `5400` or `5400s` | `1 hour and 30 minutes` |
| 1 day | `1d` or `24h` or `86400` or `86400s` | `1 day` |
| 10 hours | `10h` or `600m` or `9h60m` or `36000` | `10 hours` |
#### Long Units
### Address
These values are more human readable but have only been available since v4.38.0.
The base type for this syntax is a string.
| Unit | Human Readable Long Unit |
|:------------:|:-----------------------------:|
| Years | `year`, `years` |
| Months | `month`, `months` |
| Weeks | `week`, `weeks` |
| Days | `day`, `days` |
| Hours | `hour`, `hours` |
| Minutes | `minute`, `minutes` |
| Seconds | `second`, `seconds` |
| Milliseconds | `millisecond`, `milliseconds` |
The address type is a string that indicates how to configure a listener (i.e. listening for connections) or connector
(i.e. opening remote connections), which are the two primary categories of addresses.
### Examples
| Desired Value | Configuration Examples |
|:---------------------:|:-------------------------------------:|
| 1 hour and 30 minutes | `90m` or `1h30m` or `5400` or `5400s` |
| 1 day | `1d` or `24h` or `86400` or `86400s` |
| 10 hours | `10h` or `600m` or `9h60m` or `36000` |
#### Format
## Address
This section outlines the format for these strings. The formats use a conventional POSIX format to indicate optional and
required elements. The square brackets `[]` surround optional portions, and the angled brackets `<>` surround required
portions. Required portions may exist within optional portions, in which case they are often accompanied with other
format specific text which indicates if the accompanying text exists then it is actually required, otherwise it's
entirely optional.
The address type is a string that takes the following format:
```text
[<scheme>://]<ip>[:<port>]
```
The square brackets indicate optional sections, and the angled brackets indicate required sections. The following
sections elaborate on this. Sections may only be optional for the purposes of parsing, there may be a configuration
requirement that one of these is provided.
##### Hostname
The following format represents the hostname format. It's valid for both a listener and connector in most instances.
Refer to the individual documentation for an option for clarity. In this format as per the notation the scheme and port
are optional. The default for these when not provided varies.
```text
[<scheme>://]<hostname>[:<port>][/<path>]
```
##### Port
The following format represents the port format. It's valid only for a listener in most instances.
Refer to the individual documentation for an option for clarity. In this format as per the notation the scheme and
hostname are optional. The default for the scheme when not provided varies, and the default for the hostname is all
available addresses when not provided.
```text
[<scheme>://][hostname]:<port>[/<path>]
```
##### Unix Domain Socket
The following format represents the unix domain socket format. It's valid for both a listener and connector in most
instances. Refer to the individual documentation for an option for clarity. In this format as per the notation there
are no optional portions.
The Unix Domain Socket format also accepts a query string. The following query parameters control certain behaviour of
this address type.
| Parameter | Listeners | Connectors | Purpose |
|:---------:|:---------:|:----------:|:------------------------------------------------------------------------------------------------------------------------------------:|
| `umask` | Yes | No | Sets the umask prior to creating the socket and restores it after creating it. The value must be an octal number with 3 or 4 digits. |
```text
unix://<path>
```
```text
unix://<path>?umask=0022
```
##### Examples
Various examples for these formats.
```text
0.0.0.0
tcp://0.0.0.0
tcp://0.0.0.0/subpath
tcp://0.0.0.0:9091
tcp://0.0.0.0:9091/subpath
tcp://:9091
tcp://:9091/subpath
0.0.0.0:9091
udp://0.0.0.0:123
udp://:123
unix:///var/lib/authelia.sock
```
#### scheme
### scheme
The entire scheme is optional, but if the scheme host delimiter `://` is in the string, the scheme must be present. The
scheme must be one of the following (the listeners and connectors columns indicate support for the scheme on the
respective address type):
scheme must be one of `tcp://`, or `udp://`. The default scheme is `tcp://`.
| Scheme | Listeners | Connectors | Default Port | Notes |
|:-------------:|:---------:|:----------:|:------------:|:-------------------------------------------------------------------------:|
| `tcp` | Yes | Yes | N/A | Standard TCP Socket which allows IPv4 and/or IPv6 addresses |
| `tcp4` | Yes | Yes | N/A | Standard TCP Socket which allows only IPv4 addresses |
| `tcp6` | Yes | Yes | N/A | Standard TCP Socket which allows only IPv6 addresses |
| `udp` | Yes | Yes | N/A | Standard UDP Socket which allows IPv4 and/or IPv6 addresses |
| `udp4` | Yes | Yes | N/A | Standard UDP Socket which allows only IPv4 addresses |
| `udp6` | Yes | Yes | N/A | Standard UDP Socket which allows only IPv6 addresses |
| `unix` | Yes | Yes | N/A | Standard Unix Domain Socket which allows only absolute paths |
| `ldap` | No | Yes | 389 | Remote LDAP connection via TCP with implicit TLS via StartTLS |
| `ldaps` | No | Yes | 636 | Remote LDAP connection via TCP with explicit TLS |
| `ldapi` | No | Yes | N/A | LDAP connection via Unix Domain Socket |
| `smtp` | No | Yes | 25 | Remote SMTP connection via TCP using implicit TLS via StartTLS |
| `submission` | No | Yes | 587 | Remote SMTP Submission connection via TCP using implicit TLS via StartTLS |
| `submissions` | No | Yes | 465 | Remote SMTP Submission connection via TCP using explicit TLS |
### ip
If the scheme is absent, the default scheme is assumed. If the address has a `/` prefix it's assumed to be `unix`,
otherwise it's assumed to be`tcp`. If the scheme is `unix` it must be suffixed with an absolute path i.e.
`/var/local/authelia.sock` would be represented as `unix:///var/run/authelia.sock`.
The IP is required. If specifying an IPv6 it should be wrapped in square brackets. For example for the IPv6 address
`::1` with the `tcp://` scheme and port `80`: `tcp://[::1]:80`.
#### hostname
### port
The hostname is required if the scheme is one of the `tcp` or `udp` schemes and there is no [port](#port) specified. It
can be any IP that is locally addressable or a hostname which resolves to a locally addressable IP.
The entire port is optional, but if the host port delimiter `:` exists it must also include a numeric port.
If specifying an IPv6 it should be wrapped in square brackets. For example for the IPv6 address `::1` with the `tcp`
scheme and port `80` the correct address would be `tcp://[::1]:80`.
## Regular Expressions
#### port
The hostname is required if the scheme is one of the `tcp` or `udp` schemes and there is no [hostname](#hostname)
specified.
### Regular Expressions
We have several sections of configuration that utilize regular expressions. We use the Google RE2 regular expression
engine which is the full Go regular expression syntax engine, the syntax of which is described
[here](https://github.com/google/re2/wiki/Syntax) by the authors. It's very similar to regular expression engines like
PCRE, Perl, and Python; with the major exceptions being that it doesn't have backtracking.
It's recommended to validate your regular expressions manually either via tools like [Regex 101](https://regex101.com/)
(ensure you pick the `Golang` option) or some other means.
We have several sections of configuration that utilize regular expressions. It's recommended to validate your regex
manually either via tools like [Regex 101](https://regex101.com/) (ensure you pick the `Golang` option) or some other
means.
It's important when attempting to utilize a backslash that it's utilized correctly. The YAML parser is likely to parse
this as you trying to use YAML escape syntax instead of regex escape syntax. To avoid this use single quotes instead of
@ -209,30 +128,19 @@ Bad Example:
domain_regex: "^(admin|secure)\.example\.com$"
```
## Structures
The following represent common data structures used within the configuration which have specific requirements that are
used in multiple areas. This is intended on assisting in understanding these specific structures, and not as a specific
guide on configuring any particular instance.
### TLS Configuration
## TLS Configuration
Various sections of the configuration use a uniform configuration section called TLS. Notably LDAP and SMTP.
This section documents the usage.
Various sections of the configuration use a uniform configuration section called `tls` which configure TLS socket and
TLS verification parameters. Notably the [LDAP](../first-factor/ldap.md#tls), [SMTP](../notifications/smtp.md#tls),
[PostgreSQL](../storage/postgres.md#tls), [MySQL](../storage/mysql.md#tls), and [Redis](../session/redis.md#tls)
sections. This section documents the common parts of this structure.
#### server_name
### server_name
{{< confkey type="string" required="no" >}}
The key `server_name` overrides the name checked against the certificate in the verification process. Useful if you
require an IP address for the host of the backend service but want to verify a specific certificate server name.
#### skip_verify
### skip_verify
{{< confkey type="boolean" default="false" required="no" >}}
@ -240,7 +148,7 @@ The key `skip_verify` completely negates validating the certificate of the backe
instead you should tweak the `server_name` option, and the global option
[certificates directory](../miscellaneous/introduction.md#certificatesdirectory).
#### minimum_version
### minimum_version
{{< confkey type="string" default="TLS1.2" required="no" >}}
@ -249,7 +157,7 @@ The possible values are `TLS1.3`, `TLS1.2`, `TLS1.1`, `TLS1.0`, `SSL3.0`. Anythi
are very old and deprecated. You should avoid using these and upgrade your backend service instead of decreasing
this value. At the time of this writing `SSL3.0` will always produce errors.
#### maximum_version
### maximum_version
{{< confkey type="string" default="TLS1.3" required="no" >}}
@ -258,7 +166,7 @@ The possible values are `TLS1.3`, `TLS1.2`, `TLS1.1`, `TLS1.0`, `SSL3.0`. Anythi
are very old and deprecated. You should avoid using these and upgrade your backend service instead of decreasing
this value. At the time of this writing `SSL3.0` will always produce errors.
#### certificate_chain
### certificate_chain
{{< confkey type="string" required="no" >}}
@ -267,7 +175,7 @@ the server.
The value must be one or more certificates encoded in the DER base64 ([RFC4648]) encoded PEM format.
#### private_key
### private_key
{{< confkey type="string" required="no" >}}
@ -276,69 +184,49 @@ especially for containerized deployments.*
The private key to be used with the [certificate_chain](#certificatechain) for mutual TLS authentication.
The value must be one private key encoded in the DER base64 ([RFC4648]) encoded PEM format. If more than one certificate
is provided, in top down order, each certificate must be signed by the next certificate if provided.
The value must be one private key encoded in the DER base64 ([RFC4648]) encoded PEM format.
[RFC4648]: https://datatracker.ietf.org/doc/html/rfc4648
### Server Buffers
## Server Buffers
Various sections of the configuration use a uniform configuration section called `buffers` which configure HTTP server
buffers. Notably the [server](../miscellaneous/server.md#buffers) and
[metrics telemetry](../telemetry/metrics.md#buffers) sections. This section documents the common parts of this
structure.
#### read
### read
{{< confkey type="integer" default="4096" required="no" >}}
Configures the maximum request size. The default of 4096 is generally sufficient for most use cases.
#### write
### write
{{< confkey type="integer" default="4096" required="no" >}}
Configures the maximum response size. The default of 4096 is generally sufficient for most use cases.
### Server Timeouts
## Server Timeouts
Various sections of the configuration use a uniform configuration section called `timeouts` which configure HTTP server
timeouts. Notably the [server](../miscellaneous/server.md#timeouts) and
[metrics telemetry](../telemetry/metrics.md#timeouts) sections. This section documents the common parts of this
structure.
#### read
### read
{{< confkey type="duration" default="6s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](#duration-notation-format). Please see the
[common options](#duration-notation-format) documentation for information on this format.*
Configures the server read timeout.
#### write
### write
{{< confkey type="duration" default="6s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](#duration).
Please see the [documentation](#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](#duration-notation-format). Please see the
[common options](#duration-notation-format) documentation for information on this format.*
Configures the server write timeout.
#### idle
### idle
{{< confkey type="duration" default="30s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](#duration).
Please see the [documentation](#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](#duration-notation-format). Please see the
[common options](#duration-notation-format) documentation for information on this format.*
Configures the server idle timeout.
## Historical References
This contains links to historical anchors.
##### Duration Notation Format
See [duration common syntax](#duration).

View File

@ -25,21 +25,17 @@ section of the configuration.
## Configuration
{{< config-alert-example >}}
```yaml
duo_api:
disable: false
hostname: 'api-123456789.example.com'
integration_key: 'ABCDEF'
secret_key: '1234567890abcdefghifjkl'
hostname: api-123456789.example.com
integration_key: ABCDEF
secret_key: 1234567890abcdefghifjkl
enable_self_enrollment: false
```
## Options
This section describes the individual configuration options.
### Disable
{{< confkey type="boolean" default="false" required="no" >}}

View File

@ -26,13 +26,11 @@ and many only support SHA1.
## Configuration
{{< config-alert-example >}}
```yaml
totp:
disable: false
issuer: 'authelia.com'
algorithm: 'sha1'
issuer: authelia.com
algorithm: sha1
digits: 6
period: 30
skew: 1
@ -41,8 +39,6 @@ totp:
## Options
This section describes the individual configuration options.
### disable
{{< confkey type="boolean" default="false" required="no" >}}
@ -65,8 +61,9 @@ by Authelia from others.
*__Important Note:__ Many TOTP applications do not support this option. It is strongly advised you find out which
applications your users use and test them before changing this option. It is insufficient to test that the application
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. See the
[Reference Guide](../../reference/integrations/time-based-one-time-password-apps.md) for tested applications.*
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. [Bitwarden]
is the only one that has been tested at this time. If you'd like to contribute to documenting support for this option
please see [Issue 2650](https://github.com/authelia/authelia/issues/2650).*
[Bitwarden]: https://bitwarden.com/
@ -87,8 +84,9 @@ information.
*__Important Note:__ Some TOTP applications do not support this option. It is strongly advised you find out which
applications your users use and test them before changing this option. It is insufficient to test that the application
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. See the
[Reference Guide](../../reference/integrations/time-based-one-time-password-apps.md) for tested applications.*
can add the key, it must also authenticate with Authelia as some applications silently ignore these options. [Bitwarden]
is the only one that has been tested at this time. If you'd like to contribute to documenting support for this option
please see [Issue 2650](https://github.com/authelia/authelia/issues/2650).*
The number of digits a user needs to input to perform authentication. It's generally not recommended for this to be
altered as many TOTP applications do not support anything other than 6. What's worse is some TOTP applications allow

View File

@ -16,21 +16,17 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
webauthn:
disable: false
display_name: 'Authelia'
attestation_conveyance_preference: 'indirect'
user_verification: 'preferred'
timeout: '60s'
display_name: Authelia
attestation_conveyance_preference: indirect
user_verification: preferred
timeout: 60s
```
## Options
This section describes the individual configuration options.
### disable
{{< confkey type="boolean" default="false" required="no" >}}
@ -84,11 +80,11 @@ Available Options:
{{< confkey type="duration" default="60s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
This adjusts the requested timeout for a WebAuthn interaction.
## Frequently Asked Questions
## FAQ
See the [Security Key FAQ](../../overview/authentication/security-key/index.md#frequently-asked-questions) for the FAQ.
See the [Security Key FAQ](../../overview/authentication/security-key/index.md#faq) for the FAQ.

View File

@ -15,20 +15,13 @@ aliases:
- /docs/configuration/access-control.html
---
*__Important Note:__ This section does not apply to OpenID Connect 1.0. See the [Frequently Asked Questions] for more
information.*
[Frequently Asked Questions]: ../../integration/openid-connect/frequently-asked-questions.md#why-doesnt-the-access-control-configuration-work-with-openid-connect-10
## Configuration
{{< config-alert-example >}}
```yaml
access_control:
default_policy: 'deny'
default_policy: deny
networks:
- name: 'internal'
- name: internal
networks:
- '10.0.0.0/8'
- '172.16.0.0/12'
@ -36,7 +29,7 @@ access_control:
rules:
- domain: 'private.example.com'
domain_regex: '^(\d+\-)?priv-img.example.com$'
policy: 'one_factor'
policy: one_factor
networks:
- 'internal'
- '1.1.1.1'
@ -45,8 +38,8 @@ access_control:
- ['user:fred']
- ['group:admins']
methods:
- 'GET'
- 'HEAD'
- GET
- HEAD
resources:
- '^/api.*'
query:
@ -64,8 +57,6 @@ access_control:
## Options
This section describes the individual configuration options.
### default_policy
{{< confkey type="string" default="deny" required="no" >}}
@ -159,10 +150,10 @@ different ways.*
access_control:
rules:
- domain: '*.example.com'
policy: 'bypass'
policy: bypass
- domain:
- '*.example.com'
policy: 'bypass'
policy: bypass
```
*Multiple domains matched. These rules will match either `apple.example.com` or `orange.example.com`. All rules in this
@ -172,11 +163,11 @@ list are effectively the same rule just expressed in different ways.*
access_control:
rules:
- domain: ['apple.example.com', 'banana.example.com']
policy: 'bypass'
policy: bypass
- domain:
- 'apple.example.com'
- 'banana.example.com'
policy: 'bypass'
- apple.example.com
- banana.example.com
policy: bypass
```
*Multiple domains matched either via a static domain or via a [domain_regex]. This rule will match
@ -222,7 +213,7 @@ access_control:
- domain_regex:
- '^user-(?P<User>\w+)\.example\.com$'
- '^group-(?P<Group>\w+)\.example\.com$'
policy: 'one_factor'
policy: one_factor
```
*Multiple domains example, one with a static domain and one with a regex domain. This will match requests to
@ -233,7 +224,7 @@ access_control:
rules:
- domain: 'protected.example.com'
- domain_regex: '^(img|data)-private\.example\.com'
policy: 'one_factor'
policy: one_factor
```
#### policy
@ -272,14 +263,14 @@ ways.*
```yaml
access_control:
rules:
- domain: 'example.com'
policy: 'two_factor'
- domain: example.com
policy: two_factor
subject:
- 'user:john'
- ['group:admin', 'group:app-name']
- 'group:super-admin'
- domain: 'example.com'
policy: 'two_factor'
- domain: example.com
policy: two_factor
subject:
- ['user:john']
- ['group:admin', 'group:app-name']
@ -292,15 +283,15 @@ expressed in different ways.*
```yaml
access_control:
rules:
- domain: 'example.com'
policy: 'one_factor'
- domain: example.com
policy: one_factor
subject: 'group:super-admin'
- domain: 'example.com'
policy: 'one_factor'
- domain: example.com
policy: one_factor
subject:
- 'group:super-admin'
- domain: 'example.com'
policy: 'one_factor'
- domain: example.com
policy: one_factor
subject:
- ['group:super-admin']
```
@ -337,10 +328,10 @@ relevant methods are listed in this table:
```yaml
access_control:
rules:
- domain: 'example.com'
policy: 'bypass'
- domain: example.com
policy: bypass
methods:
- 'OPTIONS'
- OPTIONS
```
#### networks
@ -374,28 +365,28 @@ rules in this list are effectively the same rule just expressed in different way
```yaml
access_control:
default_policy: 'two_factor'
default_policy: two_factor
networks:
- name: 'internal'
- name: internal
networks:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/18'
rules:
- domain: 'secure.example.com'
policy: 'one_factor'
- domain: secure.example.com
policy: one_factor
networks:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/18'
- '112.134.145.167/32'
- domain: 'secure.example.com'
policy: 'one_factor'
- domain: secure.example.com
policy: one_factor
networks:
- 'internal'
- '112.134.145.167/32'
- domain: 'secure.example.com'
policy: 'two_factor'
- domain: secure.example.com
policy: two_factor
```
#### resources
@ -430,8 +421,8 @@ likely save you a lot of time if you do it for all resource rules.
```yaml
access_control:
rules:
- domain: 'app.example.com'
policy: 'bypass'
- domain: app.example.com
policy: bypass
resources:
- '^/api([/?].*)?$'
```
@ -476,8 +467,8 @@ defaults to `present`.
```yaml
access_control:
rules:
- domain: 'app.example.com'
policy: 'bypass'
- domain: app.example.com
policy: bypass
query:
- - operator: 'present'
key: 'secure'
@ -554,13 +545,13 @@ a match for that request.
- domain:
- 'example.com'
- '*.example.com'
policy: 'bypass'
policy: bypass
resources:
- '^/api$'
- '^/api/'
- domain:
- 'app.example.com'
policy: 'two_factor'
policy: two_factor
```
[Rule Matching Concept 1]: #rule-matching-concept-1-sequential-order
@ -612,25 +603,25 @@ Here is a detailed example of an example access control section:
```yaml
access_control:
default_policy: 'deny'
default_policy: deny
networks:
- name: 'internal'
- name: internal
networks:
- '10.10.0.0/16'
- '192.168.2.0/24'
- name: 'VPN'
networks: '10.9.0.0/16'
- name: VPN
networks: 10.9.0.0/16
rules:
- domain: 'public.example.com'
policy: 'bypass'
policy: bypass
- domain: '*.example.com'
policy: 'bypass'
policy: bypass
methods:
- 'OPTIONS'
- OPTIONS
- domain: 'secure.example.com'
policy: 'one_factor'
policy: one_factor
networks:
- 'internal'
- 'VPN'
@ -640,37 +631,37 @@ access_control:
- domain:
- 'secure.example.com'
- 'private.example.com'
policy: 'two_factor'
policy: two_factor
- domain: 'singlefactor.example.com'
policy: 'one_factor'
policy: one_factor
- domain: 'mx2.mail.example.com'
subject: 'group:admins'
policy: 'deny'
policy: deny
- domain: '*.example.com'
subject:
- 'group:admins'
- 'group:moderators'
policy: 'two_factor'
policy: two_factor
- domain: 'dev.example.com'
- domain: dev.example.com
resources:
- '^/groups/dev/.*$'
subject: 'group:dev'
policy: 'two_factor'
policy: two_factor
- domain: 'dev.example.com'
- domain: dev.example.com
resources:
- '^/users/john/.*$'
subject:
- ['group:dev', 'user:john']
- 'group:admins'
policy: 'two_factor'
policy: two_factor
- domain: '{user}.example.com'
policy: 'bypass'
policy: bypass
```
[RFC7231]: https://datatracker.ietf.org/doc/html/rfc7231

View File

@ -18,8 +18,6 @@ aliases:
## Configuration
{{< config-alert-example >}}
```yaml
password_policy:
standard:
@ -37,8 +35,6 @@ password_policy:
## Options
This section describes the individual configuration options.
### standard
This section allows you to enable standard security policies.

View File

@ -20,19 +20,15 @@ authentication attempts. This helps prevent brute-force attacks.
## Configuration
{{< config-alert-example >}}
```yaml
regulation:
max_retries: 3
find_time: '2m'
ban_time: '5m'
find_time: 2m
ban_time: 5m
```
## Options
This section describes the individual configuration options.
### max_retries
{{< confkey type="integer" default="3" required="no" >}}
@ -43,8 +39,8 @@ The number of failed login attempts before a user may be banned. Setting this op
{{< confkey type="duration" default="2m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The period of time analyzed for failed attempts. For
example if you set `max_retries` to 3 and `find_time` to `2m` this means the user must have 3 failed logins in
@ -54,8 +50,8 @@ example if you set `max_retries` to 3 and `find_time` to `2m` this means the use
{{< confkey type="duration" default="5m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The period of time the user is banned for after meeting the `max_retries` and `find_time` configuration. After this
duration the account will be able to login again.

View File

@ -20,24 +20,24 @@ the session cookie behaviour and the domains which Authelia can service authoriz
## Configuration
{{< config-alert-example >}}
```yaml
session:
secret: 'insecure_session_secret'
name: 'authelia_session'
same_site: 'lax'
inactivity: '5m'
expiration: '1h'
remember_me: '1M'
secret: insecure_session_secret
name: authelia_session
same_site: lax
inactivity: 5m
expiration: 1h
remember_me: 1M
cookies:
- domain: 'example.com'
authelia_url: 'https://auth.example.com'
name: 'authelia_session'
same_site: 'lax'
inactivity: '5m'
expiration: '1h'
remember_me: '1d'
- domain: example.com
authelia_url: https://auth.example.com
name: authelia_session
same_site: lax
inactivity: 5m
expiration: 1h
remember_me: 1d
```
## Providers
@ -56,8 +56,6 @@ providers are recommended.
## Options
This section describes the individual configuration options.
### secret
{{< confkey type="string" required="yes" >}}
@ -97,8 +95,8 @@ The default `same_site` value for all `cookies` configurations.
{{< confkey type="duration" default="5m" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The default `inactivity` value for all [cookies](#cookies) configurations.
@ -106,8 +104,8 @@ The default `inactivity` value for all [cookies](#cookies) configurations.
{{< confkey type="duration" default="1h" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The default `expiration` value for all [cookies](#cookies) configurations.
@ -115,8 +113,8 @@ The default `expiration` value for all [cookies](#cookies) configurations.
{{< confkey type="duration" default="1M" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The default `remember_me` value for all [cookies](#cookies) configurations.
@ -195,8 +193,8 @@ state but it's available as an option anyway.
*__Default Value:__ This option takes its default value from the [inactivity](#inactivity) setting above.*
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The period of time the user can be inactive for until the session is destroyed. Useful if you want long session timers
but don't want unused devices to be vulnerable.
@ -207,8 +205,8 @@ but don't want unused devices to be vulnerable.
*__Default Value:__ This option takes its default value from the [expiration](#expiration) setting above.*
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The period of time before the cookie expires and the session is destroyed. This is overriden by
[remember_me](#rememberme) when the remember me box is checked.
@ -219,8 +217,8 @@ The period of time before the cookie expires and the session is destroyed. This
*__Default Value:__ This option takes its default value from the [remember_me](#rememberme) setting above.*
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
*__Note:__ This setting uses the [duration notation format](../prologue/common.md#duration-notation-format). Please see
the [common options](../prologue/common.md#duration-notation-format) documentation for information on this format.*
The period of time before the cookie expires and the session is destroyed when the remember me box is checked. Setting
this to `-1` disables this feature entirely for this session cookie domain.

View File

@ -20,23 +20,21 @@ this option and we highly recommend it in production environments. It requires y
## Configuration
{{< config-alert-example >}}
```yaml
session:
redis:
host: '127.0.0.1'
host: 127.0.0.1
port: 6379
username: 'authelia'
password: 'authelia'
username: authelia
password: authelia
database_index: 0
maximum_active_connections: 8
minimum_idle_connections: 0
tls:
server_name: 'myredis.example.com'
server_name: myredis.example.com
skip_verify: false
minimum_version: 'TLS1.2'
maximum_version: 'TLS1.3'
minimum_version: TLS1.2
maximum_version: TLS1.3
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
@ -105,15 +103,15 @@ session:
DO NOT USE==
-----END RSA PRIVATE KEY-----
high_availability:
sentinel_name: 'mysentinel'
sentinel_name: mysentinel
# If `sentinel_username` is supplied, Authelia will connect using ACL-based
# authentication. Otherwise, it will use traditional `requirepass` auth.
sentinel_username: 'sentinel_user'
sentinel_password: 'sentinel_specific_pass'
sentinel_username: sentinel_user
sentinel_password: sentinel_specific_pass
nodes:
- host: 'sentinel-node1'
- host: sentinel-node1
port: 26379
- host: 'sentinel-node2'
- host: sentinel-node2
port: 26379
route_by_latency: false
route_randomly: false
@ -121,8 +119,6 @@ session:
## Options
This section describes the individual configuration options.
### host
{{< confkey type="string" required="yes" >}}
@ -182,12 +178,8 @@ is useful if there are long delays in establishing connections.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
If defined enables connecting to [redis] over a TLS socket, and additionally controls the TLS connection
validation parameters.
If defined enables [redis] over TLS, and additionally controls the TLS connection validation process. You can see how to
configure the tls section [here](../prologue/common.md#tls-configuration).
### high_availability

View File

@ -21,11 +21,9 @@ The available storage backends are listed in the table of contents below.
## Configuration
{{< config-alert-example >}}
```yaml
storage:
encryption_key: 'a_very_important_secret'
encryption_key: a_very_important_secret
local: {}
mysql: {}
postgres: {}
@ -33,8 +31,6 @@ storage:
## Options
This section describes the individual configuration options.
### encryption_key
{{< confkey type="string" required="yes" >}}

View File

@ -32,9 +32,9 @@ this instance if you wanted to downgrade to pre1 you would need to use an Authel
| 1 | 4.33.0 | Initial migration managed version |
| 2 | 4.34.0 | WebAuthn - added webauthn_devices table, altered totp_config to include device created/used dates |
| 3 | 4.34.2 | WebAuthn - fix V2 migration kid column length and provide migration path for anyone on V2 |
| 4 | 4.35.0 | Added OpenID Connect 1.0 storage tables and opaque user identifier tables |
| 4 | 4.35.0 | Added OpenID Connect storage tables and opaque user identifier tables |
| 5 | 4.35.1 | Fixed the oauth2_consent_session table to accept NULL subjects for users who are not yet signed in |
| 6 | 4.37.0 | Adjusted the OpenID Connect 1.0 tables to allow pre-configured consent improvements |
| 6 | 4.37.0 | Adjusted the OpenID Connect tables to allow pre-configured consent improvements |
| 7 | 4.37.3 | Fixed some schema inconsistencies most notably the MySQL/MariaDB Engine and Collation |
| 8 | 4.38.0 | OpenID Connect 1.0 Pushed Authorization Requests |
| 9 | 4.38.0 | Fix a PostgreSQL NOT NULL constraint issue on the `aaguid` column of the `webauthn_devices` table |

View File

@ -22,22 +22,21 @@ guide for supported version information.
## Configuration
{{< config-alert-example >}}
```yaml
storage:
encryption_key: 'a_very_important_secret'
encryption_key: a_very_important_secret
mysql:
address: 'tcp://127.0.0.1:3306'
database: 'authelia'
username: 'authelia'
password: 'mypassword'
timeout: '5s'
host: 127.0.0.1
port: 3306
database: authelia
username: authelia
password: mypassword
timeout: 5s
tls:
server_name: 'mysql.example.com'
server_name: mysql.example.com
skip_verify: false
minimum_version: 'TLS1.2'
maximum_version: 'TLS1.3'
minimum_version: TLS1.2
maximum_version: TLS1.3
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
@ -109,41 +108,37 @@ storage:
## Options
This section describes the individual configuration options.
### encryption_key
See the [encryption_key docs](introduction.md#encryption_key).
### address
### host
{{< confkey type="address" required="yes" >}}
{{< confkey type="string" default="localhost" required="no" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
The database server host. This can also be a unix socket.
Configures the address for the MySQL/MariaDB Server. The address itself is a connector and the scheme must either be
the `unix` scheme or one of the `tcp` schemes.
__Examples:__
If utilising an IPv6 literal address it must be enclosed by square brackets and quoted:
```yaml
storage:
mysql:
address: 'tcp://127.0.0.1:3306'
host: "[fd00:1111:2222:3333::1]"
```
If utilizing a unix socket it must have the `/` prefix:
```yaml
storage:
mysql:
address: 'tcp://[fd00:1111:2222:3333::1]:3306'
host: /var/run/mysqld.sock
```
```yaml
storage:
mysql:
address: 'unix:///var/run/mysqld.sock'
```
### port
{{< confkey type="integer" default="3306" required="no" >}}
The port the database server is listening on.
### database
@ -175,19 +170,12 @@ characters and the user password is changed to this value.
{{< confkey type="duration" default="5s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The SQL connection timeout.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
If defined enables connecting to [MySQL] or [MariaDB] over a TLS socket, and additionally controls the TLS connection
validation parameters.
validation process. You can see how to configure the tls section [here](../prologue/common.md#tls-configuration).
[MySQL]: https://www.mysql.com/
[MariaDB]: https://mariadb.org/

View File

@ -21,23 +21,21 @@ guide for supported version information.
## Configuration
{{< config-alert-example >}}
```yaml
storage:
encryption_key: 'a_very_important_secret'
encryption_key: a_very_important_secret
postgres:
address: 'tcp://127.0.0.1:5432'
database: 'authelia'
schema: 'public'
username: 'authelia'
password: 'mypassword'
timeout: '5s'
host: 127.0.0.1
port: 5432
database: authelia
schema: public
username: authelia
password: mypassword
tls:
server_name: 'postgres.example.com'
server_name: postgres.example.com
skip_verify: false
minimum_version: 'TLS1.2'
maximum_version: 'TLS1.3'
minimum_version: TLS1.2
maximum_version: TLS1.3
certificate_chain: |
-----BEGIN CERTIFICATE-----
MIIC5jCCAc6gAwIBAgIRAK4Sj7FiN6PXo/urPfO4E7owDQYJKoZIhvcNAQELBQAw
@ -109,41 +107,37 @@ storage:
## Options
This section describes the individual configuration options.
### encryption_key
See the [encryption_key docs](introduction.md#encryptionkey).
See the [encryption_key docs](introduction.md#encryption_key).
### address
### host
{{< confkey type="address" required="yes" >}}
{{< confkey type="string" required="yes" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
The database server host. This can also be a unix socket.
Configures the address for the PostgreSQL Server. The address itself is a connector and the scheme must either be
the `unix` scheme or one of the `tcp` schemes.
__Examples:__
If utilising an IPv6 literal address it must be enclosed by square brackets and quoted:
```yaml
storage:
postgres:
address: 'tcp://127.0.0.1:5432'
host: "[fd00:1111:2222:3333::1]"
```
If utilizing a unix socket it must have the `/` prefix:
```yaml
storage:
postgres:
address: 'tcp://[fd00:1111:2222:3333::1]:5432'
host: /var/run/postgres.sock
```
```yaml
storage:
postgres:
address: 'unix:///var/run/postgres.sock'
```
### port
{{< confkey type="integer" default="5432" required="no" >}}
The port the database server is listening on.
### database
@ -182,18 +176,11 @@ characters and the user password is changed to this value.
{{< confkey type="duration" default="5s" required="no" >}}
*__Reference Note:__ This configuration option uses the [duration common syntax](../prologue/common.md#duration).
Please see the [documentation](../prologue/common.md#duration) on this format for more information.*
The SQL connection timeout.
### tls
*__Reference Note:__ This configuration option uses the
[TLS configuration common structure](../prologue/common.md#tls-configuration). Please see the
[documentation](../prologue/common.md#tls-configuration) on this structure for more information.*
If defined enables connecting to [PostgreSQL] over a TLS socket, and additionally controls the TLS connection
validation parameters.
validation process. You can see how to configure the tls section [here](../prologue/common.md#tls-configuration).
[PostgreSQL]: https://www.postgresql.org/

View File

@ -24,19 +24,15 @@ but this requires you setup an external database such as [PostgreSQL](postgres.m
## Configuration
{{< config-alert-example >}}
```yaml
storage:
encryption_key: 'a_very_important_secret'
encryption_key: a_very_important_secret
local:
path: '/config/db.sqlite3'
path: /config/db.sqlite3
```
## Options
This section describes the individual configuration options.
### encryption_key
See the [encryption_key docs](introduction.md#encryptionkey).

View File

@ -16,26 +16,22 @@ toc: true
## Configuration
{{< config-alert-example >}}
```yaml
telemetry:
metrics:
enabled: false
address: 'tcp://:9959/'
address: "tcp://0.0.0.0:9959"
buffers:
read: 4096
write: 4096
timeouts:
read: '6s'
write: '6s'
idle: '30s'
read: 6s
write: 6s
idle: 30s
```
## Options
This section describes the individual configuration options.
### enabled
{{< confkey type="boolean" default="false" required="no" >}}
@ -44,29 +40,20 @@ Determines if the [Prometheus] HTTP Metrics Exporter is enabled.
### address
{{< confkey type="address" default="tcp://:9959/" required="no" >}}
{{< confkey type="address" default="tcp://0.0.0.0:9959" required="no" >}}
*__Reference Note:__ This configuration option uses the [address common syntax](../prologue/common.md#address). Please
see the [documentation](../prologue/common.md#address) on this format for more information.*
Configures the listener address for the [Prometheus] Metrics Exporter HTTP Server. The address itself is a listener and
the scheme must either be the `unix` scheme or one of the `tcp` schemes.
Configures the listener address for the [Prometheus] HTTP Metrics Exporter. This configuration key uses the
[Address](../prologue/common.md#address) format. The scheme must be `tcp://` or empty.
### buffers
*__Reference Note:__ This configuration option uses the
[Server buffers common structure](../prologue/common.md#server-buffers). Please see the
[documentation](../prologue/common.md#server-buffers) on this structure for more information.*
Configures the server buffers.
Configures the server buffers. See the [Server Buffers](../prologue/common.md#server-buffers) documentation for more
information.
### timeouts
*__Reference Note:__ This configuration option uses the
[Server timeouts common structure](../prologue/common.md#server-timeouts). Please see the
[documentation](../prologue/common.md#server-timeouts) on this structure for more information.*
Configures the server timeouts.
Configures the server timeouts. See the [Server Timeouts](../prologue/common.md#server-timeouts) documentation for more
information.
## See More

View File

@ -62,7 +62,7 @@ There is a scripting context provided with __Authelia__ which can easily be conf
[suites] and various other tasks. Read more about it in the [authelia-scripts](reference-authelia-scripts.md) reference
guide.
## Frequently Asked Questions
## FAQ
### Do you support development under Windows or OSX?

View File

@ -182,8 +182,8 @@ By making a contribution to this project, I certify that:
This can be achieved in the following ways:
- While making the commit use `git commit --signoff` or `git commit -s`
- To correct a single commit missing the sign off `git commit -amend --no-edit --signoff` or `git commit --amend --no-edit -s`
- While making the commit use `git commit --signoff`
- To correct a single commit missing the sign off `git commit -amend --signoff --no-edit`
- To correct multiple commits missing the sign off `git rebase --signoff HEAD~2` (i.e. with 2 commits that are missing the sign off)
This can be achieved by using `git commit --signoff`. A single previous commit can be signed using

View File

@ -42,16 +42,6 @@ on most Debian based operating systems.
In addition to the `.deb` packages we also have an [APT Repository](https://apt.authelia.com).
## Nix
Using the Nix package manager Authelia is available via the `https://nixos.org/channels/nixpkgs-unstable` channel.
```shell
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
$ nix-channel --update
$ nix-env -iA nixpkgs.authelia
```
## FreeBSD
In addition to the [binaries](#binaries) we publish, [FreshPorts](https://www.freshports.org/www/authelia/) offer a

View File

@ -18,44 +18,6 @@ The [Docker] container is deployed with the following image names:
* [docker.io/authelia/authelia](https://hub.docker.com/r/authelia/authelia)
* [ghcr.io/authelia/authelia](https://github.com/authelia/authelia/pkgs/container/authelia)
## Get Started
It's __*strongly recommended*__ that users setting up *Authelia* for the first time take a look at our
[Get Started](../prologue/get-started.md) guide. This takes you through various steps which are essential to
bootstrapping *Authelia*.
## Container
### Environment Variables
Several environment variables apply specifically to the official container. This table documents them. It is important
to note these environment variables are specific to the container and have no effect on the *Authelia* daemon itself and
this section is not meant to document the daemon environment variables.
| Name | Default | Usage |
|:-----:|:-------:|:---------------------------------------------------------------------------------------------:|
| PUID | 0 | If the container is running as UID 0, it will drop privileges to this UID via the entrypoint |
| PGID | 0 | If the container is running as UID 0, it will drop privileges to this GID via the entrypoint |
| UMASK | N/A | If set the container will run with the provided UMASK by running the `umask ${UMASK}` command |
### Permission Context
By default the container runs as the configured [Docker] daemon user. Users can control this behaviour in several ways.
The first and recommended way is instructing the [Docker] daemon to run the *Authelia* container as another user. See
the [docker run] or [Docker Compose file reference documentation](https://docs.docker.com/compose/compose-file/05-services/#user)
for more information. The best part of this method is the process will never have privileged access, and the only
negative is the user must manually configure the filesystem permissions correctly.
The second method is by using the environment variables listed above. The downside to this method is that the entrypoint
itself will run as UID 0 (root). The advantage is the container will automatically set owner and permissions on the
filesystem correctly.
The last method which is beyond our documentation or support is using the
[user namespace](https://docs.docker.com/engine/security/userns-remap/) facility [Docker] provides.
[docker run]: https://docs.docker.com/engine/reference/commandline/run/
## Docker Compose
We provide two main [Docker Compose] examples which can be utilized to help test *Authelia* or can be adapted into your
@ -65,6 +27,12 @@ existing [Docker Compose].
* [Bundle: lite](#lite)
* [Bundle: local](#local)
### Get Started
It's __*strongly recommended*__ that users setting up *Authelia* for the first time take a look at our
[Get Started](../prologue/get-started.md) guide. This takes you through various steps which are essential to
bootstrapping *Authelia*.
### Standalone Example
The following examples are [Docker Compose] deployments with just *Authelia* and no bundled applications or
@ -92,35 +60,35 @@ Use this [Standalone Example](#standalone-example) if you want to use
version: "3.8"
secrets:
JWT_SECRET:
file: '${PWD}/data/authelia/secrets/JWT_SECRET'
file: ${PWD}/data/authelia/secrets/JWT_SECRET
SESSION_SECRET:
file: '${PWD}/data/authelia/secrets/SESSION_SECRET'
file: ${PWD}/data/authelia/secrets/SESSION_SECRET
STORAGE_PASSWORD:
file: '${PWD}/data/authelia/secrets/STORAGE_PASSWORD'
file: ${PWD}/data/authelia/secrets/STORAGE_PASSWORD
STORAGE_ENCRYPTION_KEY:
file: '${PWD}/data/authelia/secrets/STORAGE_ENCRYPTION_KEY'
file: ${PWD}/data/authelia/secrets/STORAGE_ENCRYPTION_KEY
services:
authelia:
container_name: 'authelia'
image: 'docker.io/authelia/authelia:latest'
restart: 'unless-stopped'
container_name: authelia
image: docker.io/authelia/authelia:latest
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 9091
secrets: ['JWT_SECRET', 'SESSION_SECRET', 'STORAGE_PASSWORD', 'STORAGE_ENCRYPTION_KEY']
secrets: [JWT_SECRET, SESSION_SECRET, STORAGE_PASSWORD, STORAGE_ENCRYPTION_KEY]
environment:
AUTHELIA_JWT_SECRET_FILE: '/run/secrets/JWT_SECRET'
AUTHELIA_SESSION_SECRET_FILE: '/run/secrets/SESSION_SECRET'
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: '/run/secrets/STORAGE_PASSWORD'
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: '/run/secrets/STORAGE_ENCRYPTION_KEY'
AUTHELIA_JWT_SECRET_FILE: /run/secrets/JWT_SECRET
AUTHELIA_SESSION_SECRET_FILE: /run/secrets/SESSION_SECRET
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: /run/secrets/STORAGE_PASSWORD
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: /run/secrets/STORAGE_ENCRYPTION_KEY
volumes:
- '${PWD}/data/authelia/config:/config'
- ${PWD}/data/authelia/config:/config
networks:
net:
external: true
name: 'net'
name: net
...
```
{{< /details >}}
@ -136,26 +104,26 @@ Use this [Standalone Example](#standalone-example) if you want to use a standard
version: "3.8"
services:
authelia:
container_name: 'authelia'
image: 'docker.io/authelia/authelia:latest'
restart: 'unless-stopped'
container_name: authelia
image: docker.io/authelia/authelia:latest
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 9091
environment:
AUTHELIA_JWT_SECRET_FILE: '/secrets/JWT_SECRET'
AUTHELIA_SESSION_SECRET_FILE: '/secrets/SESSION_SECRET'
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: '/secrets/STORAGE_PASSWORD'
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: '/secrets/STORAGE_ENCRYPTION_KEY'
AUTHELIA_JWT_SECRET_FILE: /secrets/JWT_SECRET
AUTHELIA_SESSION_SECRET_FILE: /secrets/SESSION_SECRET
AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE: /secrets/STORAGE_PASSWORD
AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE: /secrets/STORAGE_ENCRYPTION_KEY
volumes:
- '${PWD}/data/authelia/config:/config'
- '${PWD}/data/authelia/secrets:/secrets'
- ${PWD}/data/authelia/config:/config
- ${PWD}/data/authelia/secrets:/secrets
networks:
net:
external: true
name: 'net'
name: net
```
...
{{< /details >}}
@ -210,7 +178,7 @@ running the following command:
grep -Eo '"https://.*" ' ./authelia/notification.txt.
```
## Frequently Asked Questions
## FAQ
#### Running the Proxy on the Host Instead of in a Container

View File

@ -63,7 +63,7 @@ spec:
...
```
## Frequently Asked Questions
## FAQ
### RAM usage

View File

@ -30,8 +30,8 @@ This is an example IstioOperator manifest adjusted to authenticate with Authelia
portions of the resource that you add as well as context. You will need to adapt it to your needs.
```yaml
apiVersion: 'install.istio.io/v1alpha1'
kind: 'IstioOperator'
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
meshConfig:
extensionProviders:
@ -63,13 +63,13 @@ spec:
The following [Authorization Policy] applies the above filter extension provider to the `nextcloud.example.com` domain:
```yaml
apiVersion: 'security.istio.io/v1beta1'
kind: 'AuthorizationPolicy'
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: 'nextcloud'
namespace: 'apps'
name: nextcloud
namespace: apps
spec:
action: 'CUSTOM'
action: CUSTOM
provider:
name: 'authelia'
rules:

View File

@ -51,14 +51,14 @@ __SHOULD NOT__ be applied to the Authelia [Ingress] / [IngressRoute] itself.*
{{< details "middleware.yml" >}}
```yaml
---
apiVersion: 'traefik.containo.us/v1alpha1'
kind: 'Middleware'
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: 'forwardauth-authelia'
namespace: 'default'
name: forwardauth-authelia
namespace: default
labels:
app.kubernetes.io/instance: 'authelia'
app.kubernetes.io/name: 'authelia'
app.kubernetes.io/instance: authelia
app.kubernetes.io/name: authelia
spec:
forwardAuth:
address: 'http://authelia.default.svc.cluster.local/api/authz/forward-auth'
@ -85,25 +85,25 @@ the `default` [Namespace] with TCP port `80` configured to route to the applicat
{{< details "ingress.yml" >}}
```yaml
---
apiVersion: 'networking.k8s.io/v1'
kind: 'Ingress'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 'app'
namespace: 'default'
name: app
namespace: default
annotations:
traefik.ingress.kubernetes.io/router.entryPoints: 'websecure'
traefik.ingress.kubernetes.io/router.middlewares: 'default-forwardauth-authelia@kubernetescrd'
traefik.ingress.kubernetes.io/router.tls: 'true'
traefik.ingress.kubernetes.io/router.entryPoints: websecure
traefik.ingress.kubernetes.io/router.middlewares: default-forwardauth-authelia@kubernetescrd
traefik.ingress.kubernetes.io/router.tls: "true"
spec:
rules:
- host: 'app.example.com'
- host: app.example.com
http:
paths:
- path: '/bar'
pathType: 'Prefix'
- path: /bar
pathType: Prefix
backend:
service:
name: 'app'
name: app
port:
number: 80
...
@ -119,27 +119,27 @@ the `default` [Namespace] with TCP port `80` configured to route to the applicat
{{< details "ingressRoute.yml" >}}
```yaml
---
apiVersion: 'traefik.containo.us/v1alpha1'
kind: 'IngressRoute'
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: 'app'
namespace: 'default'
name: app
namespace: default
spec:
entryPoints:
- 'websecure'
- websecure
routes:
- kind: 'Rule'
match: 'Host(`app.example.com`)'
- kind: Rule
match: Host(`app.example.com`)
middlewares:
- name: 'forwardauth-authelia'
namespace: 'default'
- name: forwardauth-authelia
namespace: default
services:
- kind: 'Service'
name: 'app'
namespace: 'default'
- kind: Service
name: app
namespace: default
port: 80
scheme: 'http'
strategy: 'RoundRobin'
scheme: http
strategy: RoundRobin
weight: 10
...
```

View File

@ -44,8 +44,8 @@ In your Authelia configuration you will need to enter and update the following v
```yaml
ldap:
address: 'ldap://OpenLDAP:1389'
implementation: custom
url: ldap://OpenLDAP:1389
timeout: 5s
start_tls: false
tls:
@ -55,16 +55,14 @@ In your Authelia configuration you will need to enter and update the following v
base_dn: DC=example,DC=com
additional_users_dn: OU=users
users_filter: (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
username_attribute: uid
mail_attribute: mail
display_name_attribute: displayName
additional_groups_dn: OU=groups
groups_filter: (&(member=UID={input},OU=users,DC=example,DC=com)(objectClass=groupOfNames))
group_name_attribute: cn
user: UID=authelia,OU=service accounts,DC=example,DC=com
password: "SUPER_COMPLEX_PASSWORD"
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
Following this, restart Authelia, and you should be able to begin using LDAP integration for your user logins, with
Authelia taking the email attribute for users straight from the 'mail' attribute within the LDAP object.
@ -93,8 +91,8 @@ In your Authelia configuration you will need to enter and update the following v
```yaml
ldap:
address: 'ldaps://ldap.example.com'
implementation: custom
url: ldaps://ldap.example.com
timeout: 5s
start_tls: false
tls:
@ -102,18 +100,16 @@ In your Authelia configuration you will need to enter and update the following v
skip_verify: true
minimum_version: TLS1.2
base_dn: dc=example,DC=com
username_attribute: uid
additional_users_dn: CN=users,CN=accounts
users_filter: (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
additional_groups_dn: OU=groups
groups_filter: (&(member=UID={input},CN=users,CN=accounts,DC=example,DC=com)(objectClass=groupOfNames))
group_name_attribute: cn
mail_attribute: mail
display_name_attribute: displayName
user: UID=authelia,CN=users,CN=accounts,DC=example,DC=com
password: "SUPER_COMPLEX_PASSWORD"
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
Following this, restart Authelia, and you should be able to begin using LDAP integration for your user logins, with
Authelia taking the email attribute for users straight from the 'mail' attribute within the LDAP object.
@ -138,26 +134,24 @@ In your Authelia configuration you will need to enter and update the following v
```yaml
ldap:
address: 'ldap://lldap:3890'
implementation: custom
url: ldap://lldap:3890
timeout: 5s
start_tls: false
base_dn: dc=example,DC=com
username_attribute: uid
additional_users_dn: OU=people
# To allow sign in both with username and email, one can use a filter like
# (&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))
users_filter: (&({username_attribute}={input})(objectClass=person))
additional_groups_dn: OU=groups
groups_filter: (member={dn})
group_name_attribute: cn
mail_attribute: mail
display_name_attribute: displayName
# The username and password of the admin or service user.
user: UID=authelia,OU=people,DC=example,DC=com
password: "SUPER_COMPLEX_PASSWORD"
attributes:
distinguished_name: 'distinguishedName'
username: 'uid'
mail: 'mail'
member_of: 'memberOf'
group_name: 'cn'
```
Following this, restart Authelia, and you should be able to begin using lldap integration for your user logins, with
Authelia taking the email attribute for users straight from the 'mail' attribute within the LDAP object.

View File

@ -1,6 +1,6 @@
---
title: "OpenID Connect 1.0"
description: "OpenID Connect 1.0 Integration"
title: "OpenID Connect"
description: "OpenID Connect Integration"
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false

View File

@ -1,6 +1,6 @@
---
title: "Apache Guacamole"
description: "Integrating Apache Guacamole with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Apache Guacamole with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-07-31T13:09:05+10:00
draft: false
@ -53,7 +53,7 @@ openid-groups-claim-type: groups
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with
[Apache Guacamole] which will operate with the above example:
```yaml
@ -62,23 +62,23 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'guacamole'
description: 'Apache Guacamole'
- id: guacamole
description: Apache Guacamole
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://guacamole.example.com'
- https://guacamole.example.com
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
- openid
- profile
- groups
- email
response_types:
- 'id_token'
- id_token
grant_types:
- 'implicit'
userinfo_signing_alg: 'none'
- implicit
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Argo CD"
description: "Integrating Argo CD with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Argo CD with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-07-13T04:27:30+10:00
draft: false
@ -56,7 +56,7 @@ requestedScopes:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Argo CD]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Argo CD]
which will operate with the above example:
```yaml
@ -65,32 +65,32 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'argocd'
description: 'Argo CD'
- id: argocd
description: Argo CD
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://argocd.example.com/auth/callback'
- https://argocd.example.com/auth/callback
scopes:
- 'openid'
- 'groups'
- 'email'
- 'profile'
userinfo_signing_alg: 'none'
- id: 'argocd-cli'
description: 'Argo CD (CLI)'
- openid
- groups
- email
- profile
userinfo_signing_algorithm: none
- id: argocd-cli
description: Argo CD (CLI)
public: true
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'http://localhost:8085/auth/callback'
- http://localhost:8085/auth/callback
scopes:
- 'openid'
- 'groups'
- 'email'
- 'profile'
- 'offline_access'
userinfo_signing_alg: 'none'
- openid
- groups
- email
- profile
- offline_access
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "BookStack"
description: "Integrating BookStack with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating BookStack with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -58,7 +58,7 @@ To configure [BookStack] to utilize Authelia as an [OpenID Connect 1.0] Provider
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [BookStack]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [BookStack]
which will operate with the above example:
```yaml
@ -67,18 +67,18 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'bookstack'
description: 'BookStack'
- id: bookstack
description: BookStack
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://bookstack.example.com/oidc/callback'
- https://bookstack.example.com/oidc/callback
scopes:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Cloudflare Zero Trust"
description: "Integrating Cloudflare Zero Trust with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Cloudflare Zero Trust with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -66,7 +66,7 @@ To configure [Cloudflare Zero Trust] to utilize Authelia as an [OpenID Connect 1
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Cloudflare]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Cloudflare]
which will operate with the above example:
```yaml
@ -75,18 +75,18 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'cloudflare'
description: 'Cloudflare ZeroTrust'
- id: cloudflare
description: Cloudflare ZeroTrust
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://example-team.cloudflareaccess.com/cdn-cgi/access/callback'
- https://example-team.cloudflareaccess.com/cdn-cgi/access/callback
scopes:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Firezone"
description: "Integrating Firezone with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Firezone with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-28T20:29:13+11:00
draft: false
@ -67,7 +67,7 @@ descriptions.
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Firezone] which
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Firezone] which
will operate with the above example:
```yaml
@ -76,20 +76,20 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'firezone'
description: 'Firezone'
- id: firezone
description: Firezone
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
enforce_pkce: true
pkce_challenge_method: 'S256'
pkce_challenge_method: S256
redirect_uris:
- 'https://firezone.example.com/auth/oidc/authelia/callback'
- https://firezone.example.com/auth/oidc/authelia/callback
scopes:
- 'openid'
- 'email'
- 'profile'
userinfo_signing_alg: 'none'
- openid
- email
- profile
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,7 +1,7 @@
---
title: "Frequently Asked Questions"
description: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party"
lead: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party."
description: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party"
lead: "Frequently Asked Questions regarding integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party."
date: 2022-10-20T15:27:09+11:00
draft: false
images: []
@ -12,11 +12,7 @@ weight: 615
toc: true
---
### Questions
The following section lists individual questions.
### How do I generate client secrets?
## How do I generate client secrets?
We strongly recommend the following guidelines for generating client secrets:
@ -39,7 +35,7 @@ party / client application encoding the characters correctly as it uses the
[Generating a Random Password Hash]: ../../reference/guides/generating-secure-values.md#generating-a-random-password-hash
#### Plaintext
### Plaintext
Authelia *technically* supports storing the plaintext secret in the configuration. This will likely be completely
unavailable in the future as it was a mistake to implement it like this in the first place. While some other OpenID
@ -62,7 +58,7 @@ Plaintext is either denoted by the `$plaintext$` prefix where everything after t
the secret does not start with the `$` character it's considered as a plaintext secret for the time being but is
deprecated as is the `$plaintext$` prefix.
### Why isn't my application able to retrieve the token even though I've consented?
## Why isn't my application able to retrieve the token even though I've consented?
The most common cause for this issue is when the affected application can not make requests to the Token [Endpoint].
This becomes obvious when the log level is set to `debug` or `trace` and a presence of requests to the Authorization
@ -75,97 +71,4 @@ to the Token [Endpoint].
All causes should be clearly logged by the client application, and all errors that do not match this scenario are
clearly logged by Authelia. It's not possible for us to log requests that never occur however.
One potential solution to this is detailed in the [Solution: Configure DNS Appropriately](#configure-dns-appropriately)
section. This section also details how to identity if you're affected.
### Why doesn't the discovery endpoint return the correct issuer and endpoint URL's?
The most common cause for this is if the `X-Forwarded-Proto` and `X-Forwarded-Host` / `Host` headers do not match the
fully qualified URL of the provider. This can be because of requesting from the Authelia port directly i.e. without going
through your proxy or due to a poorly configured proxy.
If you've configured Authelia alongside a proxy and are making a request directly to Authelia you need to perform the
request via the proxy. If you're avoiding the proxy due to a DNS limitation see
[Solution: Configure DNS Appropriately](#configure-dns-appropriately) section.
### Why doesn't the access control configuration work with OpenID Connect 1.0?
The [access control](../../configuration/security/access-control.md) configuration contains several elements which are
not very compatible with OpenID Connect 1.0. They were designed with per-request authorizations in mind. In particular
the [resources](../../configuration/security/access-control.md#resources),
[query](../../configuration/security/access-control.md#query),
[methods](../../configuration/security/access-control.md#methods), and
[networks](../../configuration/security/access-control.md#networks) criteria are very specific to each request and to
some degree so are the [domain](../../configuration/security/access-control.md#domain) and
[domain regex](../../configuration/security/access-control.md#domainregex) criteria as the token is issued to the client
not a specific domain.
For these reasons we implemented the
[authorization policy](../../configuration/identity-providers/openid-connect/clients.md#authorizationpolicy) as a direct
option in the client. It's likely in the future that we'll expand this option to encompass the features that work well
with OpenID Connect 1.0 such as the [subject](../../configuration/security/access-control.md#subject) criteria which
reasonably be matched to an individual authorization policy. Because the other criteria are mostly geared towards
per-request authorization these criteria types are fairly unlikely to become part of OpenID Connect 1.0 as there are no
ways to apply these criteria except during the initial authorization request.
## Solutions
The following section details solutions for multiple of the questions above.
### Configure DNS Appropriately
In order to make requests to Authelia an application must be able to resolve it. It's important in all instances to
check if the application with the issue can resolve the correct IP address for Authelia between each step of the
process, and this check also can be used to clearly identity if this is the most likely underlying cause for an issue
you're facing.
##### Bare-Metal
1. If you're running an internal DNS server ensure an A record exists for the FQDN of Authelia with the value being the
IP of the server responsible for handling requests for Authelia.
2. If you're not running an internal DNS server then do check the following:
1. Ensure the external DNS server(s) have the same A record as described above.
2. Ensure that that your NAT-hairpin is configured correctly.
3. If all else fails add a hosts file entry to work around this issue.
##### Docker
1. Ensure both the application with the issue shares a network in common with the proxy container.
2. Ensure an alias for the FQDN of Authelia is present for the proxy container:
- If using `docker compose` see the
[network aliases](https://docs.docker.com/compose/compose-file/compose-file-v3/#aliases) documentation
reference for more information.
- If using `docker run` see the `--network-alias` option of the [docker run](https://docs.docker.com/engine/reference/commandline/run/)
reference for more information.
Examples (assuming your Authelia Root URL is `https://auth.example.com`):
```yaml
version: "3.8"
services:
application:
## Mandatory that the application is on the same network as the proxy.
networks:
proxy: {}
proxy:
networks:
## Mandatory that the proxy is on the same network as the application, and that it has this alias.
proxy:
aliases:
- 'auth.example.com'
authelia:
networks:
proxy: {}
networks:
proxy:
## An external network can be created manually and shared between multiple compose files. This is NOT mandatory.
external: true
name: 'proxy-net'
```
```console
docker run -d --name proxy --network proxy --network-alias auth.example.com <other proxy arguments>
docker run -d --name application --network proxy <other application arguments>
```
[Endpoint]: ./introduction.md#discoverable-endpoints

View File

@ -1,6 +1,6 @@
---
title: "Gitea"
description: "Integrating Gitea with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Gitea with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-07-01T13:07:02+10:00
draft: false
@ -77,7 +77,7 @@ descriptions.
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Gitea] which
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Gitea] which
will operate with the above example:
```yaml
@ -86,18 +86,18 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'gitea'
description: 'Gitea'
- id: gitea
description: Gitea
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://gitea.example.com/user/oauth2/authelia/callback'
- https://gitea.example.com/user/oauth2/authelia/callback
scopes:
- 'openid'
- 'email'
- 'profile'
userinfo_signing_alg: 'none'
- openid
- email
- profile
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "GitLab"
description: "Integrating GitLab with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating GitLab with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -69,7 +69,7 @@ gitlab_rails['omniauth_providers'] = [
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [GitLab]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [GitLab]
which will operate with the above example:
```yaml
@ -78,19 +78,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'gitlab'
description: 'GitLab'
- id: gitlab
description: GitLab
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://gitlab.example.com/users/auth/openid_connect/callback'
- https://gitlab.example.com/users/auth/openid_connect/callback
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Grafana"
description: "Integrating Grafana with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Grafana with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -87,7 +87,7 @@ Configure the following environment variables:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Grafana]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Grafana]
which will operate with the above example:
```yaml
@ -96,19 +96,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'grafana'
description: 'Grafana'
- id: grafana
description: Grafana
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://grafana.example.com/login/generic_oauth'
- https://grafana.example.com/login/generic_oauth
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Harbor"
description: "Integrating Harbor with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Harbor with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -60,7 +60,7 @@ To configure [Harbor] to utilize Authelia as an [OpenID Connect 1.0] Provider:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Harbor]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Harbor]
which will operate with the above example:
```yaml
@ -69,19 +69,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'harbor'
description: 'Harbor'
- id: harbor
description: Harbor
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://harbor.example.com/c/oidc/callback'
- https://harbor.example.com/c/oidc/callback
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "HashiCorp Vault"
description: "Integrating HashiCorp Vault with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating HashiCorp Vault with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -43,7 +43,7 @@ To configure [HashiCorp Vault] to utilize Authelia as an [OpenID Connect 1.0] Pr
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [HashiCorp Vault]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [HashiCorp Vault]
which will operate with the above example:
```yaml
@ -52,20 +52,20 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'vault'
description: 'HashiCorp Vault'
- id: vault
description: HashiCorp Vault
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://vault.example.com/oidc/callback'
- 'https://vault.example.com/ui/vault/auth/oidc/oidc/callback'
- https://vault.example.com/oidc/callback
- https://vault.example.com/ui/vault/auth/oidc/oidc/callback
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,7 +1,7 @@
---
title: "OpenID Connect"
description: "An introduction into integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party"
lead: "An introduction into integrating the Authelia OpenID Connect 1.0 Provider with an OpenID Connect 1.0 Relying Party."
description: "An introduction into integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party"
lead: "An introduction into integrating the Authelia OpenID Connect Provider with an OpenID Connect relying party."
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
@ -18,10 +18,8 @@ Authelia can act as an [OpenID Connect 1.0] Provider as part of an open beta. Th
specifics that can be used for integrating Authelia with an [OpenID Connect 1.0] Relying Party, as well as specific
documentation for some [OpenID Connect 1.0] Relying Party implementations.
See the [OpenID Connect 1.0 Provider](../../configuration/identity-providers/openid-connect/provider.md) and
[OpenID Connect 1.0 Clients](../../configuration/identity-providers/openid-connect/clients.md) configuration guides for
information on how to configure the Authelia [OpenID Connect 1.0] Provider (note the clients guide is for configuring
the registered clients in the provider).
See the [configuration documentation](../../configuration/identity-providers/open-id-connect.md) for information on how
to configure the Authelia [OpenID Connect 1.0] Provider.
This page is intended as an integration reference point for any implementers who wish to integrate an
[OpenID Connect 1.0] Relying Party (client application) either as a developer or user of the third party Reyling Party.
@ -103,49 +101,6 @@ This scope includes the profile information the authentication backend reports a
| preferred_username | string | username | The username the user used to login with |
| name | string | display_name | The users display name |
## Signing and Encryption Algorithms
[OpenID Connect 1.0] and OAuth 2.0 support a wide variety of signature and encryption algorithms. Authelia supports
a subset of these.
### Response Object
Authelia's response objects can have the following signature algorithms:
| Algorithm | Key Type | Hashing Algorithm | Use | JWK Default Conditions | Notes |
|:---------:|:-----------:|:-----------------:|:---------:|:--------------------------------------------:|:----------------------------------------------------:|
| RS256 | RSA | SHA-256 | Signature | RSA Private Key without a specific algorithm | Requires an RSA Private Key with 2048 bits or more |
| RS384 | RSA | SHA-384 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| RS512 | RSA | SHA-512 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| ES256 | ECDSA P-256 | SHA-256 | Signature | ECDSA Private Key with the P-256 curve | |
| ES384 | ECDSA P-384 | SHA-384 | Signature | ECDSA Private Key with the P-384 curve | |
| ES512 | ECDSA P-521 | SHA-512 | Signature | ECDSA Private Key with the P-521 curve | Requires an ECDSA Private Key with 2048 bits or more |
| PS256 | RSA (MGF1) | SHA-256 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| PS384 | RSA (MGF1) | SHA-384 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
| PS512 | RSA (MGF1) | SHA-512 | Signature | N/A | Requires an RSA Private Key with 2048 bits or more |
### Request Object
Authelia accepts a wide variety of request object types.
| Algorithm | Key Type | Hashing Algorithm | Use | Notes |
|:---------:|:------------------:|:-----------------:|:---------:|:--------------------------------------------------:|
| none | None | None | N/A | N/A |
| HS256 | HMAC Shared Secret | SHA-256 | Signature | [Client Authentication Method] `client_secret_jwt` |
| HS384 | HMAC Shared Secret | SHA-384 | Signature | [Client Authentication Method] `client_secret_jwt` |
| HS512 | HMAC Shared Secret | SHA-512 | Signature | [Client Authentication Method] `client_secret_jwt` |
| RS256 | RSA | SHA-256 | Signature | [Client Authentication Method] `private_key_jwt` |
| RS384 | RSA | SHA-384 | Signature | [Client Authentication Method] `private_key_jwt` |
| RS512 | RSA | SHA-512 | Signature | [Client Authentication Method] `private_key_jwt` |
| ES256 | ECDSA P-256 | SHA-256 | Signature | [Client Authentication Method] `private_key_jwt` |
| ES384 | ECDSA P-384 | SHA-384 | Signature | [Client Authentication Method] `private_key_jwt` |
| ES512 | ECDSA P-521 | SHA-512 | Signature | [Client Authentication Method] `private_key_jwt` |
| PS256 | RSA (MFG1) | SHA-256 | Signature | [Client Authentication Method] `private_key_jwt` |
| PS384 | RSA (MFG1) | SHA-384 | Signature | [Client Authentication Method] `private_key_jwt` |
| PS512 | RSA (MFG1) | SHA-512 | Signature | [Client Authentication Method] `private_key_jwt` |
[Client Authentication Method]: #client-authentication-method
## Parameters
The following section describes advanced parameters which can be used in various endpoints as well as their related
@ -219,8 +174,8 @@ specification and the [OAuth 2.0 - Client Types] specification for more informat
|:------------------------------------:|:-----------------------------:|:----------------------:|:-----------------------:|:--------------------------------------------------------:|
| Secret via HTTP Basic Auth Scheme | `client_secret_basic` | `confidential` | N/A | N/A |
| Secret via HTTP POST Body | `client_secret_post` | `confidential` | N/A | N/A |
| JWT (signed by secret) | `client_secret_jwt` | `confidential` | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| JWT (signed by private key) | `private_key_jwt` | `confidential` | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| JWT (signed by secret) | `client_secret_jwt` | Not Supported | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| JWT (signed by private key) | `private_key_jwt` | Not Supported | N/A | `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
| [OAuth 2.0 Mutual-TLS] | `tls_client_auth` | Not Supported | N/A | N/A |
| [OAuth 2.0 Mutual-TLS] (Self Signed) | `self_signed_tls_client_auth` | Not Supported | N/A | N/A |
| No Authentication | `none` | `public` | `public` | N/A |
@ -255,7 +210,7 @@ Below is a list of the potential values we place in the [Claim] and their meanin
## User Information Signing Algorithm
The following table describes the response from the [UserInfo] endpoint depending on the
[userinfo_signing_alg](../../configuration/identity-providers/openid-connect/clients.md#userinfosigningalg).
[userinfo_signing_algorithm](../../configuration/identity-providers/open-id-connect.md#userinfosigningalgorithm).
| Signing Algorithm | Encoding | Content Type |
|:-----------------:|:------------:|:-----------------------------------:|
@ -265,7 +220,7 @@ The following table describes the response from the [UserInfo] endpoint dependin
## Endpoint Implementations
The following section documents the endpoints we implement and their respective paths. This information can
traditionally be discovered by relying parties that utilize [OpenID Connect Discovery 1.0], however this information may be
traditionally be discovered by relying parties that utilize [OpenID Connect Discovery], however this information may be
useful for clients which do not implement this.
The endpoints can be discovered easily by visiting the Discovery and Metadata endpoints. It is recommended regardless
@ -275,7 +230,7 @@ below.
These tables document the endpoints we currently support and their paths in the most recent version of Authelia. The
paths are appended to the end of the primary URL used to access Authelia. The tables use the url
https://auth.example.com as an example of the Authelia root URL which is also the OpenID Connect 1.0 Issuer.
https://auth.example.com as an example of the Authelia root URL which is also the OpenID Connect issuer.
### Well Known Discovery Endpoints
@ -283,12 +238,12 @@ These endpoints can be utilized to discover other endpoints and metadata about t
| Endpoint | Path |
|:-----------------------------------------:|:---------------------------------------------------------------:|
| [OpenID Connect Discovery 1.0] | https://auth.example.com/.well-known/openid-configuration |
| [OpenID Connect Discovery] | https://auth.example.com/.well-known/openid-configuration |
| [OAuth 2.0 Authorization Server Metadata] | https://auth.example.com/.well-known/oauth-authorization-server |
### Discoverable Endpoints
These endpoints implement OpenID Connect 1.0 Provider specifications.
These endpoints implement OpenID Connect elements.
| Endpoint | Path | Discovery Attribute |
|:-------------------------------:|:--------------------------------------------------------------:|:-------------------------------------:|
@ -365,7 +320,7 @@ The advantages of this approach are as follows:
[OpenID Connect 1.0]: https://openid.net/connect/
[OpenID Connect Discovery 1.0]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OpenID Connect Discovery]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OAuth 2.0 Authorization Server Metadata]: https://datatracker.ietf.org/doc/html/rfc8414
[JSON Web Key Set]: https://datatracker.ietf.org/doc/html/rfc7517#section-5

View File

@ -1,8 +1,8 @@
---
title: "Kasm Workspaces"
description: "Integrating Kasm Workspaces with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Kasm Workspaces with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-04-27T18:40:06+10:00
date: 2023-04-25T23:07:05+2:00
draft: false
images: []
menu:
@ -67,20 +67,20 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'kasm'
description: 'Kasm Workspaces'
- id: kasm
description: Kasm Workspaces
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://kasm.example.com/api/oidc_callback'
- https://kasm.example.com/api/oidc_callback
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
consent_mode: 'implicit'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
consent_mode: implicit
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Komga"
description: "Integrating Komga with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Komga with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-08-26T11:39:00+10:00
draft: false
@ -50,22 +50,22 @@ spring:
client:
registration:
authelia:
client-id: 'komga'
client-secret: 'insecure_secret'
client-name: 'Authelia'
scope: 'openid,profile,email'
authorization-grant-type: 'authorization_code'
client-id: `komga`
client-secret: `insecure_secret`
client-name: Authelia
scope: openid,profile,email
authorization-grant-type: authorization_code
redirect-uri: "{baseScheme}://{baseHost}{basePort}{basePath}/login/oauth2/code/authelia"
provider:
authelia:
issuer-uri: 'https://auth.example.com'
user-name-attribute: 'preferred_username'
issuer-uri: https://auth.example.com
user-name-attribute: preferred_username
````
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Komga]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Komga]
which will operate with the above example:
```yaml
@ -74,20 +74,20 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'komga'
description: 'Komga'
- id: komga
description: Komga
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://komga.example.com/login/oauth2/code/authelia'
- https://komga.example.com/login/oauth2/code/authelia
scopes:
- 'openid'
- 'profile'
- 'email'
- openid
- profile
- email
grant_types:
- 'authorization_code'
userinfo_signing_alg: 'none'
- authorization_code
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "MinIO"
description: "Integrating MinIO with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating MinIO with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-21T11:21:23+11:00
draft: false
@ -63,7 +63,7 @@ To configure [MinIO] to utilize Authelia as an [OpenID Connect 1.0] Provider:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [MinIO]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [MinIO]
which will operate with the above example:
```yaml
@ -72,19 +72,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'minio'
description: 'MinIO'
- id: minio
description: MinIO
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://minio.example.com/apps/oidc_login/oidc'
- https://minio.example.com/apps/oidc_login/oidc
scopes:
- 'openid'
- 'profile'
- 'email'
- 'groups'
userinfo_signing_alg: 'none'
- openid
- profile
- email
- groups
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Misago"
description: "Integrating Misago with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Misago with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-14T08:51:13+11:00
draft: false
@ -79,7 +79,7 @@ To configure [Misago] to utilize Authelia as an [OpenID Connect 1.0](https://www
### Authelia
The following YAML configuration is an example **Authelia** [client configuration](https://www.authelia.com/configuration/identity-providers/openid-connect/#clients) for use with [Misago] which will operate with the above example:
The following YAML configuration is an example **Authelia** [client configuration](https://www.authelia.com/configuration/identity-providers/open-id-connect/#clients) for use with [Misago] which will operate with the above example:
```yaml
identity_providers:
@ -87,24 +87,23 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'misago'
description: 'Misago'
- id: misago
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
scopes:
- 'openid'
- 'profile'
- 'email'
- openid
- profile
- email
redirect_uris:
- 'https://misago.example.com/oauth2/complete/'
- https://misago.example.com/oauth2/complete/
grant_types:
- 'authorization_code'
- authorization_code
response_types:
- 'code'
- code
response_modes:
- 'query'
userinfo_signing_alg: 'none'
- query
userinfo_signing_algorithm: none
```
---

View File

@ -1,6 +1,6 @@
---
title: "Nextcloud"
description: "Integrating Nextcloud with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Nextcloud with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -86,7 +86,7 @@ $CONFIG = array (
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Nextcloud]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Nextcloud]
which will operate with the above example:
```yaml
@ -95,19 +95,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'nextcloud'
description: 'NextCloud'
- id: nextcloud
description: NextCloud
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://nextcloud.example.com/apps/oidc_login/oidc'
- https://nextcloud.example.com/apps/oidc_login/oidc
scopes:
- 'openid'
- 'profile'
- 'email'
- 'groups'
userinfo_signing_alg: 'none'
- openid
- profile
- email
- groups
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Outline"
description: "Integrating Outline with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Outline with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-08-12T09:11:42+10:00
draft: false
@ -60,7 +60,7 @@ OIDC_SCOPES="openid offline_access profile email"
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Outline]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Outline]
which will operate with the above example:
```yaml
@ -69,19 +69,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'outline'
description: 'Outline'
- id: outline
description: Outline
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://outline.example.com/auth/oidc.callback'
- https://outline.example.com/auth/oidc.callback
scopes:
- 'openid'
- 'offline_access'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
- openid
- offline_access
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Portainer"
description: "Integrating Portainer with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Portainer with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -61,7 +61,7 @@ To configure [Portainer] to utilize Authelia as an [OpenID Connect 1.0] Provider
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Portainer]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Portainer]
which will operate with the above example:
```yaml
@ -70,19 +70,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'portainer'
description: 'Portainer'
- id: portainer
description: Portainer
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://portainer.example.com'
- https://portainer.example.com
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Proxmox"
description: "Integrating Proxmox with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Proxmox with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -65,7 +65,7 @@ To configure [Proxmox] to utilize Authelia as an [OpenID Connect 1.0] Provider:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Proxmox]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Proxmox]
which will operate with the above example:
```yaml
@ -74,18 +74,18 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'proxmox'
description: 'Proxmox'
- id: proxmox
description: Proxmox
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://proxmox.example.com'
- https://proxmox.example.com
scopes:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Seafile"
description: "Integrating Seafile with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Seafile with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -69,7 +69,7 @@ OAUTH_ATTRIBUTE_MAP = {
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Seafile]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Seafile]
which will operate with the above example:
```yaml
@ -78,18 +78,18 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'seafile'
description: 'Seafile'
- id: seafile
description: Seafile
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://seafile.example.com/oauth/callback/'
- https://seafile.example.com/oauth/callback/
scopes:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Synapse"
description: "Integrating Synapse with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Synapse with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
@ -63,7 +63,7 @@ oidc_providers:
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Synapse]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Synapse]
which will operate with the above example:
```yaml
@ -72,18 +72,18 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'synapse'
description: 'Synapse'
- id: synapse
description: Synapse
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://synapse.example.com/_synapse/client/oidc/callback'
- https://synapse.example.com/_synapse/client/oidc/callback
scopes:
- 'openid'
- 'profile'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Synology DSM"
description: "Integrating Synology DSM with the Authelia OpenID Connect 1.0 Provider."
description: "Integrating Synology DSM with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-10-18T21:22:13+11:00
draft: false
@ -65,7 +65,7 @@ To configure [Synology DSM] to utilize Authelia as an [OpenID Connect 1.0] Provi
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/openid-connect/clients.md) for use with [Synology DSM]
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Synology DSM]
which will operate with the above example:
```yaml
@ -74,19 +74,19 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'synology-dsm'
description: 'Synology DSM'
- id: synology-dsm
description: Synology DSM
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: 'two_factor'
authorization_policy: two_factor
redirect_uris:
- 'https://dsm.example.com'
- https://dsm.example.com
scopes:
- 'openid'
- 'profile'
- 'groups'
- 'email'
userinfo_signing_alg: 'none'
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -1,6 +1,6 @@
---
title: "Tailscale"
description: "Integrating Tailscale with the Authelia OpenID Connect 1.0 Provider."
description: "Using Authelia as the Tailscale OpenID Connect Provider."
lead: ""
date: 2023-04-23T10:06:28+10:00
draft: false
@ -17,7 +17,7 @@ community: true
* [Authelia]
* [v4.37.5](https://github.com/authelia/authelia/releases/tag/v4.37.5)
* [Tailscale] - **Note:** Version not important, since configuration is via the WebUI
* [Tailscale] - Note: Version not important, since configuration is via the web UI
* [1.38.4](https://github.com/tailscale/tailscale/releases/tag/v1.38.4)
## Before You Begin
@ -36,39 +36,35 @@ This example makes the following assumptions:
## Configuration
The configuration in Authelia is straight forward, Tailscale is just another `identity_provider/oidc` entry.
Tailscale also requires a WebFinger reply for your domain - see the following [Application](#application)
section.
The configuration in Authelia is straightforwarded: Tailscale is just another `identity_provider/oidc` entry. Complicating things is the necessary WebFinger reply for your domain - see the following [Application](#application) section.
### Application
To configure [Tailscale] to utilize Authelia as a [OpenID Connect 1.0] Provider, you will need a public WebFinger reply
for your domain (see [RFC7033 Section 3.1]) and point it to Authelia. The steps necessary are outlined in the Tailscale
documentation on [Custom OIDC providers KB article]. This WebFinger reply is not generated by Authelia, so your external
webserver hosted at the root of your domain will need to generate the response (Check [See also](#see-also) for example
implementations). The following steps are necessary to get Tailscale working with Authelia:
To configure [Tailscale] to utilize Authelia as an [OpenID Connect 1.0] Provider, you will need a public WebFinger reply for your domain (see [RFC 7033](https://www.rfc-editor.org/rfc/rfc7033#section-3.1)) and point it to Authelia. The steps necessary are outlined in the Tailscale documentation on [Custom OIDC providers](https://tailscale.com/kb/1240/sso-custom-oidc/). This WebFinger reply is not generated by Authelia, so your external webserver hosted at the root of your domain will need to generate the reponse (Check [See also](#see-also) for example implementations). The following steps are necessary to get Tailscale working with Authelia:
1. Your domain will need to reply to a WebFinger request for your Authelia account
2. Your domain root is `example.com` and the Authelia account in question is `user@example.com` the WebFinger request
will be: `https://example.com/.well-known/webfinger/?resource=acct:user@example.com the complete request is `https://example.com/.well-known/webfinger?rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer&resource=acct%3Auser%40example.com`
2. Your domain root is `example.com` and the Authelia account in question is `user@example.com`, the WebFinger request will be: `https://example.com/.well-known/webfinger/?resource=acct:user@example.com` (the complete request is `https://example.com/.well-known/webfinger?rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer&resource=acct%3Auser%40example.com`)
3. The WebFinger request needs to be answered with the following example reply:
```json
```
{
"subject" : "acct:user@example.com",
"links": [{
"links" :
[
{
"rel" : "http://openid.net/specs/connect/1.0/issuer",
"href" : "https://auth.example.com"
}]
}
]
}
```
4. For any other users that you want to add to Tailscale, you will need to provide similar WebFinger replies (e.g. for `user2@example.com` or `user3@example.com`)
5. Once you have the WebFinger reply set up and your [Authelia OpenID Connect Discovery endpoint](https://www.authelia.com/integration/openid-connect/introduction/#well-known-discovery-endpoints) is working (e.g. `https://auth.example.com/.well-known/openid-configuration`), you can sign up for a **new Tailnet** (migration can only be done if the Tailnet is associated with a custom domain) via the link: [Sign up with OIDC](https://login.tailscale.com/start/oidc) where you will see the following screen: \
{{< figure src="tailscale_signup_1.png" alt="Tailscale Signup Screen 1" width="300" >}} \
4. For any other users that you want to add to Tailscale, you will need to to provide similar WebFinger replies (e.g. for `user2@example.com` or `user3@example.com`)
5. Once you have the WebFinger reply set up and your [Authelia OpenID Connect Discovery endpoint](https://www.authelia.com/integration/openid-connect/introduction/#well-known-discovery-endpoints) is working (e.g. `https://auth.example.com/.well-known/openid-configuration`), you can sign up for a **new Tailnet** (currently migration isn't supported) via the link: [Sign up with OIDC](https://login.tailscale.com/start/oidc) where you will see the following screen:
{{< figure src="tailscale_signup_1.png" alt="Tailscale Signup Screen 1" width="300" >}}
**Note:** Even though the WebFinger URL displayed is `https://example.com/.well-known/webfinger`, the actual GET request will be including request parameters, most importantly `resource`.
6. After clicking on **Get OIDC Issuer**, Tailscale will fetch the WebFinger reply via `https://example.com/.well-known/webfinger/?resource=acct:user@example.com` and follow the set `href` to `https://auth.example.com/.well-known/openid-configuration`. \
**Note:** Make sure that the `href` URL matches the `issuer` URL returned from the Authelia OIDC discovery endpoint
7. On the next screen you will need to add your client ID & secret configured in Authelia to finish the OIDC provider registration in [Tailscale]. See the following example screenshot: \
6. After clicking on **Get OIDC Issuer**, Tailscale will fetch the WebFinger reply via `https://example.com/.well-known/webfinger/?resource=acct:user@example.com` and follow the set `href` to `https://auth.example.com/.well-known/openid-configuration`.
**Note:** make sure that the `href` URL matches the `issuer` URL returned from the Authelia OIDC dicsovery endpoint
7. On the next screen you will need to add your client ID & secret configured in Authelia to finish the OIDC provider registration in [Tailscale]. See the following example screenshot:
{{< figure src="tailscale_signup_2.png" alt="Tailscale Signup Screen 2" width="300" >}}
@ -84,25 +80,23 @@ identity_providers:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: 'tailscale'
description: 'Tailscale'
- id: tailscale
description: Tailscale SSO
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
redirect_uris:
- 'https://login.tailscale.com/a/oauth_response'
- https://login.tailscale.com/a/oauth_response
scopes:
- 'openid'
- 'email'
- 'profile'
- openid
- email
- profile
```
## See Also
- [Tailscale] [Custom OIDC providers KB article]
- [RFC7033 Section 3.1] _WebFinger: Identity Provider Discovery for OpenID Connect_
- [Tailscale] [Custom OIDC Provider Knowledge Base entry](https://tailscale.com/kb/1240/sso-custom-oidc/):
- [RFC 7033, Identity Provider Discovery for OpenID Connect](https://www.rfc-editor.org/rfc/rfc7033#section-3.1)
- [WebFinger example implementations](https://webfinger.net/code/)
[Authelia]: https://www.authelia.com
[Tailscale]: https://tailscale.com
[Custom OIDC providers KB article]: https://tailscale.com/kb/1240/sso-custom-oidc/
[RFC7033 Section 3.1]: https://datatracker.ietf.org/doc/html/rfc7033#section-3.1
[OpenID Connect 1.0]: ../../openid-connect/introduction.md

Binary file not shown.

Before

Width:  |  Height:  |  Size: 59 KiB

After

Width:  |  Height:  |  Size: 63 KiB

View File

@ -36,7 +36,7 @@ In addition to the `https` scheme requirement for Authelia itself:
1. Due to the fact a cookie is used, it's an intentional design decision that *__ALL__* applications/domains protected via
this method *__MUST__* use secure schemes (`https` and `wss`) for all of their communication.
### OpenID Connect 1.0
### OpenID Connect
No additional requirements other than the use of the `https` scheme for Authelia itself exist excluding those mandated
by the relevant specifications.
@ -93,11 +93,6 @@ recommended that you read the relevant [Proxy Integration Documentation](../prox
recommend viewing the dedicated [Kubernetes Documentation](../kubernetes/introduction.md) prior to viewing the
[Proxy Integration Documentation](../proxies/introduction.md).*
## Additional Useful Links
See the [Frequently Asked Questions](../../reference/guides/frequently-asked-questions.md) for helpful sections of the
documentation which may answer specific questions.
## Moving to Production
We consider it important to do several things in moving to a production environment.

View File

@ -101,7 +101,7 @@ server:
endpoints:
authz:
forward-auth:
implementation: 'ForwardAuth'
implementation: ForwardAuth
```
## Configuration

View File

@ -75,7 +75,7 @@ server:
endpoints:
authz:
ext-authz:
implementation: 'ExtAuthz'
implementation: ExtAuthz
```
## Configuration
@ -97,47 +97,47 @@ Support for [Envoy] is possible with Authelia v4.37.0 and higher via the [Envoy]
version: "3.8"
networks:
net:
driver: 'bridge'
driver: bridge
services:
envoy:
container_name: 'envoy'
image: 'envoyproxy/envoy:v1.24'
restart: 'unless-stopped'
container_name: envoy
image: envoyproxy/envoy:v1.24
restart: unless-stopped
networks:
net: {}
ports:
- '80:8080'
- '443:8443'
volumes:
- '${PWD}/data/envoy/envoy.yaml:/etc/envoy/envoy.yaml:ro'
- '${PWD}/data/certificates:/certificates:ro'
- ${PWD}/data/envoy/envoy.yaml:/etc/envoy/envoy.yaml:ro
- ${PWD}/data/certificates:/certificates:ro
authelia:
container_name: 'authelia'
image: 'authelia/authelia'
restart: 'unless-stopped'
container_name: authelia
image: authelia/authelia
restart: unless-stopped
networks:
net: {}
expose:
- 9091
volumes:
- '${PWD}/data/authelia/config:/config'
- ${PWD}/data/authelia/config:/config
environment:
TZ: 'Australia/Melbourne'
TZ: "Australia/Melbourne"
nextcloud:
container_name: 'nextcloud'
image: 'linuxserver/nextcloud'
restart: 'unless-stopped'
container_name: nextcloud
image: linuxserver/nextcloud
restart: unless-stopped
networks:
net: {}
expose:
- 443
volumes:
- '${PWD}/data/nextcloud/config:/config'
- '${PWD}/data/nextcloud/data:/data'
- ${PWD}/data/nextcloud/config:/config
- ${PWD}/data/nextcloud/data:/data
environment:
PUID: '1000'
PGID: '1000'
TZ: 'Australia/Melbourne'
PUID: "1000"
PGID: "1000"
TZ: "Australia/Melbourne"
```
{{< /details >}}
@ -145,92 +145,92 @@ services:
```yaml
static_resources:
listeners:
- name: 'listener_http'
- name: listener_http
address:
socket_address:
address: '0.0.0.0'
address: 0.0.0.0
port_value: 8080
filter_chains:
- filters:
- name: 'envoy.filters.network.http_connection_manager'
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": 'type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager'
codec_type: 'auto'
stat_prefix: 'ingress_http'
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
codec_type: auto
stat_prefix: ingress_http
route_config:
name: 'local_route'
name: local_route
virtual_hosts:
- name: 'backend'
domains: ['*']
- name: backend
domains: ["*"]
routes:
- match:
prefix: '/'
prefix: "/"
redirect:
https_redirect: true
http_filters:
- name: 'envoy.filters.http.router'
- name: envoy.filters.http.router
typed_config:
"@type": 'type.googleapis.com/envoy.extensions.filters.http.router.v3.Router'
- name: 'listener_https'
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
- name: listener_https
address:
socket_address:
address: '0.0.0.0'
address: 0.0.0.0
port_value: 8443
filter_chains:
- filters:
- name: 'envoy.filters.network.http_connection_manager'
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": 'type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager'
stat_prefix: 'ingress_http'
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
use_remote_address: true
skip_xff_append: false
route_config:
name: 'local_route'
name: local_route
virtual_hosts:
- name: 'whoami_service'
- name: whoami_service
domains: ["nextcloud.example.com"]
routes:
- match:
prefix: "/"
route:
cluster: 'nextcloud'
- name: 'authelia_service'
domains: ['auth.example.com']
cluster: nextcloud
- name: authelia_service
domains: ["auth.example.com"]
typed_per_filter_config:
envoy.filters.http.ext_authz:
"@type": 'type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute'
"@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
disabled: true
routes:
- match:
prefix: '/'
prefix: "/"
route:
cluster: 'authelia'
cluster: authelia
http_filters:
- name: 'envoy.filters.http.ext_authz'
- name: envoy.filters.http.ext_authz
typed_config:
"@type": 'type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz'
transport_api_version: 'v3'
"@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
transport_api_version: v3
allowed_headers:
patterns:
- exact: 'authorization'
- exact: 'proxy-authorization'
- exact: 'accept'
- exact: 'cookie'
- exact: authorization
- exact: proxy-authorization
- exact: accept
- exact: cookie
http_service:
path_prefix: '/api/authz/ext-authz/'
path_prefix: /api/authz/ext-authz/
server_uri:
uri: 'authelia:9091'
cluster: 'authelia'
timeout: '0.25s'
uri: authelia:9091
cluster: authelia
timeout: 0.25s
authorization_request:
allowed_headers:
patterns:
- exact: 'authorization'
- exact: 'proxy-authorization'
- exact: 'accept'
- exact: 'cookie'
- exact: authorization
- exact: proxy-authorization
- exact: accept
- exact: cookie
headers_to_add:
- key: 'X-Forwarded-Proto'
- key: X-Forwarded-Proto
value: '%REQ(:SCHEME)%'
## The following commented lines are for configuring the Authelia URL in the proxy. We
## strongly suggest this is configured in the Session Cookies section of the Authelia configuration.
@ -239,52 +239,52 @@ static_resources:
authorization_response:
allowed_upstream_headers:
patterns:
- exact: 'authorization'
- exact: 'proxy-authorization'
- prefix: 'remote-'
- prefix: 'authelia-'
- exact: authorization
- exact: proxy-authorization
- prefix: remote-
- prefix: authelia-
allowed_client_headers:
patterns:
- exact: 'set-cookie'
- exact: set-cookie
allowed_client_headers_on_success:
patterns:
- exact: 'set-cookie'
- exact: set-cookie
failure_mode_allow: false
- name: 'envoy.filters.http.router'
- name: envoy.filters.http.router
typed_config:
"@type": 'type.googleapis.com/envoy.extensions.filters.http.router.v3.Router'
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
clusters:
- name: 'nextcloud'
connect_timeout: '0.25s'
type: 'logical_dns'
dns_lookup_family: 'v4_only'
lb_policy: 'round_robin'
- name: nextcloud
connect_timeout: 0.25s
type: logical_dns
dns_lookup_family: v4_only
lb_policy: round_robin
load_assignment:
cluster_name: 'nextcloud'
cluster_name: nextcloud
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: 'nextcloud'
address: nextcloud
port_value: 80
- name: 'authelia'
connect_timeout: '0.25s'
type: 'logical_dns'
dns_lookup_family: 'v4_only'
lb_policy: 'round_robin'
- name: authelia
connect_timeout: 0.25s
type: logical_dns
dns_lookup_family: v4_only
lb_policy: round_robin
load_assignment:
cluster_name: 'authelia'
cluster_name: authelia
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: 'authelia'
address: authelia
port_value: 9091
layered_runtime:
layers:
- name: 'static_layer_0'
- name: static_layer_0
static_layer:
envoy:
resource_limits:

Some files were not shown because too many files have changed in this diff Show More