Merge remote-tracking branch 'origin/master' into fix-pp-layout

# Conflicts:
#	internal/suites/utils.go
fix-pp-layout
James Elliott 2023-04-09 15:38:04 +10:00
commit 2d30814365
No known key found for this signature in database
GPG Key ID: 0F1C4A096E857E49
374 changed files with 10184 additions and 6647 deletions

View File

@ -0,0 +1,8 @@
#!/usr/bin/env bash
set +u
if [[ "${BUILDKITE_LABEL}" == ":docker: Build Image [coverage]" && "${BUILDKITE_AGENT_NAME}" =~ ^vega[0-9]+$ ]]; then
mv authelia-image-coverage.tar.zst authelia-image-coverage-vega.tar.zst
BUILDKITE_S3_ENDPOINT="${S3_ENDPOINT}" BUILDKITE_ARTIFACT_UPLOAD_DESTINATION="${S3_BUCKET}" BUILDKITE_S3_ACCESS_URL="${S3_ACCESS_URL}" BUILDKITE_S3_ACCESS_KEY_ID="${S3_ACCESS_KEY_ID}" BUILDKITE_S3_SECRET_ACCESS_KEY="${S3_SECRET_ACCESS_KEY}" buildkite-agent artifact upload authelia-image-coverage-vega.tar.zst
fi

View File

@ -15,6 +15,8 @@ if [[ ! "${BUILDKITE_BRANCH}" =~ ^(v.*) ]] && [[ "${BUILDKITE_COMMAND_EXIT_STATU
NAME="UnitTest"
if [[ "${SUITE}" != "" ]]; then
NAME=${SUITE}
go tool covdata percent -i=coverage
go tool covdata textfmt -i=coverage -o coverage.txt
fi
if [[ "${BUILDKITE_AGENT_META_DATA_CODECOV}" == "verbose" ]]; then
BUILDKITE_AGENT_META_DATA_CODECOV="-v"
@ -23,7 +25,7 @@ if [[ ! "${BUILDKITE_BRANCH}" =~ ^(v.*) ]] && [[ "${BUILDKITE_COMMAND_EXIT_STATU
if [[ "${BUILDKITE_LABEL}" =~ ":selenium:" ]]; then
cd web && pnpm report
fi
codecov -Z -c -f '!Dockerfile*' -f '!*.go' -f '!*.zst' -n ${NAME} -F frontend "${BUILDKITE_AGENT_META_DATA_CODECOV}"
codecov -Z -c -f '!Dockerfile*' -f '!*.go' -f '!*.tar' -f '!*.zst' -n ${NAME} -F frontend "${BUILDKITE_AGENT_META_DATA_CODECOV}"
fi
fi

View File

@ -21,7 +21,6 @@ if [[ "${BUILDKITE_LABEL}" == ":hammer_and_wrench: Unit Test" ]]; then
fi
if [[ "${BUILDKITE_LABEL}" == ":docker: Build Image [coverage]" ]]; then
# Saving image for docker push
docker save "${DOCKER_IMAGE}" | zstdmt -T0 -12 > "authelia-image-coverage.tar.zst"
fi

View File

@ -29,13 +29,20 @@ if [[ "${BUILDKITE_LABEL}" =~ ":debian: Build Package" ]]; then
fi
if [[ "${BUILDKITE_LABEL}" =~ ":selenium:" ]]; then
DEFAULT_ARCH=coverage
echo "--- :docker: Extract and load build container"
buildkite-agent artifact download "authelia-image-${DEFAULT_ARCH}*" .
if [[ "${SUITE}" == "Kubernetes" ]]; then
zstd -d authelia-image-coverage.tar.zst --stdout > ./internal/suites/example/kube/authelia-image-${DEFAULT_ARCH}.tar
mkdir coverage
if [[ "${BUILDKITE_AGENT_NAME}" =~ ^vega[0-9]+$ ]]; then
BUILDKITE_S3_ENDPOINT="${S3_ENDPOINT}" BUILDKITE_ARTIFACT_UPLOAD_DESTINATION="${S3_BUCKET}" BUILDKITE_S3_ACCESS_URL="${S3_ACCESS_URL}" BUILDKITE_S3_ACCESS_KEY_ID="${S3_ACCESS_KEY_ID}" BUILDKITE_S3_SECRET_ACCESS_KEY="${S3_SECRET_ACCESS_KEY}" buildkite-agent artifact download "authelia-image-coverage-vega*" .
mv authelia-image-coverage-vega.tar.zst authelia-image-coverage.tar.zst
else
zstdcat "authelia-image-${DEFAULT_ARCH}.tar.zst" | docker load
buildkite-agent artifact download "authelia-image-coverage.*" .
fi
if [[ "${SUITE}" == "Kubernetes" ]]; then
zstd -d authelia-image-coverage.tar.zst --stdout > ./internal/suites/example/kube/authelia-image-coverage.tar
else
zstdcat "authelia-image-coverage.tar.zst" | docker load
fi
if [[ "${BUILD_DUO}" == "true" ]] && [[ "${SUITE}" == "DuoPush" ]]; then
@ -54,13 +61,13 @@ if [[ "${BUILDKITE_LABEL}" =~ ":selenium:" ]]; then
fi
if [[ "${BUILDKITE_LABEL}" == ":docker: Build and Deploy" ]]; then
echo ${DOCKER_PASSWORD} | docker login -u ${DOCKER_USERNAME} --password-stdin
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
fi
if [[ "${BUILDKITE_LABEL}" == ":docker: Deploy Manifest" ]]; then
echo "--- :go: :react: :swagger: Extract pre-built binary"
buildkite-agent artifact download "authelia-linux-*-musl.tar.gz" .
for archive in authelia-linux-*-musl.tar.gz; do tar xzf ${archive} --wildcards "authelia-linux-*"; done
for archive in authelia-linux-*-musl.tar.gz; do tar xzf "${archive}" --wildcards "authelia-linux-*"; done
fi
if [[ "${BUILDKITE_LABEL}" == ":github: Deploy Artifacts" ]]; then

View File

@ -133,7 +133,9 @@ body:
id: logs
attributes:
label: Logs (Authelia)
description: Provide complete debug logs (the template will automatically put this content in a code block)
description: |
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

2
.gitignore vendored
View File

@ -25,3 +25,5 @@ authelia-image-dev.tar
/authelia
__debug_bin
internal/suites/common/pki/ca/ca.private.pem

View File

@ -18,7 +18,9 @@ repository (but search first in case a similar issue already exists).
If you would like to fix a bug or implement a feature, please fork the repository and create a Pull Request.
More information on getting set up locally can be found in the
[Development Contribution](https://www.authelia.com/contributing/development/introduction/) documentation.
[Development Contribution](https://www.authelia.com/contributing/development/introduction/) documentation, in addition
the [Contribution Guidelines](https://www.authelia.com/contributing/guidelines/introduction/) documentation includes
several contribution guidelines.
Before you start any Pull Request, it's recommended that you create an issue to discuss first if you have any doubts
about requirement or implementation. That way you can be sure that the maintainer(s) agree on what to change and how,

View File

@ -1,7 +1,7 @@
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.17.1
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.19.5-alpine AS builder-backend
FROM golang:1.20.3-alpine AS builder-backend
WORKDIR /go/src/app
@ -39,14 +39,14 @@ RUN \
mv api internal/server/public_html/api && \
cd cmd/authelia && \
chmod 0666 /go/src/app/.healthcheck.env && \
echo ">> Starting go build (coverage via go test)..." && \
CGO_ENABLED=1 CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-strong" CGO_LDFLAGS="-Wl,-z,relro,-z,now" go test -c --tags coverage -covermode=atomic \
-ldflags "${LDFLAGS_EXTRA}" -o authelia -coverpkg github.com/authelia/authelia/...
echo ">> Starting go build (coverage via -cover)..." && \
CGO_ENABLED=1 CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-strong" CGO_LDFLAGS="-Wl,-z,relro,-z,now" go build -cover -covermode=atomic \
-ldflags "${LDFLAGS_EXTRA}" -o authelia
# ===================================
# ===== Authelia official image =====
# ===================================
FROM alpine:3.17.1
FROM alpine:3.17.3
RUN apk --no-cache add ca-certificates tzdata
@ -59,7 +59,8 @@ EXPOSE 9091
VOLUME /config
ENV PATH="/app:${PATH}" \
GOCOVERDIR="/authelia/coverage/" \
X_AUTHELIA_CONFIG="/config/configuration.yml"
CMD ["authelia", "-test.coverprofile=/authelia/coverage.txt", "COVERAGE"]
CMD ["authelia"]
HEALTHCHECK --interval=30s --timeout=3s CMD /app/healthcheck.sh

View File

@ -13,7 +13,7 @@ RUN yarn install --frozen-lockfile && yarn build
# =======================================
# ===== Build image for the backend =====
# =======================================
FROM golang:1.19.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.17.1
FROM alpine:3.17.3
WORKDIR /app

View File

@ -3,10 +3,12 @@
</p>
[![Build](https://img.shields.io/buildkite/d6543d3ece3433f46dbe5fd9fcfaf1f68a6dbc48eb1048bc22/master?logo=buildkite&style=flat-square&color=brightgreen)](https://buildkite.com/authelia/authelia)
[![OpenSSF Best Practices](https://img.shields.io/static/v1?label=openssf%20best%20practices&logo=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEYAAABGCAYAAABxLuKEAAAK/UlEQVR4nOxcD2wb1Rn/pXE5lxRfYQPiLXdsA48/SSG+eRPBKYg/ZeIqGIwyTWWAkKPWhYxIgw2GNhXB0JiAsdCMHRBro5rKAG3TgFwZdGv542UF75xhWmkYunFnuPBv41wDZ2q300veZW7+2e98l6rSflKaq+Pve19++d73vu997zmwf/9+/B8zESD/tLS0HJTB+XjicACfBXAMgMX0ZQvAW7auvVs2svsOimGEE+IxfhPDCdGjAJwTFKXlAE4E8HkAHQDaASyaQ6wM4F/063Vb13YBGKtY5o5qcbziq8F+E8PHE6cCuBnAJQAO80jtbgB32bq2qWxkP/RI5wx4TgwnRI8O8OFkgA9fBKDbma4+4F0AWyuW+Ttb135fLY5XvVTuGTFtXfLKAB9eC+AC8l9PrGsc/wCwyda1h8pG9k0vFHpCDB9PrAOgeGFQk3jH1rVY2cgazSpqipi2Lvn0AB++BcB5AFqbNcYjvAXg3lJuRKkWxy23SlwRwwnR44OidDuAS32MIc2CrGYbSrmRzW5WMWZiOCF6WFCUXgEQYR3sIOFWK53awCo0Vw4xKzghuiwoSo8dQqQQfL+tS76SVahhjyFJWlCUXqaZ6qEGspT3WOnUS40KNOQxnBBtC4rSrw9RUgh+YetahkWgbuBs65K7Anx4C03hvQCpf3QAxPt22rpG8o4igI/pHyoE4NNBUSLjfQnAaQCWNDHeUCk38u1qcZxJqC4xAT58j0ek7AXwWwC3WenUrnpvLhvZie98PEHIuprIAQgzjrnZ1rXrWElBvRjT1iVfGODDjzNrPRAmzUo3Ts9KO+TkkZT0ZQAOp7GAeM/bxXzGLOYznzjv5YQoMfLMoCjdSLPrehgipJSNrKt9lXmJ4eOJHIAuN4opSFy6ykqnprYPOuTkEkFOriavAzh3HtmPSGwAcP9of3d+ml1xAI/N40HEU77llhTMRUxrqL116fJV9wNIuNQ7ZuvahoplqiS5CkVirR1ycjUfiV0G4CwSQxj1kXmlGqrym4KqkByKeJAQFKUbqI21tVlTnuJgVmLauuRrA3x4yKXOzaXcSKJaHLdDkdgRnQPDawD0N+l5Dsgvu8lQlbscguji8CSA49wG2tkwKzF8PEGC48ku9D1q69qaspGt9gyNEaVP0zrKD1wx2t9NpirxntODotRv69oVzXqKgxnE0EFGXegatnVtLTHslIHhs/hI7AEAX/TCyDlAlvf7dg723VbMZ1wXi3NhRoJHoz4r/lzKjaynpKzkI7EtPpMCmttc3zkwvN4P5QfkMXw8QZbNVaxKbF27ngTZnqExEgQfajIhY8EThqrc6Yfi6R5zR81ufSMg5fy6spEd65CTpFx40UUS5hYPGqpySUFVPN3SdDBFDCdESbK1jlF+m5VOkVgCQU6SpfMUzy2cHcRT1vtFCqZ5TC+rcMUyJ0gJRWIkL2Eu7V3CV09xMBVjgqIkM8qqtq6R2gedA8M3AzjKc+tm4sGdg33rivmM7+3T2uAbZZQlxZlj4DebsOE1AI8AIOUHB+BCumU6vU6ZmD4LQQocYjgh2grgJAa5rJVOvU4eeobG1rkMuC8YqnJDQVV2THt9U4ec5EOR2Df4SOzHAD5Fp4+vMWU6JmJMUJQ6yWrNIPc8JgvCFrodwIqnDFU5t5YUPp5YTP9AKKiKtWuw70EAly1EoJ0NzlQ6k0XI1rUcfSSEHs045qOGqqwhv2hbl9wb4MPraeAXg6K0NyhKGQB/KOVGhkf7u7d1yMntBVVZ8CMZDjHzlf+z4UX6nXUle5UGT0LK6gAffnhanCM5VA/5Wrp8VV8pN3JGQVXeZRzDEzjLNWv6XsBk7nIco9y1xXzmA0zuDN5VZwfxhKXLV13LqN8zOMSwbHLvrVjmf+hzO4OcaajKnzAZT9bTbYJ6WM2g31M4xLAE3j01yzSL3K6aWNFoodrJxxOfYxjDMzA13ChqVweWfvXemmcWQlne6xkcYliOdNVWzmUGudrM+G8Nyti2rr3OMIZncIh5n0FmCd2xB93RbxQn1jxvbFBmrGxkSwxjeAaHGJbzJGT6HEserHymwCDH9wyNXYPJPOhxJ0mcDxXLHGbQ7ykcYv7KKDexvVDMZ/7OKLfxlIHhFWUju7+UGyErzly95AqAH9m6lmLU7xkcYhpudlM4O/6sxCziI7GfkodqcfwdW9dW0BXKrHnPUySvstKpH3qx2+8WE5vhy3r7yJL4Twa5X1np1NWhSGxR58AwqXdijOPusPKZ/l2DfRON9tZQeyDAh0lw3ls2shM5UigSa+mQkzfykdjFhqpcXlCVBQ3CU10CPp4Yd2JHA9htpVPHY7K6vgCA6mJssqJdNNrf/fT0H/QMjS2mXUin4ffCaH/3ChdjuEYtMSQrPYdB9nwrnXqmQ04uEuTkGIDlLsYnaUIewE4Ab9PATlavL9Nedi1e2DnYd1Uxn9ntYhxmTCV4Fcvcyij7CCdEjymoyj4rn7m9ifEJEV8HQMqEtbSFO50Ugt7OgeFtoUjsCy7HYjZsAhXLZF2ZjgyK0qWYXJ0eBbAQkVLsHBh+aAHGOYCYFwG8xyif5IQoR2ogK5/5iffmzYrenqGx5/32nCliqsXxDwHczSh/alCU7sGk12x0kQ+5Ra/fnnNAEWnr2s9pEGTB+rYu+eKCqlQNVTkfwLPemjgnfPWcA4gpG9k9Fcu8j1VJgA//sq1LPrmgKnt2DvZdSFYQT62cG2d0yElfTlPM2HaoWOZmF3qWBfjwRPOtmM/sMVSFkFP3nF2TsAHIuwb7HvBD+Qxiykb2NQDbXejq5eOJ5zkhGimoygeGqkStfOYWAF7fKSK5z3NWPvPV0f7uP2Ly8FCSjye2t4baPZtWsx4c4oRolJ6R4VzofK9imWs+fEV9BpMtFi4Uia3lI7GbAHymSXu3G6pyk9N24YTokqAo3QbgevpzvZQbObNaHH+jyXHmPpzIxxPXARh0qbcK4CZb1+52Tjh1yMkjBDlJCsZrSA7EqO8vAAZG+7unDjFzQvSEoCg9OwvZW610aqVLu6cwJzGcEG0JitKTZB43of9ZW9furVjmlmpx/GNMEhQC8JVQJNbNR2LStOOs++hl0XcAvGGoCiHkpWI+86rTmqWEJOjZ37lqu630HKDu1vB5j7NyQpTkKaxbC7MhZ+uaXDayLBtbM8DHE5cB2AQg2MDbm/Kcupcs+HjiflrDNIuPAOyoWOa2imVqAF6e7yYa3Yo4DcBpQVE6gzYFWTsGrj2nLjGtofbFS5ev2gDge4ynrRpBEcCbAPZQ4kh1vZS2fY/1aLzdpdzI2azkNHwth48nhgActM5gk2CeVg33lUq5kR/QC6G+Xwb3ASInRJkuijBf/ePjCVJofseNdQcJVXqzdoxFiLkTWcqN3AzATdlwMDCRbLKSAre3aFtD7aRwXBEUpTtIIcc66ALgk4pl3lmxzFvLRvYTNwqaunfNCVEuKEokKPe5UuAPyOpznpVO5ZtR4slN/bYu+fwAH/6Zy4sZXoFkzQ/buvbdspE1m1Xm2Wc70ISsNyhKVwK43MNP/6iHQsUy765Y5qaykf23V0p9+ZgUPp6I0gLUz17Q+wDuJLVY2ch+7LVyXz8/hhOiJwE4m6b0KxkaerOhSs8CP2Xr2nMVy0xXi+Mspy2YsCCfOIT/VeudAL5G654YgCPqiL1GT0VsAfCElU7ZvhtKsWDETEdrqL0lwIePpSemDqebYvvoBa0SmSplI+ubR9TDfwMAAP//J8ZWGNO8y2EAAAAASUVORK5CYII=&message=passing&style=flat-square&color=brightgreen)](https://bestpractices.coreinfrastructure.org/projects/7128)
[![Go Report Card](https://goreportcard.com/badge/github.com/authelia/authelia/v4?logo=go&style=flat-square)](https://goreportcard.com/report/github.com/authelia/authelia/v4)
[![GitHub Release](https://img.shields.io/github/release/authelia/authelia.svg?logo=github&style=flat-square&color=blue)](https://github.com/authelia/authelia/releases)
[![Docker Tag](https://img.shields.io/docker/v/authelia/authelia/latest?logo=docker&style=flat-square&color=blue&sort=semver)](https://hub.docker.com/r/authelia/authelia/tags)
[![Docker Size](https://img.shields.io/docker/image-size/authelia/authelia/latest?logo=docker&style=flat-square&color=blue&sort=semver)](https://hub.docker.com/r/authelia/authelia/tags)
[![GitHub Release](https://img.shields.io/github/release/authelia/authelia.svg?logo=github&style=flat-square&color=blue)](https://github.com/authelia/authelia/releases)
![Docker Pulls](https://img.shields.io/docker/pulls/authelia/authelia?logo=docker&label=pulls&style=flat-square&color=blue)
[![AUR source version](https://img.shields.io/aur/version/authelia?logo=arch-linux&label=authelia&style=flat-square&color=blue)](https://aur.archlinux.org/packages/authelia/)
[![AUR binary version](https://img.shields.io/aur/version/authelia-bin?logo=arch-linux&label=authelia-bin&style=flat-square&color=blue)](https://aur.archlinux.org/packages/authelia-bin/)
[![AUR development version](https://img.shields.io/aur/version/authelia-git?logo=arch-linux&label=authelia-git&style=flat-square&color=blue)](https://aur.archlinux.org/packages/authelia-git/)

View File

@ -2,46 +2,83 @@
## Prologue
Authelia takes security very seriously. We follow the rule of
[responsible disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure), and we urge our community to do so as
well instead of making the vulnerability public. This allows time for the security issue to be patched quickly.
The __Authelia__ team takes security very seriously. Because __Authelia__ is intended as a security product a lot of
decisions are made with security being the priority and we always aim to implement security by design.
If you discover a vulnerability in Authelia, please first contact one of the maintainers privately as described in the
[contact options](#contact-options) below.
## Coordinated vulnerability disclosure
We urge you not to disclose the bug publicly at least until we've had a
reasonable chance to fix it, and to clearly communicate any public disclosure timeline in your initial contact with us.
If you do not have a particular public disclosure timeline, we will clearly communicate ours as we publish security
advisories.
__Authelia__ follows the [coordinated vulnerability disclosure] model when dealing with security vulnerabilities. This
was previously known as responsible disclosure. We strongly urge anyone reporting vulnerabilities to __Authelia__ or any
other project to follow this model as it is considered as a best practice by many in the security industry.
For more information about [security](https://www.authelia.com/information/security/) related matters, please read
[the documentation](https://www.authelia.com/information/security/).
If you believe you have identified a security vulnerability or security related bug with __Authelia__ please make every
effort to contact us privately using one of the [contact options](#contact-options) below. Please do not open an issue,
do not notify us in public, and do not disclose this issue to third parties.
Using this process helps ensure that users affected have an avenue to fixing the issue as close to the issue being
made public as possible. This mitigates the increasing the attack surface (via improving attacker knowledge) for
diligent administrators simply via the act of disclosing the security issue.
For more information about [security](https://www.authelia.com/security/) related matters, please read
[the documentation](https://www.authelia.com/security/).
## Contact Options
Several [contact options](README.md#contact-options) exist, it's important to make sure you contact the maintainers
privately which is described in each available contact method. The methods include our [security email](README.md#security),
[Matrix](README.md#matrix), and [Discord](README.md#discord).
Several contact options exist however it's important you specifically use a security contact method when reporting a
security vulnerability or security related bug. These methods are clearly documented below.
## Credit
### GitHub Security
Users who report bugs will optionally be credited for the discovery. Both in the [security advisory] and in our
[all contributors](README.md#contribute) configuration/documentation.
Users can utilize GitHub's security vulnerability system to privately [report a vulnerability]. This is an easy method
for users who have a GitHub account.
### Email
Users can utilize the [security@authelia.com](mailto:security@authelia.com) email address to privately report a
vulnerability. This is an easy method of users who do not have a GitHub account.
This email address is only accessible by members of the [core team] for the purpose of disclosing security
vulnerabilities and issues within the __Authelia__ code base.
### Chat
If you wish to chat directly instead of sending an email please use either [Matrix](README.md#matrix) or
[Discord](README.md#discord) to direct / private message one of the [core team] members.
Please avoid this method unless absolutely necessary. We generally prefer that users use either the
[GitHub Security](#github-security) or [Email](#email) option rather than this option as it both allows multiple team
members to deal with the report and prevents mistakes when contacting a [core team] member.
The [core team] members are identified in [Matrix](README.md#matrix) as room admins, and in [Discord](README.md#discord)
with the `Core Team` role.
## Process
1. User privately reports a potential vulnerability.
2. The core team reviews the report and ascertain if additional information is required.
3. The core team reproduces the bug.
4. The bug is patched, and if possible the user reporting te bug is given access to a fixed version or git patch.
5. The fix is confirmed to resolve the vulnerability.
6. The fix is released.
7. The [security advisory] is published sometime after users have had a chance to update.
1. The user privately reports a potential vulnerability.
2. The report is acknowledged as received.
3. The report is reviewed to ascertain if additional information is required. If it is required:
1. The user is informed that the additional information is required.
2. The user privately adds the additional information.
3. The process begins at step 3 again, proceeding to step 4 if the additional information provided is sufficient.
4. The vulnerability is reproduced.
5. The vulnerability is patched, and if possible the user reporting the bug is given access to a fixed binary, docker
image, and git patch.
6. The patch is confirmed to resolve the vulnerability.
7. The fix is released and users are notified that they should update urgently.
8. The [security advisory] is published when (whichever happens sooner):
- The CVE details are published by [MITRE], [NIST], etc.
- Roughly 7 days after users have been notified the update is available.
## Help Wanted
[MITRE]: https://www.mitre.org/
[NIST]: https://www.nist.gov/
We are actively looking for sponsorship to obtain either a code security audit, penetration testing, or other audits
related to improving the security of Authelia. If your company or you personally are willing to offer discounts, pro
bono, or funding towards services like these please feel free to contact us on *any* of the methods above.
## Credit
Users who report bugs will at their discretion (i.e. they do not have to be if they wish to remain anonymous) be
credited for the discovery. Both in the [security advisory] and in our [all contributors](README.md#contribute)
documentation.
[coordinated vulnerability disclosure]: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure
[security advisory]: https://github.com/authelia/authelia/security/advisories
[report a vulnerability]: https://github.com/authelia/authelia/security/advisories/new
[core team]: https://www.authelia.com/information/about/#core-team

File diff suppressed because it is too large Load Diff

View File

@ -118,14 +118,14 @@ func codeScriptsRunE(cmd *cobra.Command, args []string) (err error) {
return err
}
if resp, err = http.Get("https://api.github.com/repos/swagger-api/swagger-ui/tags"); err != nil {
if resp, err = http.Get("https://api.github.com/repos/swagger-api/swagger-ui/releases/latest"); err != nil {
return fmt.Errorf("failed to get latest version of the Swagger UI: %w", err)
}
defer resp.Body.Close()
var (
respJSON []GitHubTagsJSON
respJSON GitHubReleasesJSON
respRaw []byte
)
@ -137,14 +137,10 @@ func codeScriptsRunE(cmd *cobra.Command, args []string) (err error) {
return fmt.Errorf("failed to get latest version of the Swagger UI: %w", err)
}
if len(respJSON) < 1 {
return fmt.Errorf("failed to get latest version of the Swagger UI: the api returned zero results")
}
if strings.HasPrefix(respJSON[0].Name, "v") {
data.VersionSwaggerUI = respJSON[0].Name[1:]
if strings.HasPrefix(respJSON.TagName, "v") {
data.VersionSwaggerUI = respJSON.TagName[1:]
} else {
data.VersionSwaggerUI = respJSON[0].Name
data.VersionSwaggerUI = respJSON.TagName
}
fullPathScriptsGen := filepath.Join(root, pathScriptsGen)

View File

@ -108,8 +108,9 @@ func genCLIDocWriteIndex(path, name string) (err error) {
func prepend(input string) string {
now := time.Now()
pathz := strings.Split(strings.Replace(input, ".md", "", 1), "\\")
parts := strings.Split(pathz[len(pathz)-1], "_")
_, filename := filepath.Split(strings.Replace(input, ".md", "", 1))
parts := strings.Split(filename, "_")
cmd := parts[0]

View File

@ -95,7 +95,9 @@ body:
id: logs
attributes:
label: Logs (Authelia)
description: Provide complete debug logs (the template will automatically put this content in a code block)
description: |
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

View File

@ -30,6 +30,48 @@ type GitHubTagsJSON struct {
Name string `json:"name"`
}
type GitHubReleasesJSON struct {
ID int `json:"id"`
Name string `json:"name"`
TagName string `json:"tag_name"`
TargetCommitISH string `json:"target_commitish"`
NodeID string `json:"node_id"`
Draft bool `json:"draft"`
Prerelease bool `json:"prerelease"`
URL string `json:"url"`
AssetsURL string `json:"assets_url"`
UploadURL string `json:"upload_url"`
HTMLURL string `json:"html_url"`
TarballURL string `json:"tarball_url"`
ZipballURL string `json:"zipball_url"`
Assets []any `json:"assets"`
CreatedAt time.Time `json:"created_at"`
PublishedAt time.Time `json:"published_at"`
Author GitHubAuthorJSON `json:"author"`
Body string `json:"body"`
}
type GitHubAuthorJSON struct {
ID int `json:"id"`
Login string `json:"login"`
NodeID string `json:"node_id"`
AvatarURL string `json:"avatar_url"`
GravatarID string `json:"gravatar_id"`
URL string `json:"url"`
HTMLURL string `json:"html_url"`
FollowersURL string `json:"followers_url"`
FollowingURL string `json:"following_url"`
GistsURL string `json:"gists_url"`
StarredURL string `json:"starred_url"`
SubscriptionsURL string `json:"subscriptions_url"`
OrganizationsURL string `json:"organizations_url"`
ReposURL string `json:"repos_url"`
EventsURL string `json:"events_url"`
ReceivedEventsURL string `json:"received_events_url"`
Type string `json:"type"`
SiteAdmin bool `json:"site_admin"`
}
// DocsDataMisc represents the docs misc data schema.
type DocsDataMisc struct {
CSP TemplateCSP `json:"csp"`

View File

@ -64,7 +64,7 @@ func cmdBootstrapRun(_ *cobra.Command, _ []string) {
fmt.Println()
bootstrapPrintln("Run 'authelia-scripts suites setup Standalone' to start Authelia and visit https://home.example.com:8080.")
bootstrapPrintln("More details at https://github.com/authelia/authelia/blob/master/docs/getting-started.md")
bootstrapPrintln("More details at https://www.authelia.com/contributing/development/build-and-test/")
}
var hostEntries = []HostEntry{

View File

@ -7,5 +7,5 @@
package cmd
const (
versionSwaggerUI = "4.15.5"
versionSwaggerUI = "4.18.1"
)

View File

@ -1,43 +0,0 @@
// +build coverage
package main
import (
"os"
"os/signal"
"strings"
"syscall"
"testing"
)
func TestCoverage(t *testing.T) {
var (
args []string
)
for _, arg := range os.Args {
switch {
case strings.HasPrefix(arg, "COVERAGE"):
case strings.HasPrefix(arg, "-test"):
default:
args = append(args, arg)
}
}
waitCh := make(chan int, 1)
os.Args = args
go func() {
main()
close(waitCh)
}()
signalCh := make(chan os.Signal, 1)
signal.Notify(signalCh, syscall.SIGINT, syscall.SIGQUIT, syscall.SIGTERM, syscall.SIGHUP)
select {
case <-signalCh:
return
case <-waitCh:
return
}
}

View File

@ -426,7 +426,7 @@ authentication_backend:
## changed once attributed to a user otherwise it would break the configuration for that user. Technically,
## non-unique attributes like 'mail' can also be used but we don't recommend using them, we instead advise to use
## a filter to perform alternative lookups and the attributes mentioned above (sAMAccountName and uid) to
## follow https://www.ietf.org/rfc/rfc2307.txt.
## follow https://datatracker.ietf.org/doc/html/rfc2307.
# username_attribute: uid
## The additional_users_dn is prefixed to base_dn and delimited by a comma when searching for users.

View File

@ -62,7 +62,12 @@
url = "/code-of-conduct"
weight = 30
[[footer]]
name = "About"
url = "/information/about"
weight = 40
[[footer]]
name = "Contact"
url = "/information/contact"
weight = 40
weight = 50

View File

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

View File

@ -1 +0,0 @@
canonifyURLs = false

View File

@ -1,2 +1 @@
canonifyURLs = false
baseurl = "https://authelia-staging.netlify.app/"

View File

@ -256,8 +256,8 @@ truncation that [Bcrypt] does. It is not supported by many other systems.*
Controls the hashing cost when hashing passwords using [Bcrypt].
[Argon2]: https://www.rfc-editor.org/rfc/rfc9106.html
[Argon2]: https://datatracker.ietf.org/doc/html/rfc9106
[Scrypt]: https://en.wikipedia.org/wiki/Scrypt
[PBKDF2]: https://www.ietf.org/rfc/rfc2898.html
[PBKDF2]: https://datatracker.ietf.org/doc/html/rfc2898
[SHA2 Crypt]: https://www.akkadia.org/drepper/SHA-crypt.txt
[Bcrypt]: https://en.wikipedia.org/wiki/Bcrypt

View File

@ -316,4 +316,4 @@ for your users.
[username attribute]: #usernameattribute
[TechNet wiki]: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx
[RFC2307]: https://www.rfc-editor.org/rfc/rfc2307.html
[RFC2307]: https://datatracker.ietf.org/doc/html/rfc2307

View File

@ -119,7 +119,7 @@ identity_providers:
clients:
- id: myapp
description: My Application
secret: '$plaintext$this_is_a_secret'
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
sector_identifier: ''
public: false
authorization_policy: two_factor
@ -170,9 +170,9 @@ encoded PEM format used to sign/encrypt the [OpenID Connect 1.0] [JWT]'s. When c
JSON key's in the JWKs [Discoverable Endpoint](../../integration/openid-connect/introduction.md#discoverable-endpoints)
as per [RFC7517].
[RFC7517]: https://www.rfc-editor.org/rfc/rfc7517
[x5c]: https://www.rfc-editor.org/rfc/rfc7517#section-4.7
[x5t]: https://www.rfc-editor.org/rfc/rfc7517#section-4.8
[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
@ -251,7 +251,7 @@ this value.
{{< confkey type="string" default="public_clients_only" required="no" >}}
[Proof Key for Code Exchange](https://www.rfc-editor.org/rfc/rfc7636.html) enforcement policy: if specified, must be
[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
@ -272,6 +272,23 @@ 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
@ -285,6 +302,7 @@ A list of endpoints to configure with cross-origin resource sharing headers. It
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
@ -402,9 +420,6 @@ This enables the public client type for this client. This is for clients that ar
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.
In addition to the standard rules for redirect URIs, public clients can use the `urn:ietf:wg:oauth:2.0:oob` redirect
URI.
#### redirect_uris
{{< confkey type="list(string)" required="yes" >}}
@ -420,7 +435,6 @@ their redirect URIs are as follows:
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`.
4. The client can ignore rule 3 and use `urn:ietf:wg:oauth:2.0:oob` if it is a [public](#public) client type.
#### audience
@ -434,30 +448,41 @@ A list of audiences this client is allowed to request.
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 want to use with Authelia will most-likely provide you with the scopes to allow.
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="refresh_token, authorization_code" required="no" >}}
A list of grant types this client can return. *It is recommended that this isn't configured at this time unless you
know what you're doing*. Valid options are: `implicit`, `refresh_token`, `authorization_code`, `password`,
`client_credentials`.
*__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" >}}
A list of response types this client can return. *It is recommended that this isn't configured at this time unless you
know what you're doing*. Valid options are: `code`, `code id_token`, `id_token`, `token id_token`, `token`,
`token id_token code`.
*__Important Note:__ It is recommended that this isn't configured at this time unless you know what you're doing.*
A list of response types this client supports.
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, fragment" required="no" >}}
A list of response modes this client can return. It is recommended that this isn't configured at this time unless you
know what you're doing. Potential values are `form_post`, `query`, and `fragment`.
*__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.
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.
#### authorization_policy
@ -465,6 +490,12 @@ know what you're doing. Potential values are `form_post`, `query`, and `fragment
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" >}}
@ -495,14 +526,18 @@ more information.
{{< 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 public clients 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. *__Note:__* this option is not technically part of the specification. |
| pre-configured | Allows the end-user to remember their consent for the [pre_configured_consent_duration]. |
| 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
@ -530,12 +565,13 @@ To integrate Authelia's [OpenID Connect 1.0] implementation with a relying party
[token lifespan]: https://docs.apigee.com/api-platform/antipatterns/oauth-long-expiration
[OpenID Connect 1.0]: https://openid.net/connect/
[JWT]: https://www.rfc-editor.org/rfc/rfc7519.html
[RFC6234]: https://www.rfc-editor.org/rfc/rfc6234.html
[RFC4648]: https://www.rfc-editor.org/rfc/rfc4648.html
[RFC7468]: https://www.rfc-editor.org/rfc/rfc7468.html
[RFC6749 Section 2.1]: https://www.rfc-editor.org/rfc/rfc6749.html#section-2.1
[PKCE]: https://www.rfc-editor.org/rfc/rfc7636.html
[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

@ -75,7 +75,8 @@ level to `debug` or `trace` this will generate large amount of log entries. Admi
they rotate and/or truncate the logs over time to prevent significant long-term disk usage.
If you include the value `%d` in the filename it will replace this value with a date time indicative of the time
the logger was initialized using `2006-02-01T150405Z` as the format.
the logger was initialized using [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339) as the format which is
represented as `2006-01-02T15:04:05Z07:00` in go.
#### File Path Examples

View File

@ -164,7 +164,7 @@ characters and the user password is changed to this value.
{{< confkey type="string" required="yes" >}}
The sender is used to construct both the SMTP command `MAIL FROM` and to add the `FROM` header. This address must be
in [RFC5322](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.4) format. This means it must one of two formats:
in [RFC5322](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4) format. This means it must one of two formats:
* jsmith@domain.com
* John Smith <jsmith@domain.com>

View File

@ -35,10 +35,18 @@ The way this format works is you can either configure an integer or a string in
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:
- all spaces
- leading zeros
While you can use multiple of these blocks in combination, we suggest keeping it simple and use a single value.
### Unit Legend
#### Short Units
These values have been available for a long time.
| Unit | Associated Letter |
|:-------:|:-----------------:|
| Years | y |
@ -49,6 +57,21 @@ While you can use multiple of these blocks in combination, we suggest keeping it
| Minutes | m |
| Seconds | s |
#### Long Units
These values are more human readable but have only been available since v4.38.0.
| 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` |
### Examples
| Desired Value | Configuration Examples |
@ -154,7 +177,7 @@ The value must be one or more certificates encoded in the DER base64 ([RFC4648])
### private_key
{{< confkey type="string" required="yes" >}}
{{< confkey type="string" required="no" >}}
*__Important Note:__ This can also be defined using a [secret](../methods/secrets.md) which is __strongly recommended__
especially for containerized deployments.*
@ -163,6 +186,8 @@ The private key to be used with the [certificate_chain](#certificatechain) for m
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
### read

View File

@ -172,5 +172,5 @@ at least a minimal configuration that has the storage backend connection details
See the [CLI Documentation](../../reference/cli/authelia/authelia_storage_user_totp_export.md) for methods to perform
exports.
[RFC4226]: https://www.rfc-editor.org/rfc/rfc4226.html
[RFC6238]: https://www.rfc-editor.org/rfc/rfc6238.html
[RFC4226]: https://datatracker.ietf.org/doc/html/rfc4226
[RFC6238]: https://datatracker.ietf.org/doc/html/rfc6238

View File

@ -588,8 +588,8 @@ The match type `Equals` matches if the value extracted from the pattern is equal
match value is a list/slice).
The regex groups are case-insensitive due to the fact that the regex groups are used in domain criteria and domain names
should not be compared in a case-sensitive way as per the [RFC4343](https://www.rfc-editor.org/rfc/rfc4343.html)
abstract and [RFC3986 Section 3.2.2](https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2).
should not be compared in a case-sensitive way as per the [RFC4343](https://datatracker.ietf.org/doc/html/rfc4343)
abstract and [RFC3986 Section 3.2.2](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2).
We do not currently apply any other normalization to usernames or groups when matching these groups. As such it's
generally *__not recommended__* to use these patterns with usernames or groups which contain characters that are not
@ -664,6 +664,6 @@ access_control:
policy: bypass
```
[RFC7231]: https://www.rfc-editor.org/rfc/rfc7231.html
[RFC5789]: https://www.rfc-editor.org/rfc/rfc5789.html
[RFC4918]: https://www.rfc-editor.org/rfc/rfc4918.html
[RFC7231]: https://datatracker.ietf.org/doc/html/rfc7231
[RFC5789]: https://datatracker.ietf.org/doc/html/rfc5789
[RFC4918]: https://datatracker.ietf.org/doc/html/rfc4918

View File

@ -137,11 +137,12 @@ cookies for this domain.
For example if Authelia is accessible via the URL `https://auth.example.com` the domain should be either
`auth.example.com` or `example.com`.
Please note most good DynamicDNS solutions fall into a specially protected group of domains and browsers do not allow
you to write cookies for the root domain. i.e. if you have been assigned `john.duckdns.org` you can't use `duckdns.org`
for the domain value as browsers will not allow `john.duckdns.org` to read or write cookies for `duckdns.org`.
The value must not match a domain on the [Public Suffix List](https://publicsuffix.org/list/) as browsers do not allow
websites to write cookies for these domains. This includes most Dynamic DNS services such as `duckdns.org`. You should
use your domain instead of `duckdns.org` for this value, for example `example.duckdns.org`.
Consequently, if you have `john.duckdns.org` and `mary.duckdns.org` you cannot share cookies between these domains.
Consequently, if you have `example.duckdns.org` and `example-auth.duckdns.org` you cannot share cookies between these
domains.
#### authelia_url

View File

@ -36,3 +36,4 @@ this instance if you wanted to downgrade to pre1 you would need to use an Authel
| 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 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 |

View File

@ -94,6 +94,49 @@ authelia-scripts suites test Standalone
The suite will be spawned, tests will be run and then the suite will be torn down automatically.
## Manually Building
### Binary
If you want to manually build the binary from source you will require the open source software described in the
[Development Environment](./environment.md#setup) documentation. Then you can follow the below steps on Linux (you may
have to adapt them on other systems).
Clone the Repository:
```bash
git clone https://github.com/authelia/authelia.git
```
Download the Dependencies:
```bash
cd authelia && go mod download
cd web && pnpm install
cd ..
```
Build the Web Frontend:
```bash
cd web && pnpm build
cd ..
```
Build the Binary (with debug symbols):
```bash
CGO_ENABLED=1 CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-strong" CGO_LDFLAGS="-Wl,-z,relro,-z,now" \
go build -ldflags "-linkmode=external" -trimpath -buildmode=pie -o authelia ./cmd/authelia
```
Build the Binary (without debug symbols):
```bash
CGO_ENABLED=1 CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-strong" CGO_LDFLAGS="-Wl,-z,relro,-z,now" \
go build -ldflags "-linkmode=external -s -w" -trimpath -buildmode=pie -o authelia ./cmd/authelia
```
[suites]: ./integration-suites.md
[React]: https://reactjs.org/
[go]: https://go.dev/dl/

View File

@ -21,7 +21,7 @@ In order to build and contribute to __Authelia__, you need to make sure the foll
* General:
* [git]
* Backend Development:
* [go] *(v1.19 or greater)*
* [go] *(v1.20 or greater)*
* [gcc]
* Frontend Development
* [Node.js] *(v18 or greater)*

View File

@ -0,0 +1,53 @@
---
title: "Accessibility"
description: "Authelia Development Accessibility Guidelines"
lead: "This section covers the accessibility guidelines we aim to respect during development."
date: 2023-03-06T20:17:57+11:00
draft: false
images: []
menu:
contributing:
parent: "guidelines"
weight: 350
toc: true
---
## Backend
There are no specific guidelines for backend accessibility other than ensuring there are reasonable logging and this is
extremely subjective.
## Frontend
### Translations
We aim to ensure as much of the web frontend information displayed to users is translated by default. This allows for
both automatic and manual translations by the community to be contributed to the code base. In addition it allows for
admins to locally override these values.
### Responsive Design
We aim to make the web frontend responsive to multiple screen resolutions. There are a few guidelines which we aim to
abide by:
- The available space is utilized efficiently in order to avoid scrolling where possible.
- The user only has to scroll in one direction to view available information. This direction should always be
vertically.
Recommendations on resolutions which are common:
- Desktop/Laptop:
1. 1920x1080
2. 1366x768
3. 2560x1440
4. 1280x720
- Tablet Devices (With Touch and Landscape):
1. 768x1024
2. 810x1080
3. 800x1280
- Mobile Devices (With Touch and Landscape):
1. 360x800
2. 390x844
3. 414x896
4. 412x915

View File

@ -19,3 +19,12 @@ those which are automated and those which are not in this section.
While it's expected that people aim to follow all of these guidelines we understand that there are logical exceptions to
all guidelines and if it makes sense we're likely to agree with you. So if you find a situation where it doesn't make
sense to follow one just let us know your reasoning when you make a PR if it's not obvious.
## General Guidelines
Some general guidelines include:
- It's recommended people wishing to contribute discuss their intended changes prior to contributing
- This helps avoid people doubling up on contributions
- This helps avoid conflicts between contributions
- This helps avoid contributors wasting their percussion time in a contribution that may not be accepted

View File

@ -31,3 +31,32 @@ the [master] branch.
Every [Pull Request] will undergo a formal review process. This process is heavily complicated if you rewrite history
and/or perform a force push, especially after a maintainer has started a review. As such we request that any action that
you merge `origin/master` into your branch to synchronize your commit after the initial review and any other action that
rewrites history.
### Requirements
The following requirements must be met for a pull request to be accepted. This list also acts as a checklist for
maintainers in their review process.
- The changes must be [documented](../prologue/documentation-contributions.md) if they add or change behaviour
- The changes must meet the following guidelines:
- [General](introduction.md#general-guidelines)
- [Commit Message](commit-message.md)
- [Database Schema](database-schema.md)
- [Documentation](documentation.md)
- [Testing](testing.md)
- [Accessibility](accessibiliy.md)
- [Style](style.md)
- The changes adhere to all of the relevant linting and quality testing automations
- The pull request closes related issues by mentioning them appropriately
- The contribution adhere to the security by design principles by:
- Setting secure defaults
- Disallows critically insecure settings
- Requires explicit awareness by users that specific settings may reduce security
- Potential future items:
- Contribution includes DCO
- Contribution includes REUSE-compliance requirements
[Pull Request]: https://github.com/authelia/authelia/pulls
[master]: https://github.com/authelia/authelia/tree/master/

View File

@ -8,7 +8,7 @@ images: []
menu:
contributing:
parent: "guidelines"
weight: 320
weight: 350
toc: true
aliases:
- /docs/contributing/style-guide.html

View File

@ -0,0 +1,27 @@
---
title: "Testing"
description: "Authelia Development Testing Guidelines"
lead: "This section covers the testing guidelines."
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
menu:
contributing:
parent: "guidelines"
weight: 320
toc: true
---
The following outlines the specific requirements we have for testing the Authelia code contributions.
- While we aim for 100% coverage on changes and additions, we do not enforce this where it doesn't make practical sense:
- A test which just marks a line as tested is not necessarily an effectual test
- Sometimes there is limited ways in which tests can be performed and the limitation makes the test ineffectual
- Tests should be named to reflect what they testing for and which part of the code they are testing
- It's required for bug fixes that contributors create a test that fails prior to and passes
subsequent to the fix being applied, this test must be included in the contribution, excluding this test will likely
result in the fix being rejected unless explicitly agreed and advised otherwise by the
[core team](../../information/about.md#core-team)
- It's strongly encouraged for features that contributors create have as much testing as is reasonable i.e. any line
that can be tested should be tested, if the line can't be tested generally this is an indication a refactor may be
required

View File

@ -44,40 +44,6 @@ We are currently directly looking for someone to sponsor:
* [Security Audit](../../policies/security.md#help-wanted)
### Balto
Our [apt repository](https://apt.authelia.com) is hosted thanks to [Balto](https://www.getbalto.com/?from=Authelia).
{{< figure src="/images/logos/balto.svg" alt="Balto" width="193" style="padding-right: 10px" ignoreStaticImages="false" >}}
### Buildkite
Our [continuous integration and continuous deployment pipelines](https://buildkite.com/authelia/?from=Authelia) are hosted by
[Buildkite](https://buildkite.com/features?from=Authelia).
### Crowdin
Our [localization platform](https://translate.authelia.com) is hosted by [Crowdin](https://crowdin.com/?from=Authelia).
### JetBrains
Our development IDE's are provided by [JetBrains](https://www.jetbrains.com/?from=Authelia).
{{< figure src="/images/logos/jetbrains.svg" alt="JetBrains" width="50" style="padding-right: 10px" ignoreStaticImages="false" >}}
### Microsoft
Our pipeline agents which we rely on for productivity are hosted on [Azure](https://azure.microsoft.com/?from=Authelia)
and our [git repositories](https://github.com/authelia) are hosted on [GitHub](https://github.com/?from=Authela)
which are both [Microsoft](https://www.microsoft.com/?from=Authelia) products.
{{< figure src="/images/logos/microsoft.svg" alt="Microsoft" width="234.45" style="padding-right: 10px" ignoreStaticImages="false" >}}
{{< figure src="/images/logos/azure.svg" alt="Azure" width="173.55" style="padding-right: 10px" ignoreStaticImages="false" >}}
### Netlify
Our [website and documentation](https://www.authelia.com) are built and hosted by
[Netlify](https://www.netlify.com/?from=Authelia).
To see a list of our sponsors please see the [sponsors section](../../information/about.md#sponsors) on the about page.
[Open Collective]: https://opencollective.com/authelia-sponsors

View File

@ -0,0 +1,8 @@
---
title: "Amir Zarrinkafsh"
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
---
{{< profile-details name="amir-zarrinkafsh" >}}

View File

@ -0,0 +1,8 @@
---
title: "Clément Michaud"
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
---
{{< profile-details name="clement-michaud" >}}

View File

@ -1,15 +1,8 @@
---
title: "James Elliott"
description: "Authelia Core Team"
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
---
*__Authelia Core Team Member.__*
__GitHub:__ [james-d-elliott](https://github.com/james-d-elliott)
__Email:__ [james.elliott@authelia.com](mailto:james.elliott@authelia.com)
__Matrix:__ [@james:authelia.com](https://matrix.to/#/@james:authelia.com) __Discord:__ [James#6549](https://discord.com/users/209869584814047232/)
{{< profile-details name="james-elliott" >}}

View File

@ -0,0 +1,8 @@
---
title: "Manuel Nuñez"
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
---
{{< profile-details name="manuel-nunez" >}}

View File

@ -0,0 +1,104 @@
---
title: "About"
description: "About Authelia and the Authelia Team"
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
aliases:
- /about
- /about.html
---
## What is Authelia?
Authelia is a project with several open source developers who contribute to the project in their free time. We are not
a company or another type of incorporated entity, and do not have any monetization model. Individuals and Organizations
are free to contribute [financially](../contributing/prologue/financial.md) or with their time to the
[documentation](../contributing/prologue/documentation-contributions.md) or
[code base](../contributing/development/introduction.md).
## Teams
The following section describes the various teams within the Authelia project.
### Core Team
{{% profile-team name="core" %}}
### Maintainers Team
{{% profile-team name="maintainers" %}}
## Sponsors
Authelia is sponsored by the organizations listed below. The organizations below sponsor us completely voluntarily
and do not expect anything additional other than us mentioning them or having a code of conduct, and some do not even
require either of those things.
Please see the [sponsorship section](../contributing/prologue/financial.md#sponsorship) of the financial contributing
page for more information on how to become a sponsor.
### Balto
Our [apt repository](https://apt.authelia.com) is hosted thanks to [Balto](https://www.getbalto.com/?from=Authelia).
{{< figure src="/images/logos/balto.svg" alt="Balto" width="193" style="padding-right: 10px" ignoreStaticImages="false" >}}
### Buildkite
Our [continuous integration and continuous deployment pipelines](https://buildkite.com/authelia/?from=Authelia) are hosted by
[Buildkite](https://buildkite.com/features?from=Authelia).
### Crowdin
Our [localization platform](https://translate.authelia.com) is hosted by [Crowdin](https://crowdin.com/?from=Authelia).
### JetBrains
Our development IDE's are provided by [JetBrains](https://www.jetbrains.com/?from=Authelia).
{{< figure src="/images/logos/jetbrains.svg" alt="JetBrains" width="50" style="padding-right: 10px" ignoreStaticImages="false" >}}
### Microsoft
Our pipeline agents which we rely on for productivity are hosted on [Azure](https://azure.microsoft.com/?from=Authelia)
and our [git repositories](https://github.com/authelia) are hosted on [GitHub](https://github.com/?from=Authela)
which are both [Microsoft](https://www.microsoft.com/?from=Authelia) products.
{{< figure src="/images/logos/microsoft.svg" alt="Microsoft" width="234.45" style="padding-right: 10px" ignoreStaticImages="false" >}}
{{< figure src="/images/logos/azure.svg" alt="Azure" width="173.55" style="padding-right: 10px" ignoreStaticImages="false" >}}
### Netlify
Our [website and documentation](https://www.authelia.com) are built and hosted by
[Netlify](https://www.netlify.com/?from=Authelia).
[Open Collective]: https://opencollective.com/authelia-sponsors
## Governance and Affiliations
Authelia is free from any outside governance and is entirely governed as outlined on this page, in addition we do not
have any affiliations which have ever asked this of us.
Our affiliations with external companies will be transparently communicated in this section and the
[sponsors](#sponsors) section.
## Compliance
The following section contains various compliance related information.
### Key Individuals
There is no key individual who if they were incapacitated or unavailable would prevent future operations of the project.
All of the following areas can be reset or are otherwise accessible to all of the members of the [Core Team](#core-team):
- Private Keys
- Access Rights
- Passwords
### Bus Factor
The Authelia team has a bus factor of 3. Meaning that the project would stall if 3 team members were suddenly hit by a
bus.

View File

@ -11,15 +11,25 @@ aliases:
## Security
If you believe you have identified a security related bug with Authelia please visit the
[security policy](../policies/security.md) documentation.
If you believe you have identified a security vulnerability or security related bug with __Authelia__ please view our
[security policy](../policies/security.md).
## Individual Team Members
If you're interested in contacting an individual team member for any reason please see the [About](about.md)
informational page.
## GitHub
### Discussions
If you have a general question or want to discuss an idea that's not entirely hashed out please visit
[GitHub Discussions](https://github.com/authelia/authelia/discussions) and start a new discussion.
The [GitHub Discussions](https://github.com/authelia/authelia/discussions) forum is the correct location to discus
anything that is not a bug or feature request such as:
- Ideas about future features where it's not clear most people can use it (allows users to vote on it)
- Questions / Support Requests
- Sharing configuration or utilization ideas (i.e. show your setup) for things that are not obvious
- Any issue you're experiencing that may or may not be a bug (i.e you're unsure if it's a bug)
### Issues
@ -55,7 +65,7 @@ are bridged to the [Matrix Rooms](#matrix) with the same names providing they ex
To contact the team for anything not security related you can utilize [team@authelia.com](mailto:team@authelia.com).
For all security related matters over email please ensure you use [security@authelia.com](mailto:team@authelia.com).
For all security related matters over email please ensure you use [security@authelia.com](mailto:security@authelia.com).
[Discord]: https://discord.com/
[Matrix]: https://matrix.org/

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://guacamole.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `guacamole`
* __Client Secret:__ `guacamole_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -64,23 +57,28 @@ The following YAML configuration is an example __Authelia__
[Apache Guacamole] which will operate with the above example:
```yaml
- id: guacamole
description: Apache Guacamole
secret: '$plaintext$guacamole_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://guacamole.example.com
scopes:
- openid
- profile
- groups
- email
response_types:
- id_token
grant_types:
- implicit
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://guacamole.example.com
scopes:
- openid
- profile
- groups
- email
response_types:
- id_token
grant_types:
- implicit
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://argocd.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `argocd`
* __Client Secret:__ `argocd_client_secret`
* __Client Secret:__ `insecure_secret`
* __CLI Client ID:__ `argocd-cli`
## Configuration
@ -51,7 +44,7 @@ To configure [Argo CD] to utilize Authelia as an [OpenID Connect 1.0] Provider u
name: Authelia
issuer: https://auth.example.com
clientID: argocd
clientSecret: argocd_client_secret
clientSecret: insecure_secret
cliClientID: argocd-cli
requestedScopes:
- openid
@ -67,32 +60,37 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: argocd
description: Argo CD
secret: '$plaintext$argocd_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://argocd.example.com/auth/callback
scopes:
- openid
- groups
- email
- profile
userinfo_signing_algorithm: none
- id: argocd-cli
description: Argo CD (CLI)
public: true
authorization_policy: two_factor
redirect_uris:
- http://localhost:8085/auth/callback
scopes:
- openid
- groups
- email
- profile
- offline_access
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://argocd.example.com/auth/callback
scopes:
- openid
- groups
- email
- profile
userinfo_signing_algorithm: none
- id: argocd-cli
description: Argo CD (CLI)
public: true
authorization_policy: two_factor
redirect_uris:
- http://localhost:8085/auth/callback
scopes:
- openid
- groups
- email
- profile
- offline_access
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,13 +31,13 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://bookstack.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `bookstack`
* __Client Secret:__ `bookstack_client_secret`
* __Client Secret:__ `insecure_secret`
*__Important Note:__ [BookStack] does not properly URL encode the secret per [RFC6749 Appendix B] at the time this
article was last modified (noted at the bottom). This means you'll either have to use only alphanumeric characters for
the secret or URL encode the secret yourself.*
[RFC6749 Appendix B]: https://www.rfc-editor.org/rfc/rfc6749#appendix-B
[RFC6749 Appendix B]: https://datatracker.ietf.org/doc/html/rfc6749#appendix-B
## Configuration
@ -58,7 +51,7 @@ To configure [BookStack] to utilize Authelia as an [OpenID Connect 1.0] Provider
2. OIDC_NAME: `Authelia`
3. OIDC_DISPLAY_NAME_CLAIMS: `name`
4. OIDC_CLIENT_ID: `bookstack`
5. OIDC_CLIENT_SECRET: `bookstack_client_secret`
5. OIDC_CLIENT_SECRET: `insecure_secret`
6. OIDC_ISSUER: `https://auth.example.com`
7. OIDC_ISSUER_DISCOVER: `true`
@ -69,18 +62,23 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: bookstack
description: BookStack
secret: '$plaintext$bookstack_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://bookstack.example.com/oidc/callback
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://bookstack.example.com/oidc/callback
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -20,14 +20,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -36,13 +29,13 @@ This example makes the following assumptions:
* __Cloudflare Team Name:__ `example-team`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `cloudflare`
* __Client Secret:__ `cloudflare_client_secret`
* __Client Secret:__ `insecure_secret`
*__Important Note:__ [Cloudflare Zero Trust] does not properly URL encode the secret per [RFC6749 Appendix B] at the
time this article was last modified (noted at the bottom). This means you'll either have to use only alphanumeric
characters for the secret or URL encode the secret yourself.*
[RFC6749 Appendix B]: https://www.rfc-editor.org/rfc/rfc6749#appendix-B
[RFC6749 Appendix B]: https://datatracker.ietf.org/doc/html/rfc6749#appendix-B
## Configuration
@ -62,7 +55,7 @@ To configure [Cloudflare Zero Trust] to utilize Authelia as an [OpenID Connect 1
6. Set the following values:
1. Name: `Authelia`
2. App ID: `cloudflare`
3. Client Secret: `cloudflare_client_secret`
3. Client Secret: `insecure_secret`
4. Auth URL: `https://auth.example.com/api/oidc/authorization`
5. Token URL: `https://auth.example.com/api/oidc/token`
6. Certificate URL: `https://auth.example.com/jwks.json`
@ -77,18 +70,23 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: cloudflare
description: Cloudflare ZeroTrust
secret: '$plaintext$cloudflare_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://example-team.cloudflareaccess.com/cdn-cgi/access/callback
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://example-team.cloudflareaccess.com/cdn-cgi/access/callback
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

View File

@ -0,0 +1,101 @@
---
title: "Firezone"
description: "Integrating Firezone with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-25T13:07:02+10:00
draft: false
images: []
menu:
integration:
parent: "openid-connect"
weight: 620
toc: true
community: true
---
## Tested Versions
* [Authelia]
* [v4.37.5](https://github.com/authelia/authelia/releases/tag/v4.37.5)
* [Firezone]
* [0.7.25](https://github.com/firezone/firezone/releases/tag/0.7.25)
## Before You Begin
{{% oidc-common %}}
### Assumptions
This example makes the following assumptions:
* __Application Root URL:__ `https://firezone.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `firezone`
* __Client Secret:__ `insecure_secret`
* __Config ID (Firezone):__ `authelia`:
* This option determines the redirect URI in the format of
`https://firezone.example.com/auth/oidc/<Config ID>/callback`.
This means if you change this value you need to update the redirect URI.
## Configuration
### Application
To configure [Firezone] to utilize Authelia as an [OpenID Connect 1.0] Provider:
1. Visit your [Firezone] site
2. Sign in as an admin
3. Visit:
1. Settings
2. Security
4. In the `Single Sign-On` section, click on the `Add OpenID Connect Provider` button
5. Configure:
1. Config ID: `authelia`
2. Label: `Authelia`
3. Scope: `openid email profile`
4. Client ID: `firezone`
5. Client secret: `insecure_secret`
6. Discovery Document URI: `https://auth.example.com/.well-known/openid-configuration`
7. Redirect URI (optional): `https://firezone.example.com/auth/oidc/authelia/callback`
8. Auto-create users (checkbox): `true`
{{< figure src="firezone.png" alt="Firezone" width="500" >}}
Take a look at the [See Also](#see-also) section for the cheatsheets corresponding to the sections above for their
descriptions.
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [Firezone] which
will operate with the above example:
```yaml
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
enforce_pkce: true
pkce_challenge_method: S256
redirect_uris:
- https://firezone.example.com/auth/oidc/authelia/callback
scopes:
- openid
- email
- profile
userinfo_signing_algorithm: none
```
## See Also
- [Firezone OIDC documentation](https://www.firezone.dev/docs/authenticate/oidc/)
[Authelia]: https://www.authelia.com
[Firezone]: https://www.firezone.dev
[OpenID Connect 1.0]: ../../openid-connect/introduction.md

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,11 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://gitea.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `gitea`
* __Client Secret:__ `gitea_client_secret`
* __Client Secret:__ `insecure_secret`
* __Authentication Name (Gitea):__ `authelia`:
* This option determines the redirect URI in the format of
`https://gitea.example.com/user/oauth2/<Authentication Name>/callback`.
This means if you change this value you need to update the redirect URI.
## Configuration
@ -54,7 +51,7 @@ To configure [Gitea] to utilize Authelia as an [OpenID Connect 1.0] Provider:
1. Authentication Name: `authelia`
2. OAuth2 Provider: `OpenID Connect`
3. Client ID (Key): `gitea`
4. Client Secret: `gitea_client_secret`
4. Client Secret: `insecure_secret`
5. OpenID Connect Auto Discovery URL: `https://auth.example.com/.well-known/openid-configuration`
{{< figure src="gitea.png" alt="Gitea" width="300" >}}
@ -84,25 +81,30 @@ The following YAML configuration is an example __Authelia__
will operate with the above example:
```yaml
- id: gitea
description: Gitea
secret: '$plaintext$gitea_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://gitea.example.com/user/oauth2/authelia/callback
scopes:
- openid
- email
- profile
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://gitea.example.com/user/oauth2/authelia/callback
scopes:
- openid
- email
- profile
userinfo_signing_algorithm: none
```
## See Also
- [Gitea] app.ini [Config Cheat Sheet - OpenID](https://docs.gitea.io/en-us/config-cheat-sheet/#openid-openid)
- [Gitea] app.ini [Config Cheat Sheet - Service](https://docs.gitea.io/en-us/config-cheat-sheet/#service-service)
- [Gitea] app.ini [Config Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet):
- [OpenID](https://docs.gitea.io/en-us/config-cheat-sheet/#openid-openid)
- [Service](https://docs.gitea.io/en-us/config-cheat-sheet/#service-service)
- [Authelia]: https://www.authelia.com
[Gitea]: https://gitea.io/
[OpenID Connect 1.0]: ../../openid-connect/introduction.md

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://gitlab.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `gitlab`
* __Client Secret:__ `gitlab_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -65,7 +58,7 @@ gitlab_rails['omniauth_providers'] = [
send_scope_to_token_endpoint: "false",
client_options: {
identifier: "gitlab",
secret: "gitlab_client_secret",
secret: "insecure_secret",
redirect_uri: "https://gitlab.example.com/users/auth/openid_connect/callback"
}
}
@ -80,19 +73,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: gitlab
description: GitLab
secret: '$plaintext$gitlab_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://gitlab.example.com/users/auth/openid_connect/callback
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://gitlab.example.com/users/auth/openid_connect/callback
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://grafana.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `grafana`
* __Client Secret:__ `grafana_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -58,7 +51,7 @@ enabled = true
name = Authelia
icon = signin
client_id = grafana
client_secret = grafana_client_secret
client_secret = insecure_secret
scopes = openid profile email groups
empty_scopes = false
auth_url = https://auth.example.com/api/oidc/authorization
@ -80,7 +73,7 @@ Configure the following environment variables:
| GF_AUTH_GENERIC_OAUTH_ENABLED | true |
| GF_AUTH_GENERIC_OAUTH_NAME | Authelia |
| GF_AUTH_GENERIC_OAUTH_CLIENT_ID | grafana |
| GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET | grafana_client_secret |
| GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET | insecure_secret |
| GF_AUTH_GENERIC_OAUTH_SCOPES | openid profile email groups |
| GF_AUTH_GENERIC_OAUTH_EMPTY_SCOPES | false |
| GF_AUTH_GENERIC_OAUTH_AUTH_URL | https://auth.example.com/api/oidc/authorization |
@ -98,19 +91,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: grafana
description: Grafana
secret: '$plaintext$grafana_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://grafana.example.com/login/generic_oauth
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://grafana.example.com/login/generic_oauth
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://harbor.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `harbor`
* __Client Secret:__ `harbor_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -54,7 +47,7 @@ To configure [Harbor] to utilize Authelia as an [OpenID Connect 1.0] Provider:
1. OIDC Provider Name: `Authelia`
2. OIDC Provider Endpoint: `https://auth.example.com`
3. OIDC Client ID: `harbor`
4. OIDC Client Secret: `harbor_client_secret`
4. OIDC Client Secret: `insecure_secret`
5. Group Claim Name: `groups`
6. OIDC Scope: `openid,profile,email,groups`
7. For OIDC Admin Group you can specify a group name that matches your authentication backend.
@ -71,19 +64,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: harbor
description: Harbor
secret: '$plaintext$harbor_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://harbor.example.com/c/oidc/callback
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://harbor.example.com/c/oidc/callback
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://vault.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `vault`
* __Client Secret:__ `vault_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -54,20 +47,25 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: vault
description: HashiCorp Vault
secret: '$plaintext$vault_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://vault.example.com/oidc/callback
- https://vault.example.com/ui/vault/auth/oidc/oidc/callback
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://vault.example.com/oidc/callback
- https://vault.example.com/ui/vault/auth/oidc/oidc/callback
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -87,6 +87,68 @@ 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 |
## Parameters
The following section describes advanced parameters which can be used in various endpoints as well as their related
configuration options.
### Grant Types
The following describes the various [OAuth 2.0] and [OpenID Connect 1.0] grant types and their support level. The value
field is both the required value for the `grant_type` parameter in the authorization request and the `grant_types`
configuration option.
| Grant Type | Supported | Value | Notes |
|:-----------------------------------------------:|:---------:|:----------------------------------------------:|:-------------------------------------------------------------------:|
| [OAuth 2.0 Authorization Code] | Yes | `authorization_code` | |
| [OAuth 2.0 Resource Owner Password Credentials] | No | `password` | This Grant Type has been deprecated and should not normally be used |
| [OAuth 2.0 Client Credentials] | Yes | `client_credentials` | |
| [OAuth 2.0 Implicit] | Yes | `implicit` | This Grant Type has been deprecated and should not normally be used |
| [OAuth 2.0 Refresh Token] | Yes | `refresh_token` | |
| [OAuth 2.0 Device Code] | No | `urn:ietf:params:oauth:grant-type:device_code` | |
|
[OAuth 2.0 Authorization Code]: https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1
[OAuth 2.0 Implicit]: https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.2
[OAuth 2.0 Resource Owner Password Credentials]: https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.3
[OAuth 2.0 Client Credentials]: https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.4
[OAuth 2.0 Refresh Token]: https://datatracker.ietf.org/doc/html/rfc6749#section-1.5
[OAuth 2.0 Device Code]: https://datatracker.ietf.org/doc/html/rfc8628#section-3.4
### Response Types
The following describes the supported response types. See the [OAuth 2.0 Multiple Response Type Encoding Practices] for
more technical information.
| Flow Type | Values |
|:-------------------------:|:---------------------:|
| [Authorization Code Flow] | `code` |
| [Implicit Flow] | `token id_token` |
| [Implicit Flow] | `id_token` |
| [Implicit Flow] | `token` |
| [Hybrid Flow] | `code token` |
| [Hybrid Flow] | `code id_token` |
| [Hybrid Flow] | `code token id_token` |
[Authorization Code Flow]: https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
[Implicit Flow]: https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth
[Hybrid Flow]: https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth
[OAuth 2.0 Multiple Response Type Encoding Practices]: https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
### Response Modes
The following describes the supported response modes. See the [OAuth 2.0 Multiple Response Type Encoding Practices] for
more technical information.
| Name | Value |
|:---------------------:|:-----------:|
| Query String | `query` |
| Fragment | `fragment` |
| [OAuth 2.0 Form Post] | `form_post` |
[OAuth 2.0 Form Post]: https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
## Authentication Method References
Authelia currently supports adding the `amr` [Claim] to the [ID Token] utilizing the [RFC8176] Authentication Method
@ -147,14 +209,71 @@ These endpoints can be utilized to discover other endpoints and metadata about t
These endpoints implement OpenID Connect elements.
| Endpoint | Path | Discovery Attribute |
|:-------------------:|:-----------------------------------------------:|:----------------------:|
| [JSON Web Key Sets] | https://auth.example.com/jwks.json | jwks_uri |
| [Authorization] | https://auth.example.com/api/oidc/authorization | authorization_endpoint |
| [Token] | https://auth.example.com/api/oidc/token | token_endpoint |
| [UserInfo] | https://auth.example.com/api/oidc/userinfo | userinfo_endpoint |
| [Introspection] | https://auth.example.com/api/oidc/introspection | introspection_endpoint |
| [Revocation] | https://auth.example.com/api/oidc/revocation | revocation_endpoint |
| Endpoint | Path | Discovery Attribute |
|:-------------------------------:|:--------------------------------------------------------------:|:-------------------------------------:|
| [JSON Web Key Set] | https://auth.example.com/jwks.json | jwks_uri |
| [Authorization] | https://auth.example.com/api/oidc/authorization | authorization_endpoint |
| [Pushed Authorization Requests] | https://auth.example.com/api/oidc/pushed-authorization-request | pushed_authorization_request_endpoint |
| [Token] | https://auth.example.com/api/oidc/token | token_endpoint |
| [UserInfo] | https://auth.example.com/api/oidc/userinfo | userinfo_endpoint |
| [Introspection] | https://auth.example.com/api/oidc/introspection | introspection_endpoint |
| [Revocation] | https://auth.example.com/api/oidc/revocation | revocation_endpoint |
## Security
The following information covers some security topics some users may wish to be familiar with.
#### Pushed Authorization Requests Endpoint
The [Pushed Authorization Requests] endpoint is discussed in depth in [RFC9126] as well as in the
[OAuth 2.0 Pushed Authorization Requests](https://oauth.net/2/pushed-authorization-requests/) documentation.
Essentially it's a special endpoint that takes the same parameters as the [Authorization] endpoint (including
[Proof Key Code Exchange](#proof-key-code-exchange)) with a few caveats:
1. The same [Client Authentication] mechanism required by the [Token] endpoint **MUST** be used.
2. The request **MUST** use the [HTTP POST method].
3. The request **MUST** use the `application/x-www-form-urlencoded` content type (i.e. the parameters **MUST** be in the
body, not the URI).
4. The request **MUST** occur over the back-channel.
The response of this endpoint is a JSON Object with two key-value pairs:
- `request_uri`
- `expires_in`
The `expires_in` indicates how long the `request_uri` is valid for. The `request_uri` is used as a parameter to the
[Authorization] endpoint instead of the standard parameters (as the `request_uri` parameter).
The advantages of this approach are as follows:
1. [Pushed Authorization Requests] cannot be created or influenced by any party other than the Relying Party (client).
2. Since you can force all [Authorization] requests to be initiated via [Pushed Authorization Requests] you drastically
improve the authorization flows resistance to phishing attacks (this can be done globally or on a per-client basis).
3. Since the [Pushed Authorization Requests] endpoint requires all of the same [Client Authentication] mechanisms as the
[Token] endpoint:
1. Clients using the confidential [Client Type] can't have [Pushed Authorization Requests] generated by parties who do not
have the credentials.
2. Clients using the public [Client Type] and utilizing [Proof Key Code Exchange](#proof-key-code-exchange) never
transmit the verifier over any front-channel making even the `plain` challenge method relatively secure.
#### Proof Key Code Exchange
The [Proof Key Code Exchange] mechanism is discussed in depth in [RFC7636] as well as in the
[OAuth 2.0 Proof Key Code Exchange](https://oauth.net/2/pkce/) documentation.
Essentially a random opaque value is generated by the Relying Party and optionally (but recommended) passed through a
SHA256 hash. The original value is saved by the Relying Party, and the hashed value is sent in the [Authorization]
request in the `code_verifier` parameter with the `code_challenge_method` set to `S256` (or `plain` using a bad practice
of not hashing the opaque value).
When the Relying Party requests the token from the [Token] endpoint, they must include the `code_verifier` parameter
again (in the body), but this time they send the value without it being hashed.
The advantages of this approach are as follows:
1. Provided the value was hashed it's certain that the Relying Party which generated the authorization request is the
same party as the one requesting the token or is permitted by the Relying Party to make this request.
2. Even when using the public [Client Type] there is a form of authentication on the [Token] endpoint.
[ID Token]: https://openid.net/specs/openid-connect-core-1_0.html#IDToken
[Access Token]: https://datatracker.ietf.org/doc/html/rfc6749#section-1.4
@ -166,16 +285,25 @@ These endpoints implement OpenID Connect elements.
[OpenID Connect 1.0]: https://openid.net/connect/
[OpenID Connect Discovery]: https://openid.net/specs/openid-connect-discovery-1_0.html
[OAuth 2.0 Authorization Server Metadata]: https://www.rfc-editor.org/rfc/rfc8414.html
[OAuth 2.0 Authorization Server Metadata]: https://datatracker.ietf.org/doc/html/rfc8414
[JSON Web Key Sets]: https://www.rfc-editor.org/rfc/rfc7517.html#section-5
[JSON Web Key Set]: https://datatracker.ietf.org/doc/html/rfc7517#section-5
[Authorization]: https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint
[Pushed Authorization Requests]: https://datatracker.ietf.org/doc/html/rfc9126
[Token]: https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
[UserInfo]: https://openid.net/specs/openid-connect-core-1_0.html#UserInfo
[Introspection]: https://www.rfc-editor.org/rfc/rfc7662.html
[Revocation]: https://www.rfc-editor.org/rfc/rfc7009.html
[Introspection]: https://datatracker.ietf.org/doc/html/rfc7662
[Revocation]: https://datatracker.ietf.org/doc/html/rfc7009
[Proof Key Code Exchange]: https://www.rfc-editor.org/rfc/rfc7636.html
[RFC8176]: https://www.rfc-editor.org/rfc/rfc8176.html
[RFC4122]: https://www.rfc-editor.org/rfc/rfc4122.html
[Subject Identifier Types]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[Client Authentication]: https://datatracker.ietf.org/doc/html/rfc6749#section-2.3
[Client Type]: https://oauth.net/2/client-types/
[HTTP POST method]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST
[Proof Key Code Exchange]: #proof-key-code-exchange
[RFC4122]: https://datatracker.ietf.org/doc/html/rfc4122
[RFC7636]: https://datatracker.ietf.org/doc/html/rfc7636
[RFC8176]: https://datatracker.ietf.org/doc/html/rfc8176
[RFC9126]: https://datatracker.ietf.org/doc/html/rfc9126

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://komga.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `komga`
* __Client Secret:__ `komga_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -58,7 +51,7 @@ spring:
registration:
authelia:
client-id: `komga`
client-secret: `komga_client_secret`
client-secret: `insecure_secret`
client-name: Authelia
scope: openid,profile,email
authorization-grant-type: authorization_code
@ -76,20 +69,25 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: komga
description: Komga
secret: '$plaintext$komga_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://komga.example.com/login/oauth2/code/authelia
scopes:
- openid
- profile
- email
grant_types:
- authorization_code
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://komga.example.com/login/oauth2/code/authelia
scopes:
- openid
- profile
- email
grant_types:
- authorization_code
userinfo_signing_algorithm: none
```
## See Also

View File

@ -0,0 +1,96 @@
---
title: "MinIO"
description: "Integrating MinIO with the Authelia OpenID Connect Provider."
lead: ""
date: 2022-06-15T17:51:47+10:00
draft: false
images: []
menu:
integration:
parent: "openid-connect"
weight: 620
toc: true
community: true
---
## Tested Versions
* [Authelia]
* [v4.37.5](https://github.com/authelia/authelia/releases/tag/v4.37.5)
* [MinIO]
* [2023-03-13T19:46:17Z](https://github.com/minio/minio/releases/tag/RELEASE.2023-03-13T19-46-17Z)
## Before You Begin
{{% oidc-common %}}
### Assumptions
This example makes the following assumptions:
* __Application Root URL:__ `https://minio.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `minio`
* __Client Secret:__ `insecure_secret`
## Configuration
### Application
To configure [MinIO] to utilize Authelia as an [OpenID Connect 1.0] Provider:
1. Login to [MinIO]
2. On the left hand menu, go to `Identity`, then `OpenID`
3. On the top right, click `Create Configuration`
4. On the screen that appears, enter the following information:
- Name: `authelia`
- Config URL: `https://auth.example.com/.well-known/openid-configuration`
- Client ID: `minio`
- Client Secret: `insecure_secret`
- Claim Name: Leave Empty
- Display Name: `Authelia`
- Claim Prefix: `authelia`
- Scopes: `openid,profile,email`
- Redirect URI: `https://minio.example.com/oauth_callback`
- Role Policy: `readonly`
- Claim User Info: Disabled
- Redirect URI Dynamic: Disabled
5. Press `Save` at the bottom
6. Accept the offer of a server restart at the top
7. When the login screen appears again, click the `Other Authentication Methods` open, then select `Authelia` from the list.
8. Login
### Authelia
The following YAML configuration is an example __Authelia__
[client configuration](../../../configuration/identity-providers/open-id-connect.md#clients) for use with [MinIO]
which will operate with the above example:
```yaml
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://minio.example.com/apps/oidc_login/oidc
scopes:
- openid
- profile
- email
- groups
userinfo_signing_algorithm: none
```
## See Also
- [MinIO OpenID Identiy Management](https://min.io/docs/minio/linux/reference/minio-server/minio-server.html#minio-server-envvar-external-identity-management-openid)
[MinIO]: https://minio.com/
[Authelia]: https://www.authelia.com
[OpenID Connect 1.0]: ../../openid-connect/introduction.md

View File

@ -0,0 +1,114 @@
---
title: "Misago"
description: "Integrating Misago with the Authelia OpenID Connect Provider."
lead: ""
date: 2023-03-04T13:20:00+00:00
draft: false
images: []
menu:
integration:
parent: "openid-connect"
weight: 620
toc: true
community: true
---
## Tested Versions
* [Authelia](https://www.authelia.com)
* [v4.37.5](https://github.com/authelia/authelia/releases/tag/v4.37.5)
* [Misago](https://github.com/rafalp/Misago)
* [misago-image v0.29.1](https://github.com/tetricky/misago-image/releases/tag/v0.29.1)
## Before You Begin
{{% oidc-common %}}
### Assumptions
This example makes the following assumptions:
* __Application Root URL:__ `https://misago.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `misago`
* __Client Secret:__ `insecure_secret`
## Configuration
### Application
To configure [Misago] to utilize Authelia as an [OpenID Connect 1.0](https://www.authelia.com/integration/openid-connect/introduction/) Provider:
1. Sign in to the [Misago] Admin Panel
2. Visit `Settings` and click `OAuth 2`
3. Configure the Following:
1. Basic settings:
1. Provider name: `authelia`
2. Client ID: `misago`
3. Client Secret: `insecure_secret`
2. Initializing Login:
1. Login form URL: `https://auth.example.com/api/oidc/authorization`
2. Scopes: `openid profile email`
3. Retrieving access token:
1. Access token retrieval URL: `https://auth.example.com/api/oidc/token`
2. Request method: `POST`
3. JSON path to access token: `access_token`
4. Retrieving user data:
1. User data URL: `https://auth.example.com/api/oidc/userinfo`
2. Request method: `GET`
3. Access token location: `Query string`
4. Access token name: `access_token`
5. User JSON mappings:
1. User ID path: `sub`
2. User name path: `name`
3. User e-mail path: `email`
4. Save the configuration
{{< figure src="misago-step-2.png" alt="Settings" width="736" style="padding-right: 10px" >}}
{{< figure src="misago-step-3-1.png" alt="Basic Settings" width="736" style="padding-right: 10px" >}}
{{< figure src="misago-step-3-2.png" alt="Initializing Login" width="736" style="padding-right: 10px" >}}
{{< figure src="misago-step-3-3.png" alt="Retrieving access token" width="736" style="padding-right: 10px" >}}
{{< figure src="misago-step-3-4.png" alt="Retrieving user data" width="736" style="padding-right: 10px" >}}
{{< figure src="misago-step-3-5.png" alt="User JSON mappings" width="736" style="padding-right: 10px" >}}
### Authelia
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:
oidc:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- id: misago
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
scopes:
- openid
- profile
- email
redirect_uris:
- https://misago.example.com/oauth2/complete/
grant_types:
- authorization_code
response_types:
- code
response_modes:
- query
userinfo_signing_algorithm: none
```
---
## See Also
- [Misago] [OAuth 2 Client Configuration guide](https://misago-project.org/t/oauth-2-client-configuration-guide/1147/)
[Misago]: https://misago-project.org/

Binary file not shown.

After

Width:  |  Height:  |  Size: 236 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://nextcloud.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `nextcloud`
* __Client Secret:__ `nextcloud_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -55,7 +48,7 @@ $CONFIG = array (
'lost_password_link' => 'disabled',
'oidc_login_provider_url' => 'https://auth.example.com',
'oidc_login_client_id' => 'nextcloud',
'oidc_login_client_secret' => 'nextcloud_client_secret',
'oidc_login_client_secret' => 'insecure_secret',
'oidc_login_auto_redirect' => false,
'oidc_login_end_session_redirect' => false,
'oidc_login_button_text' => 'Log in with Authelia',
@ -92,19 +85,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: nextcloud
description: NextCloud
secret: '$plaintext$nextcloud_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://nextcloud.example.com/apps/oidc_login/oidc
scopes:
- openid
- profile
- email
- groups
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://nextcloud.example.com/apps/oidc_login/oidc
scopes:
- openid
- profile
- email
- groups
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://outline.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `outline`
* __Client Secret:__ `outline_client_secret`
* __Client Secret:__ `insecure_secret`
*__Important Note:__ At the time of this writing [Outline] requires the `offline_access` scope by default. Failure to include this scope will result
in an error as [Outline] will attempt to use a refresh token that is never issued.*
@ -55,7 +48,7 @@ URL=https://outline.example.com
FORCE_HTTPS=true
OIDC_CLIENT_ID=outline
OIDC_CLIENT_SECRET=outline_client_secret
OIDC_CLIENT_SECRET=insecure_secret
OIDC_AUTH_URI=https://auth.example.com/api/oidc/authorization
OIDC_TOKEN_URI=https://auth.example.com/api/oidc/token
OIDC_USERINFO_URI=https://auth.example.com/api/oidc/userinfo
@ -71,19 +64,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: outline
description: Outline
secret: '$plaintext$outline_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://outline.example.com/auth/oidc.callback
scopes:
- openid
- offline_access
- profile
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://outline.example.com/auth/oidc.callback
scopes:
- openid
- offline_access
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -24,14 +24,7 @@ aliases:
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -40,7 +33,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://portainer.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `portainer`
* __Client Secret:__ `portainer_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -55,7 +48,7 @@ To configure [Portainer] to utilize Authelia as an [OpenID Connect 1.0] Provider
2. Provider: Custom
3. Enable *Automatic User Provision* if you want users to automatically be created in [Portainer].
4. Client ID: `portainer`
5. Client Secret: `portainer_client_secret`
5. Client Secret: `insecure_secret`
6. Authorization URL: `https://auth.example.com/api/oidc/authorization`
7. Access Token URL: `https://auth.example.com/api/oidc/token`
8. Resource URL: `https://auth.example.com/api/oidc/userinfo`
@ -72,19 +65,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: portainer
description: Portainer
secret: '$plaintext$portainer_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://portainer.example.com
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://portainer.example.com
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,9 @@ aliases:
* [Proxmox]
* 7.1-10
### Common Notes
## Before You Begin
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Specific Notes
@ -43,7 +38,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://proxmox.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `proxmox`
* __Client Secret:__ `proxmox_client_secret`
* __Client Secret:__ `insecure_secret`
* __Realm__ `authelia`
## Configuration
@ -60,7 +55,7 @@ To configure [Proxmox] to utilize Authelia as an [OpenID Connect 1.0] Provider:
1. Issuer URL: `https://auth.example.com`
2. Realm: `authelia`
3. Client ID: `proxmox`
4. Client Key: `proxmox_client_secret`
4. Client Key: `insecure_secret`
5. Username Claim `preferred_username`
6. Scopes: `openid profile email`
7. Enable *Autocreate Users* if you want users to automatically be created in [Proxmox].
@ -74,18 +69,23 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: proxmox
description: Proxmox
secret: '$plaintext$proxmox_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://proxmox.example.com
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://proxmox.example.com
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://seafile.example.com`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `seafile`
* __Client Secret:__ `seafile_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -55,7 +48,7 @@ To configure [Seafile] to utilize Authelia as an [OpenID Connect 1.0] Provider:
ENABLE_OAUTH = True
OAUTH_ENABLE_INSECURE_TRANSPORT = False
OAUTH_CLIENT_ID = "seafile"
OAUTH_CLIENT_SECRET = "seafile_client_secret"
OAUTH_CLIENT_SECRET = "insecure_secret"
OAUTH_REDIRECT_URL = 'https://seafile.example.com/oauth/callback/'
OAUTH_PROVIDER_DOMAIN = 'auth.example.com'
OAUTH_AUTHORIZATION_URL = 'https://auth.example.com/api/oidc/authorization'
@ -80,18 +73,23 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: seafile
description: Seafile
secret: '$plaintext$seafile_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://seafile.example.com/oauth/callback/
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://seafile.example.com/oauth/callback/
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -34,6 +34,41 @@ using PBKDF2 which can be stored in the Authelia configuration.
### Plaintext
Authelia supports storing the plaintext secret in the configuration. This may be discontinued in the future. Plaintext
is either denoted by the `$plaintext$` prefix where everything after the prefix is the secret. In addition if the secret
does not start with the `$` character it's considered as a plaintext secret for the time being but is deprecated.
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
Connect 1.0 providers operate in this way, it's more often than not that they operating in this way in error. The
current *technical support* for this is only to prevent massive upheaval to users and give them time to migrate.
As per [RFC6819 Section 5.1.4.1.3](https://datatracker.ietf.org/doc/html/rfc6819#section-5.1.4.1.3) the secret should
only be stored by the authorization server as hashes / digests unless there is a very specific specification or protocol
that is implemented by the authorization server which requires access to the secret in the clear to operate properly in
which case the secret should be encrypted and not be stored in plaintext. The most likely long term outcome is that the
client configurations will be stored in the database with the secret both salted and peppered.
Authelia currently does not implement any of the specifications or protocols which require secrets being accessible in
the clear such as most notibly the `client_secret_jwt` grant and currently we no plans to implement any of these. As
such it's *__strongly discouraged and heavily deprecated__* and we instead recommended that users remove this from their
configuration entirely and use the [Generating Client Secrets](#generating-client-secrets) guide. At such a time as we
support one of these protocols we will very likely only allow plaintext for clients configured expressly for this
purpose i.e. a client that only allows `client_secret_jwt` and no other grants.
Plaintext is either denoted by the `$plaintext$` prefix where everything after the prefix is the secret. In addition if
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.
## Frequently Asked Questions
### 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
[Endpoint] without errors but an absence of requests made to the Token [Endpoint].
These requests can be identified by looking at the `path` field in the logs, or by messages prefixed with
`Authorization Request` indicating a request to the Authorization [Endpoint] and `Access Request` indicating a request
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.
[Endpoint]: ./introduction.md#discoverable-endpoints

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Assumptions
@ -38,7 +31,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://matrix.example.com/`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `synapse`
* __Client Secret:__ `synapse_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -56,7 +49,7 @@ oidc_providers:
discover: true
issuer: "https://auth.example.com"
client_id: "synapse"
client_secret: "synapse_client_secret"
client_secret: "insecure_secret"
scopes: ["openid", "profile", "email"]
allow_existing_users: true
user_mapping_provider:
@ -74,18 +67,23 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: synapse
description: Synapse
secret: '$plaintext$synapse_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://synapse.example.com/_synapse/client/oidc/callback
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://synapse.example.com/_synapse/client/oidc/callback
scopes:
- openid
- profile
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -22,14 +22,7 @@ community: true
## Before You Begin
### Common Notes
1. You are *__required__* to utilize a unique client id for every client.
2. The client id on this page is merely an example and you can theoretically use any alphanumeric string.
3. You *__should not__* use the client secret in this example, We *__strongly recommend__* reading the
[Generating Client Secrets] guide instead.
[Generating Client Secrets]: ../specific-information.md#generating-client-secrets
{{% oidc-common %}}
### Specific Notes
@ -43,7 +36,7 @@ This example makes the following assumptions:
* __Application Root URL:__ `https://dsm.example.com/`
* __Authelia Root URL:__ `https://auth.example.com`
* __Client ID:__ `synology-dsm`
* __Client Secret:__ `synology-dsm_client_secret`
* __Client Secret:__ `insecure_secret`
## Configuration
@ -61,7 +54,7 @@ To configure [Synology DSM] to utilize Authelia as an [OpenID Connect 1.0] Provi
* Name: `Authelia`
* Well Known URL: `https://auth.example.com/.well-known/openid-configuration`
* Application ID: `synology-dsm`
* Application Key: `synology-dsm_client_secret`
* Application Key: `insecure_secret`
* Redirect URL: `https://dsm.example.com`
* Authorisation Scope: `openid profile groups email`
* Username Claim: `preferred_username`
@ -76,19 +69,24 @@ The following YAML configuration is an example __Authelia__
which will operate with the above example:
```yaml
- id: synology-dsm
description: Synology DSM
secret: '$plaintext$synology-dsm_client_secret'
public: false
authorization_policy: two_factor
redirect_uris:
- https://dsm.example.com
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
identity_providers:
oidc:
## 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
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
public: false
authorization_policy: two_factor
redirect_uris:
- https://dsm.example.com
scopes:
- openid
- profile
- groups
- email
userinfo_signing_algorithm: none
```
## See Also

View File

@ -17,6 +17,12 @@ obviously choose a different path if you are so inclined.
## Prerequisites
The most important prerequisite that users understand that there is no single way to deploy software similar to
Authelia. We provide as much information as possible for users to configure the critical parts usually in the most
common scenarios however those using more advanced architectures are likely going to have to adapt. We can generally
help with answering less specific questions about this and it may be possible if provided adequate information more
specific questions may be answered.
### Forwarded Authentication
Forwarded Authentication is a simple per-request authorization flow that checks the metadata of a request and a session

View File

@ -63,6 +63,47 @@ to the trusted proxy list in [Caddy]:
* 192.168.0.0/16
* fc00::/7
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Implementation
[Caddy] utilizes the [ForwardAuth](../../reference/guides/proxy-authorization.md#forwardauth) Authz implementation. The
associated [Metadata](../../reference/guides/proxy-authorization.md#forwardauth-metadata) should be considered required.
The examples below assume you are using the default
[Authz Endpoints Configuration](../../configuration/miscellaneous/server-endpoints-authz.md) or one similar to the
following minimal configuration:
```yaml
server:
endpoints:
authz:
forward-auth:
implementation: ForwardAuth
```
## Configuration
Below you will find commented examples of the following configuration:
@ -81,7 +122,7 @@ support to ensure the basic example covers your use case in a secure way.
{{< details "Caddyfile" >}}
```caddyfile
## It is important to read the following document before enabling this section:
## https://www.authelia.com/integration/proxies/caddy/#forwarded-header-trust#trusted-proxies
## https://www.authelia.com/integration/proxies/caddy/#trusted-proxies
(trusted_proxy_list) {
## Uncomment & adjust the following line to configure specific ranges which should be considered as trustworthy.
# trusted_proxies 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 fc00::/7
@ -102,7 +143,7 @@ nextcloud.example.com {
## The following commented line is for configuring the Authelia URL in the proxy. We strongly suggest
## this is configured in the Session Cookies section of the Authelia configuration.
# uri /api/authz/forward-auth?authelia_url=https://auth.example.com/
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
copy_headers Authorization Proxy-Authorization Remote-User Remote-Groups Remote-Email Remote-Name
## This import needs to be included if you're relying on a trusted proxies configuration.
import trusted_proxy_list
@ -120,7 +161,7 @@ nextcloud.example.com {
{{< details "Caddyfile" >}}
```caddyfile
## It is important to read the following document before enabling this section:
## https://www.authelia.com/integration/proxies/caddy/#forwarded-header-trust#trusted-proxies
## https://www.authelia.com/integration/proxies/caddy/#trusted-proxies
(trusted_proxy_list) {
## Uncomment & adjust the following line to configure specific ranges which should be considered as trustworthy.
# trusted_proxies 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 fc00::/7
@ -141,7 +182,7 @@ example.com {
handle @nextcloud {
forward_auth authelia:9091 {
uri /api/authz/forward-auth?authelia_url=https://example.com/authelia/
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
copy_headers Authorization Proxy-Authorization Remote-User Remote-Groups Remote-Email Remote-Name
## This import needs to be included if you're relying on a trusted proxies configuration.
import trusted_proxy_list
@ -165,7 +206,7 @@ preferred in *most* situations. If you are unsure of what you're doing please do
{{< details "Caddyfile" >}}
```caddyfile
## It is important to read the following document before enabling this section:
## https://www.authelia.com/integration/proxies/caddy/#forwarded-header-trust#trusted-proxies
## https://www.authelia.com/integration/proxies/caddy/#trusted-proxies
(trusted_proxy_list) {
## Uncomment & adjust the following line to configure specific ranges which should be considered as trustworthy.
# trusted_proxies 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 fc00::/7
@ -198,10 +239,12 @@ nextcloud.example.com {
## 2. Copy the relevant headers from the auth request and provide them to the backend.
@good status 2xx
handle_response @good {
request_header Authorization {http.reverse_proxy.header.Authorization}
request_header Proxy-Authorization {http.reverse_proxy.header.Proxy-Authorization}
request_header Remote-User {http.reverse_proxy.header.Remote-User}
request_header Remote-Groups {http.reverse_proxy.header.Remote-Groups}
request_header Remote-Name {http.reverse_proxy.header.Remote-Name}
request_header Remote-Email {http.reverse_proxy.header.Remote-Email}
request_header Remote-Name {http.reverse_proxy.header.Remote-Name}
}
}

View File

@ -37,6 +37,47 @@ how you can configure multiple IP ranges. You should customize this example to f
You should only include the specific IP address ranges of the trusted proxies within your architecture and should not
trust entire subnets unless that subnet only has trusted proxies and no other services.*
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Implementation
[Envoy] utilizes the [ExtAuthz](../../reference/guides/proxy-authorization.md#extauthz) Authz implementation. The
associated [Metadata](../../reference/guides/proxy-authorization.md#extauthz-metadata) should be considered required.
The examples below assume you are using the default
[Authz Endpoints Configuration](../../configuration/miscellaneous/server-endpoints-authz.md) or one similar to the
following minimal configuration:
```yaml
server:
endpoints:
authz:
ext-authz:
implementation: ExtAuthz
```
## Configuration
Below you will find commented examples of the following configuration:
@ -168,6 +209,13 @@ static_resources:
- name: envoy.filters.http.ext_authz
typed_config:
"@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
http_service:
path_prefix: /api/authz/ext-authz/
server_uri:
@ -177,9 +225,10 @@ static_resources:
authorization_request:
allowed_headers:
patterns:
- exact: authorization
- exact: proxy-authorization
- exact: accept
- exact: cookie
- exact: proxy-authorization
headers_to_add:
- key: X-Forwarded-Proto
value: '%REQ(:SCHEME)%'
@ -207,9 +256,9 @@ static_resources:
clusters:
- name: nextcloud
connect_timeout: 0.25s
type: LOGICAL_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
type: logical_dns
dns_lookup_family: v4_only
lb_policy: round_robin
load_assignment:
cluster_name: nextcloud
endpoints:
@ -221,9 +270,9 @@ static_resources:
port_value: 80
- name: authelia
connect_timeout: 0.25s
type: LOGICAL_DNS
dns_lookup_family: V4_ONLY
lb_policy: ROUND_ROBIN
type: logical_dns
dns_lookup_family: v4_only
lb_policy: round_robin
load_assignment:
cluster_name: authelia
endpoints:
@ -233,6 +282,17 @@ static_resources:
socket_address:
address: authelia
port_value: 9091
layered_runtime:
layers:
- name: static_layer_0
static_layer:
envoy:
resource_limits:
listener:
example_listener_name:
connection_limit: 10000
overload:
global_downstream_max_connections: 50000
```
{{< /details >}}

View File

@ -66,22 +66,61 @@ the following networks to the trusted proxy list in [HAProxy]:
* 192.168.0.0/16
* fc00::/7
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Implementation
[HAProxy] utilizes the [ForwardAuth](../../reference/guides/proxy-authorization.md#forwardauth) Authz implementation. The
associated [Metadata](../../reference/guides/proxy-authorization.md#forwardauth-metadata) should be considered required.
The examples below assume you are using the default
[Authz Endpoints Configuration](../../configuration/miscellaneous/server-endpoints-authz.md) or one similar to the
following minimal configuration:
```yaml
server:
endpoints:
authz:
forward-auth:
implementation: ForwardAuth
```
## Configuration
Below you will find commented examples of the following configuration:
* Authelia Portal
* Protected Endpoint (Nextcloud)
* Protected Endpoint with `Authorization` header for basic authentication (Heimdall)
* Protected Endpoints (Nextcloud)
With this configuration you can protect your virtual hosts with Authelia, by following the steps below:
1. Add host(s) to the `protected-frontends` or `protected-frontends-basic` ACLs to support protection with Authelia.
You can separate each subdomain with a `|` in the regex, for example:
1. Add host(s) to the `protected-frontends` ACLs to support protection with Authelia. You can separate each subdomain
with a `|` in the regex, for example:
```text
acl protected-frontends hdr(host) -m reg -i ^(?i)(jenkins|nextcloud|phpmyadmin)\.example\.com
acl protected-frontends-basic hdr(host) -m reg -i ^(?i)(heimdall)\.example\.com
```
2. Add host ACL(s) in the form of `host-service`, this will be utilised to route to the correct
@ -166,46 +205,24 @@ frontend fe_http
option forwardfor
# Host ACLs
acl protected-frontends hdr(host) -m reg -i ^(?i)(nextcloud)\.example\.com
acl protected-frontends-basic hdr(host) -m reg -i ^(?i)(heimdall)\.example\.com
acl host-authelia hdr(host) -i auth.example.com
acl host-nextcloud hdr(host) -i nextcloud.example.com
acl host-heimdall hdr(host) -i heimdall.example.com
# This is required if utilising basic auth with /api/verify?auth=basic
http-request set-var(txn.host) hdr(Host)
acl protected-frontends hdr(Host) -m reg -i ^(?i)(nextcloud|heimdall)\.example\.com
acl host-authelia hdr(Host) -i auth.example.com
acl host-nextcloud hdr(Host) -i nextcloud.example.com
acl host-heimdall hdr(Host) -i heimdall.example.com
http-request set-var(req.scheme) str(https) if { ssl_fc }
http-request set-var(req.scheme) str(http) if !{ ssl_fc }
http-request set-var(req.questionmark) str(?) if { query -m found }
# These are optional if you wish to use the Methods rule in the access_control section.
#http-request set-var(req.method) str(CONNECT) if { method CONNECT }
#http-request set-var(req.method) str(GET) if { method GET }
#http-request set-var(req.method) str(HEAD) if { method HEAD }
#http-request set-var(req.method) str(OPTIONS) if { method OPTIONS }
#http-request set-var(req.method) str(POST) if { method POST }
#http-request set-var(req.method) str(TRACE) if { method TRACE }
#http-request set-var(req.method) str(PUT) if { method PUT }
#http-request set-var(req.method) str(PATCH) if { method PATCH }
#http-request set-var(req.method) str(DELETE) if { method DELETE }
#http-request set-header X-Forwarded-Method %[var(req.method)]
# Required headers
http-request set-header X-Real-IP %[src]
http-request set-header X-Original-Method %[var(req.method)]
http-request set-header X-Original-URL %[var(req.scheme)]://%[req.hdr(Host)]%[path]%[var(req.questionmark)]%[query]
# Required Headers
http-request set-header X-Forwarded-Method %[method]
http-request set-header X-Forwarded-Proto %[var(req.scheme)]
http-request set-header X-Forwarded-Host %[req.hdr(Host)]
http-request set-header X-Forwarded-URI %[path]%[var(req.questionmark)]%[query]
# Protect endpoints with haproxy-auth-request and Authelia
http-request lua.auth-request be_authelia /api/authz/auth-request if protected-frontends
# Force `Authorization` header via query arg to /api/verify
http-request lua.auth-request be_authelia /api/verify?auth=basic if protected-frontends-basic
# Redirect protected-frontends to Authelia if not authenticated
http-request redirect location https://auth.example.com/?rd=%[var(req.scheme)]://%[base]%[var(req.questionmark)]%[query] if protected-frontends !{ var(txn.auth_response_successful) -m bool }
# Send 401 and pass `WWW-Authenticate` header on protected-frontend-basic if not pre-authenticated
http-request set-var(txn.auth) var(req.auth_response_header.www_authenticate) if protected-frontends-basic !{ var(txn.auth_response_successful) -m bool }
http-response deny deny_status 401 hdr WWW-Authenticate %[var(txn.auth)] if { var(txn.host) -m reg -i ^(?i)(heimdall)\.example\.com } !{ var(txn.auth_response_successful) -m bool }
http-request lua.auth-intercept be_authelia /api/authz/forward-auth HEAD * authorization,proxy-authorization,remote_user,remote-user,remote-groups,remote-name,remote-email - if protected-frontends
http-request redirect location %[var(txn.auth_response_location)] if protected-frontends !{ var(txn.auth_response_successful) -m bool }
# Authelia backend route
use_backend be_authelia if host-authelia
@ -218,28 +235,16 @@ backend be_authelia
server authelia authelia:9091
backend be_nextcloud
# Pass Remote-User, Remote-Name, Remote-Email and Remote-Groups headers
acl remote_user_exist var(req.auth_response_header.remote_user) -m found
acl remote_groups_exist var(req.auth_response_header.remote_groups) -m found
acl remote_name_exist var(req.auth_response_header.remote_name) -m found
acl remote_email_exist var(req.auth_response_header.remote_email) -m found
http-request set-header Remote-User %[var(req.auth_response_header.remote_user)] if remote_user_exist
http-request set-header Remote-Groups %[var(req.auth_response_header.remote_groups)] if remote_groups_exist
http-request set-header Remote-Name %[var(req.auth_response_header.remote_name)] if remote_name_exist
http-request set-header Remote-Email %[var(req.auth_response_header.remote_email)] if remote_email_exist
## Pass the Set-Cookie response headers to the user.
acl set_cookie_exist var(req.auth_response_header.set_cookie) -m found
http-response set-header Set-Cookie %[var(req.auth_response_header.set_cookie)] if set_cookie_exist
server nextcloud nextcloud:443 ssl verify none
backend be_heimdall
# Pass Remote-User, Remote-Name, Remote-Email and Remote-Groups headers
acl remote_user_exist var(req.auth_response_header.remote_user) -m found
acl remote_groups_exist var(req.auth_response_header.remote_groups) -m found
acl remote_name_exist var(req.auth_response_header.remote_name) -m found
acl remote_email_exist var(req.auth_response_header.remote_email) -m found
http-request set-header Remote-User %[var(req.auth_response_header.remote_user)] if remote_user_exist
http-request set-header Remote-Groups %[var(req.auth_response_header.remote_groups)] if remote_groups_exist
http-request set-header Remote-Name %[var(req.auth_response_header.remote_name)] if remote_name_exist
http-request set-header Remote-Email %[var(req.auth_response_header.remote_email)] if remote_email_exist
## Pass the Set-Cookie response headers to the user.
acl set_cookie_exist var(req.auth_response_header.set_cookie) -m found
http-response set-header Set-Cookie %[var(req.auth_response_header.set_cookie)] if set_cookie_exist
server heimdall heimdall:443 ssl verify none
```
@ -263,47 +268,37 @@ defaults
frontend fe_http
bind *:443 ssl crt /usr/local/etc/haproxy/haproxy.pem
# Host ACLs
acl protected-frontends hdr(host) -m reg -i ^(?i)(nextcloud)\.example\.com
acl protected-frontends-basic hdr(host) -m reg -i ^(?i)(heimdall)\.example\.com
acl host-authelia hdr(host) -i auth.example.com
acl host-nextcloud hdr(host) -i nextcloud.example.com
acl host-heimdall hdr(host) -i heimdall.example.com
## Trusted Proxies.
http-request del-header X-Forwarded-For
# This is required if utilising basic auth with /api/verify?auth=basic
http-request set-var(txn.host) hdr(Host)
## Comment the above directive and the two directives below to enable the trusted proxies ACL.
# acl src-trusted_proxies src -f trusted_proxies.src.acl
# http-request del-header X-Forwarded-For if !src-trusted_proxies
## Ensure X-Forwarded-For is set for the auth request.
acl hdr-xff_exists req.hdr(X-Forwarded-For) -m found
http-request set-header X-Forwarded-For %[src] if !hdr-xff_exists
option forwardfor
# Host ACLs
acl protected-frontends hdr(Host) -m reg -i ^(?i)(nextcloud|heimdall)\.example\.com
acl host-authelia hdr(Host) -i auth.example.com
acl host-nextcloud hdr(Host) -i nextcloud.example.com
acl host-heimdall hdr(Host) -i heimdall.example.com
http-request set-var(req.scheme) str(https) if { ssl_fc }
http-request set-var(req.scheme) str(http) if !{ ssl_fc }
http-request set-var(req.questionmark) str(?) if { query -m found }
# These are optional if you wish to use the Methods rule in the access_control section.
#http-request set-var(req.method) str(CONNECT) if { method CONNECT }
#http-request set-var(req.method) str(GET) if { method GET }
#http-request set-var(req.method) str(HEAD) if { method HEAD }
#http-request set-var(req.method) str(OPTIONS) if { method OPTIONS }
#http-request set-var(req.method) str(POST) if { method POST }
#http-request set-var(req.method) str(TRACE) if { method TRACE }
#http-request set-var(req.method) str(PUT) if { method PUT }
#http-request set-var(req.method) str(PATCH) if { method PATCH }
#http-request set-var(req.method) str(DELETE) if { method DELETE }
#http-request set-header X-Forwarded-Method %[var(req.method)]
# Required headers
http-request set-header X-Real-IP %[src]
http-request set-header X-Original-Method %[var(req.method)]
http-request set-header X-Original-URL %[var(req.scheme)]://%[req.hdr(Host)]%[path]%[var(req.questionmark)]%[query]
# Required Headers
http-request set-header X-Forwarded-Method %[method]
http-request set-header X-Forwarded-Proto %[var(req.scheme)]
http-request set-header X-Forwarded-Host %[req.hdr(Host)]
http-request set-header X-Forwarded-URI %[path]%[var(req.questionmark)]%[query]
# Protect endpoints with haproxy-auth-request and Authelia
http-request lua.auth-request be_authelia_proxy /api/authz/auth-request if protected-frontends
# Force `Authorization` header via query arg to /api/verify
http-request lua.auth-request be_authelia_proxy /api/verify?auth=basic if protected-frontends-basic
# Redirect protected-frontends to Authelia if not authenticated
http-request redirect location https://auth.example.com/?rd=%[var(req.scheme)]://%[base]%[var(req.questionmark)]%[query] if protected-frontends !{ var(txn.auth_response_successful) -m bool }
# Send 401 and pass `WWW-Authenticate` header on protected-frontend-basic if not pre-authenticated
http-request set-var(txn.auth) var(req.auth_response_header.www_authenticate) if protected-frontends-basic !{ var(txn.auth_response_successful) -m bool }
http-response deny deny_status 401 hdr WWW-Authenticate %[var(txn.auth)] if { var(txn.host) -m reg -i ^(?i)(heimdall)\.example\.com } !{ var(txn.auth_response_successful) -m bool }
http-request lua.auth-intercept be_authelia_proxy /api/authz/forward-auth HEAD * authorization,proxy-authorization,remote_user,remote-user,remote-groups,remote-name,remote-email - if protected-frontends
http-request redirect location %[var(txn.auth_response_location)] if protected-frontends !{ var(txn.auth_response_successful) -m bool }
# Authelia backend route
use_backend be_authelia if host-authelia
@ -325,28 +320,16 @@ listen authelia_proxy
server authelia authelia:9091 ssl verify none
backend be_nextcloud
# Pass Remote-User, Remote-Name, Remote-Email and Remote-Groups headers
acl remote_user_exist var(req.auth_response_header.remote_user) -m found
acl remote_groups_exist var(req.auth_response_header.remote_groups) -m found
acl remote_name_exist var(req.auth_response_header.remote_name) -m found
acl remote_email_exist var(req.auth_response_header.remote_email) -m found
http-request set-header Remote-User %[var(req.auth_response_header.remote_user)] if remote_user_exist
http-request set-header Remote-Groups %[var(req.auth_response_header.remote_groups)] if remote_groups_exist
http-request set-header Remote-Name %[var(req.auth_response_header.remote_name)] if remote_name_exist
http-request set-header Remote-Email %[var(req.auth_response_header.remote_email)] if remote_email_exist
## Pass the Set-Cookie response headers to the user.
acl set_cookie_exist var(req.auth_response_header.set_cookie) -m found
http-response set-header Set-Cookie %[var(req.auth_response_header.set_cookie)] if set_cookie_exist
server nextcloud nextcloud:443 ssl verify none
backend be_heimdall
# Pass Remote-User, Remote-Name, Remote-Email and Remote-Groups headers
acl remote_user_exist var(req.auth_response_header.remote_user) -m found
acl remote_groups_exist var(req.auth_response_header.remote_groups) -m found
acl remote_name_exist var(req.auth_response_header.remote_name) -m found
acl remote_email_exist var(req.auth_response_header.remote_email) -m found
http-request set-header Remote-User %[var(req.auth_response_header.remote_user)] if remote_user_exist
http-request set-header Remote-Groups %[var(req.auth_response_header.remote_groups)] if remote_groups_exist
http-request set-header Remote-Name %[var(req.auth_response_header.remote_name)] if remote_name_exist
http-request set-header Remote-Email %[var(req.auth_response_header.remote_email)] if remote_email_exist
## Pass the Set-Cookie response headers to the user.
acl set_cookie_exist var(req.auth_response_header.set_cookie) -m found
http-response set-header Set-Cookie %[var(req.auth_response_header.set_cookie)] if set_cookie_exist
server heimdall heimdall:443 ssl verify none
```

View File

@ -40,6 +40,30 @@ To configure trusted proxies for [NGINX Proxy Manager] see the [NGINX] section o
[Trusted Proxies](../nginx.md#trusted-proxies). Adapting this to [NGINX Proxy Manager] is beyond the scope of
this documentation.
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Docker Compose
The following docker compose example has various applications suitable for setting up an example environment.
@ -68,7 +92,7 @@ services:
volumes:
- ${PWD}/data/nginx-proxy-manager/data:/data
- ${PWD}/data/nginx-proxy-manager/letsencrypt:/etc/letsencrypt
- ${PWD}/data/nginx/snippets:/config/nginx/snippets:ro
- ${PWD}/data/nginx/snippets:/snippets:ro
environment:
TZ: 'Australia/Melbourne'
authelia:

View File

@ -34,8 +34,8 @@ You need the following to run __Authelia__ with [NGINX]:
* [NGINX] must be built with the `http_auth_request` module which is relatively common
* [NGINX] must be built with the `http_realip` module which is relatively common
* [NGINX] must be built with the `http_set_misc` module or the `nginx-mod-http-set-misc` package if you want to preserve
more than one query parameter when redirected to the portal due to a limitation in [NGINX]
* [NGINX] must be built with the `http_set_misc` module or the `nginx-mod-http-set-misc` package if you want to use the
legacy method and preserve more than one query parameter when redirected to the portal due to a limitation in [NGINX]
## Trusted Proxies
@ -52,6 +52,47 @@ configured in the `proxy.conf` file. Each `set_realip_from` directive adds a tru
proxies list. Any request that comes from a source IP not in one of the configured ranges results in the header being
replaced with the source IP of the client.
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Implementation
[NGINX] utilizes the [AuthRequest](../../reference/guides/proxy-authorization.md#authrequest) Authz implementation. The
associated [Metadata](../../reference/guides/proxy-authorization.md#authrequest-metadata) should be considered required.
The examples below assume you are using the default
[Authz Endpoints Configuration](../../configuration/miscellaneous/server-endpoints-authz.md) or one similar to the
following minimal configuration:
```yaml
server:
endpoints:
authz:
auth-request:
implementation: AuthRequest
```
## Docker Compose
The following docker compose example has various applications suitable for setting up an example environment.
@ -383,7 +424,7 @@ proxy_set_header X-Forwarded-For $remote_addr;
set $upstream_authelia http://authelia:9091/api/authz/auth-request;
## Virtual endpoint created by nginx to forward auth requests.
location /authelia {
location /internal/authelia/authz {
## Essential Proxy Configuration
internal;
proxy_pass $upstream_authelia;
@ -423,30 +464,49 @@ and is paired with [authelia-location.conf](#authelia-locationconf).*
{{< details "/config/nginx/snippets/authelia-authrequest.conf" >}}
```nginx
## Send a subrequest to Authelia to verify if the user is authenticated and has permission to access the resource.
auth_request /authelia;
auth_request /internal/authelia/authz;
## Set the $target_url variable based on the original request.
## Save the upstream authorization response headers from Authelia to variables.
auth_request_set $authorization $upstream_http_authorization;
auth_request_set $proxy_authorization $upstream_http_proxy_authorization;
## Comment this line if you're using nginx without the http_set_misc module.
set_escape_uri $target_url $scheme://$http_host$request_uri;
## Inject the authorization response headers from the variables into the request made to the backend.
proxy_set_header Authorization $authorization;
proxy_set_header Proxy-Authorization $proxy_authorization;
## Uncomment this line if you're using NGINX without the http_set_misc module.
# set $target_url $scheme://$http_host$request_uri;
## Save the upstream response headers from Authelia to variables.
## Save the upstream metadata response headers from Authelia to variables.
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
auth_request_set $name $upstream_http_remote_name;
auth_request_set $email $upstream_http_remote_email;
## Inject the response headers from the variables into the request made to the backend.
## Inject the metadata response headers from the variables into the request made to the backend.
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
proxy_set_header Remote-Name $name;
proxy_set_header Remote-Email $email;
proxy_set_header Remote-Name $name;
## If the subreqest returns 200 pass to the backend, if the subrequest returns 401 redirect to the portal.
error_page 401 =302 https://auth.example.com/?rd=$target_url;
## Include the Set-Cookie header if present.
auth_request_set $cookie $upstream_http_set_cookie;
add_header Set-Cookie $cookie;
## Configure the redirection when the authz failure occurs. Lines starting with 'Modern Method' and 'Legacy Method'
## should be commented / uncommented as pairs. The modern method uses the session cookies configuration's authelia_url
## value to determine the redirection URL here. It's much simpler and compatible with the mutli-cookie domain easily.
## Modern Method: Set the $redirection_url to the Location header of the response to the Authz endpoint.
auth_request_set $redirection_url $upstream_http_location;
## Modern Method: When there is a 401 response code from the authz endpoint redirect to the $redirection_url.
error_page 401 =302 $redirection_url;
## Legacy Method: Set $target_url to the original requested URL.
## This requires http_set_misc module, replace 'set_escape_uri' with 'set' if you don't have this module.
# set_escape_uri $target_url $scheme://$http_host$request_uri;
## Legacy Method: When there is a 401 response code from the authz endpoint redirect to the portal with the 'rd'
## URL parameter set to $target_url. This requires users update 'auth.example.com/' with their external authelia URL.
# error_page 401 =302 https://auth.example.com/?rd=$target_url;
```
{{< /details >}}
@ -466,7 +526,7 @@ implementation `AuthRequest` which contains the `HeaderAuthorization` and `Heade
set $upstream_authelia http://authelia:9091/api/authz/auth-request/basic;
# Virtual endpoint created by nginx to forward auth requests.
location /authelia-basic {
location /internal/authelia/authz/basic {
## Essential Proxy Configuration
internal;
proxy_pass $upstream_authelia;
@ -514,13 +574,7 @@ endpoint. It's recommended to use [authelia-authrequest.conf](#authelia-authrequ
{{< details "/config/nginx/snippets/authelia-authrequest-basic.conf" >}}
```nginx
## Send a subrequest to Authelia to verify if the user is authenticated and has permission to access the resource.
auth_request /authelia-basic;
## Comment this line if you're using nginx without the http_set_misc module.
set_escape_uri $target_url $scheme://$http_host$request_uri;
## Uncomment this line if you're using NGINX without the http_set_misc module.
# set $target_url $scheme://$http_host$request_uri;
auth_request /internal/authelia/authz/basic;
## Save the upstream response headers from Authelia to variables.
auth_request_set $user $upstream_http_remote_user;
@ -558,7 +612,7 @@ if ($request_uri = "/force-basic") {
}
## A new virtual endpoint to used if the auth_request failed
location /authelia-detect {
location /internal/authelia/authz/detect {
internal;
if ($is_basic_auth) {
@ -568,6 +622,9 @@ location /authelia-detect {
return 401;
}
## IMPORTANT: The below URL `https://auth.example.com/` MUST be replaced with the externally accessible URL of the
## Authelia Portal/Site.
##
## The original request didn't target /force-basic, redirect to the pretty login page
## This is what `error_page 401 =302 https://auth.example.com/?rd=$target_url;` did.
return 302 https://auth.example.com/$is_args$args;
@ -586,7 +643,7 @@ endpoint. It's recommended to use [authelia-authrequest.conf](#authelia-authrequ
{{< details "/config/nginx/snippets/authelia-authrequest-detect.conf" >}}
```nginx
## Send a subrequest to Authelia to verify if the user is authenticated and has permission to access the resource.
auth_request /authelia;
auth_request /internal/authelia/authz;
## Comment this line if you're using nginx without the http_set_misc module.
set_escape_uri $target_url $scheme://$http_host$request_uri;
@ -607,7 +664,7 @@ proxy_set_header Remote-Name $name;
proxy_set_header Remote-Email $email;
## If the subreqest returns 200 pass to the backend, if the subrequest returns 401 redirect to the portal.
error_page 401 =302 /authelia-detect?rd=$target_url;
error_page 401 =302 /internal/authelia/authz/detect?rd=$target_url;
```
{{< /details >}}

View File

@ -44,6 +44,30 @@ how you can configure multiple IP ranges. You should customize this example to f
You should only include the specific IP address ranges of the trusted proxies within your architecture and should not
trust entire subnets unless that subnet only has trusted proxies and no other services.*
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Potential
Support for [Skipper] should be possible via [Skipper]'s

View File

@ -15,19 +15,19 @@ aliases:
- /docs/home/supported-proxies.html
---
| Proxy | [Implementation] | [Standard](#standard) | [Kubernetes](#kubernetes) | [XHR Redirect](#xhr-redirect) | [Request Method](#request-method) |
|:---------------------:|:----------------:|:------------------------------------------------------------------:|:-------------------------------------------------------------------------------------:|:---------------------------------:|:---------------------------------:|
| [Traefik] | [ForwardAuth] | {{% support support="full" link="traefik.md" %}} | {{% support support="full" link="../../integration/kubernetes/traefik-ingress.md" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Caddy] | [ForwardAuth] | {{% support support="full" link="caddy.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Envoy] | [ExtAuthz] | {{% support support="full" link="envoy.md" %}} | {{% support support="full" link="../../integration/kubernetes/istio.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [NGINX] | [AuthRequest] | {{% support support="full" link="nginx.md" %}} | {{% support support="full" link="../../integration/kubernetes/nginx-ingress.md" %}} | {{% support %}} | {{% support support="full" %}} |
| [NGINX Proxy Manager] | [AuthRequest] | {{% support support="full" link="nginx-proxy-manager/index.md" %}} | {{% support support="unknown" %}} | {{% support %}} | {{% support support="full" %}} |
| [SWAG] | [AuthRequest] | {{% support support="full" link="swag.md" %}} | {{% support support="unknown" %}} | {{% support %}} | {{% support support="full" %}} |
| [HAProxy] | [AuthRequest] | {{% support support="full" link="haproxy.md" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [Skipper] | [ForwardAuth] | {{% support support="full" link="skipper.md" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} |
| [Traefik] 1.x | [ForwardAuth] | {{% support support="full" link="traefikv1.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Apache] | N/A | {{% support link="#apache" %}} | {{% support %}} | {{% support %}} | {{% support %}} |
| [IIS] | N/A | {{% support link="#iis" %}} | {{% support %}} | {{% support %}} | {{% support %}} |
| Proxy | [Implementation] | [Standard](#standard) | [Kubernetes](#kubernetes) | [XHR Redirect](#xhr-redirect) | [Request Method](#request-method) |
|:---------------------------------------:|:----------------:|:---------------------------------------------------:|:-------------------------------------------------------------------------------------:|:---------------------------------:|:---------------------------------:|
| [Traefik] ([guide](/i/traefik)) | [ForwardAuth] | {{% support support="full" link="/i/traefik" %}} | {{% support support="full" link="../../integration/kubernetes/traefik-ingress.md" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Caddy] ([guide](/i/caddy)) | [ForwardAuth] | {{% support support="full" link="/i/caddy" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Envoy] ([guide](/i/envoy)) | [ExtAuthz] | {{% support support="full" link="/i/envoy" %}} | {{% support support="full" link="../../integration/kubernetes/istio.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [NGINX] ([guide](/i/nginx)) | [AuthRequest] | {{% support support="full" link="/i/nginx" %}} | {{% support support="full" link="../../integration/kubernetes/nginx-ingress.md" %}} | {{% support %}} | {{% support support="full" %}} |
| [NGINX Proxy Manager] ([guide](/i/npm)) | [AuthRequest] | {{% support support="full" link="/i/npm" %}} | {{% support support="unknown" %}} | {{% support %}} | {{% support support="full" %}} |
| [SWAG] ([guide](/i/swag)) | [AuthRequest] | {{% support support="full" link="/i/swag" %}} | {{% support support="unknown" %}} | {{% support %}} | {{% support support="full" %}} |
| [HAProxy] ([guide](/i/haproxy)) | [AuthRequest] | {{% support support="full" link="/i/haproxy" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [Skipper] ([guide](/i/skipper)) | [ForwardAuth] | {{% support support="full" link="/i/skipper" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} |
| [Traefik] 1.x ([guide](/i/traefik/v1)) | [ForwardAuth] | {{% support support="full" link="/i/traefik/v1" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Apache] | N/A | {{% support link="#apache" %}} | {{% support %}} | {{% support %}} | {{% support %}} |
| [IIS] | N/A | {{% support link="#iis" %}} | {{% support %}} | {{% support %}} | {{% support %}} |
[ForwardAuth]: ../../reference/guides/proxy-authorization.md#forwardauth
[AuthRequest]: ../../reference/guides/proxy-authorization.md#authrequest

View File

@ -42,22 +42,67 @@ bootstrapping *Authelia*.
### SWAG Caveat
One current caveat of the [SWAG] implementation is that it serves Authelia as a subpath for each domain. We
*__strongly recommend__* instead of using the out of the box method and guide for [SWAG] that you follow the
[NGINX](nginx.md) guide (which *can be used* with [SWAG]) and run Authelia as it's own subdomain.
One current caveat of the [SWAG] implementation is that it serves Authelia as a subpath for each domain by default. We
*__strongly recommend__* instead of using the defaults that you configure Authelia as a subdomain if possible.
This is partly because Webauthn requires that the domain is an exact match when registering and authenticating and it is
There are two potential ways to achieve this:
1. Adjust the default `authelia-server.conf` as per the included directions.
2. Use the supplementary configuration snippets provided officially by Authelia.
This is partly because WebAuthn requires that the domain is an exact match when registering and authenticating and it is
possible that due to web standards this will never change.
In addition this represents a bad user experience in some instances such as:
- Users sometimes visit the `https://app.example.com/authelia` URL which doesn't automatically redirect the user to
`https://app.example.com` (if they visit `https://app.example.com` then they'll be redirected to authenticate then
redirected back to their original URL).
- Administrators may wish to setup OpenID Connect 1.0 in which case it also doesn't represent a good user experience.
* Users sometimes visit the `https://app.example.com/authelia` URL which doesn't automatically redirect the user to
`https://app.example.com` (if they visit `https://app.example.com` then they'll be redirected to authenticate then
redirected back to their original URL)
* Administrators may wish to setup [OpenID Connect 1.0](../../configuration/identity-providers/open-id-connect.md) in
which case it also doesn't represent a good user experience as the `issuer` will be
`https://app.example.com/authelia` for example
* Using the [SWAG] default configurations are more difficult to support as our specific familiarity is with our own
example snippets
Taking these factors into consideration we're adapting our [SWAG] guide to use what we consider best for the users and
most easily supported. Users who wish to use the [SWAG] guide are free to do so but may not receive the same support.
#### Option 1: Adjusting the Default Configuration
Open the generated `authelia-server.conf`. Adjust the following sections. There are two snippets, one before and one
after. The only lines that change are the `set $authelia_backend` lines, and this configuration assumes you're
serving Authelia at `auth.example.com`.
```nginx
## Set $authelia_backend to route requests to the current domain by default
set $authelia_backend $http_host;
## In order for Webauthn to work with multiple domains authelia must operate on a separate subdomain
## To use authelia on a separate subdomain:
## * comment the $authelia_backend line above
## * rename /config/nginx/proxy-confs/authelia.conf.sample to /config/nginx/proxy-confs/authelia.conf
## * make sure that your dns has a cname set for authelia
## * uncomment the $authelia_backend line below and change example.com to your domain
## * restart the swag container
#set $authelia_backend authelia.example.com;
return 302 https://$authelia_backend/authelia/?rd=$target_url;
```
```nginx
## Set $authelia_backend to route requests to the current domain by default
# set $authelia_backend $http_host;
## In order for Webauthn to work with multiple domains authelia must operate on a separate subdomain
## To use authelia on a separate subdomain:
## * comment the $authelia_backend line above
## * rename /config/nginx/proxy-confs/authelia.conf.sample to /config/nginx/proxy-confs/authelia.conf
## * make sure that your dns has a cname set for authelia
## * uncomment the $authelia_backend line below and change example.com to your domain
## * restart the swag container
set $authelia_backend auth.example.com;
return 302 https://$authelia_backend/authelia/?rd=$target_url;
```
#### Option 2: Using the Authelia Supplementary Configuration Snippets
See standard [NGINX](nginx.md) guide (which *can be used* with [SWAG]) and run Authelia as it's own subdomain.
## Trusted Proxies
@ -67,6 +112,30 @@ Especially if you have never read it before.*
To configure trusted proxies for [SWAG] see the [NGINX] section on [Trusted Proxies](nginx.md#trusted-proxies).
Adapting this to [SWAG] is beyond the scope of this documentation.
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Docker Compose
The following docker compose example has various applications suitable for setting up an example environment.
@ -102,6 +171,8 @@ services:
- '443:443'
volumes:
- ${PWD}/data/swag:/config
## Uncomment the line below if you want to use the Authelia configuration snippets.
#- ${PWD}/data/nginx/snippets:/snippets:ro
environment:
PUID: '1000'
PGID: '1000'

View File

@ -61,6 +61,23 @@ networks to the trusted proxy list in [Traefik]:
See the [Entry Points](https://doc.traefik.io/traefik/routing/entrypoints) documentation for more information.
## Implementation
[Traefik] utilizes the [ForwardAuth](../../reference/guides/proxy-authorization.md#forwardauth) Authz implementation. The
associated [Metadata](../../reference/guides/proxy-authorization.md#forwardauth-metadata) should be considered required.
The examples below assume you are using the default
[Authz Endpoints Configuration](../../configuration/miscellaneous/server-endpoints-authz.md) or one similar to the
following minimal configuration:
```yaml
server:
endpoints:
authz:
forward-auth:
implementation: ForwardAuth
```
## Configuration
Below you will find commented examples of the following docker deployment:
@ -76,6 +93,30 @@ The below configuration looks to provide examples of running [Traefik] 2.x with
Please ensure that you also setup the respective [ACME configuration](https://docs.traefik.io/https/acme/) for your
[Traefik] setup as this is not covered in the example below.
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
### Docker Compose
This is an example configuration using [docker compose] labels:
@ -157,7 +198,7 @@ services:
## configured in the Session Cookies section of the Authelia configuration.
# - 'traefik.http.middlewares.authelia.forwardAuth.address=http://authelia:9091/api/authz/forward-auth?authelia_url=https%3A%2F%2Fauth.example.com%2F'
- 'traefik.http.middlewares.authelia.forwardAuth.trustForwardHeader=true'
- 'traefik.http.middlewares.authelia.forwardAuth.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Name,Remote-Email'
- 'traefik.http.middlewares.authelia.forwardAuth.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Email,Remote-Name'
nextcloud:
container_name: nextcloud
image: linuxserver/nextcloud
@ -503,7 +544,7 @@ This can be avoided a couple different ways:
## configured in the Session Cookies section of the Authelia configuration.
# - 'traefik.http.middlewares.authelia.forwardAuth.address=http://authelia:9091/api/authz/forward-auth?authelia_url=https%3A%2F%2Fauth.example.com%2F'
- 'traefik.http.middlewares.authelia.forwardAuth.trustForwardHeader=true'
- 'traefik.http.middlewares.authelia.forwardAuth.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Name,Remote-Email'
- 'traefik.http.middlewares.authelia.forwardAuth.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Email,Remote-Name'
```
## See Also

View File

@ -11,6 +11,7 @@ menu:
weight: 371
toc: true
aliases:
- /i/traefik/v1
- /docs/deployment/supported-proxies/traefik1.x.html
---
@ -49,6 +50,47 @@ networks to the trusted proxy list in [Traefik]:
* 192.168.0.0/16
* fc00::/7
## Assumptions and Adaptation
This guide makes a few assumptions. These assumptions may require adaptation in more advanced and complex scenarios. We
can not reasonably have examples for every advanced configuration option that exists. The
following are the assumptions we make:
* Deployment Scenario:
* Single Host
* Authelia is deployed as a Container with the container name `authelia` on port `9091`
* Proxy is deployed as a Container on a network shared with Authelia
* The above assumption means that AUthelia should be accesible to the proxy on `http://authelia:9091` and as such:
* You will have to adapt all instances of the above URL to be `https://` if Authelia configuration has a TLS key and
certificate defined
* You will have to adapt all instances of `authelia` in the URL if:
* you're using a different container name
* you deployed the proxy to a different location
* You will have to adapt all instances of `9091` in the URL if:
* you have adjusted the default port in the configuration
* You will have to adapt the entire URL if:
* Authelia is on a different host to the proxy
* All services are part of the `example.com` domain:
* This domain and the subdomains will have to be adapted in all examples to match your specific domains unless you're
just testing or you want ot use that specific domain
## Implementation
[Traefik] utilizes the [ForwardAuth](../../reference/guides/proxy-authorization.md#forwardauth) Authz implementation. The
associated [Metadata](../../reference/guides/proxy-authorization.md#forwardauth-metadata) should be considered required.
The examples below assume you are using the default
[Authz Endpoints Configuration](../../configuration/miscellaneous/server-endpoints-authz.md) or one similar to the
following minimal configuration:
```yaml
server:
endpoints:
authz:
forward-auth:
implementation: ForwardAuth
```
## Configuration
Below you will find commented examples of the following docker deployment:
@ -137,7 +179,7 @@ services:
## configured in the Session Cookies section of the Authelia configuration.
# - 'traefik.frontend.auth.forward.address=http://authelia:9091/api/authz/forward-auth?authelia_url=https%3A%2F%2Fauth.example.com%2F'
- 'traefik.frontend.auth.forward.trustForwardHeader=true'
- 'traefik.frontend.auth.forward.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Name,Remote-Email'
- 'traefik.frontend.auth.forward.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Email,Remote-Name'
expose:
- 443
restart: unless-stopped
@ -156,7 +198,7 @@ services:
- 'traefik.frontend.rule=Host:heimdall.example.com'
- 'traefik.frontend.auth.forward.address=http://authelia:9091/api/authz/forward-auth/basic'
- 'traefik.frontend.auth.forward.trustForwardHeader=true'
- 'traefik.frontend.auth.forward.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Name,Remote-Email'
- 'traefik.frontend.auth.forward.authResponseHeaders=Authorization,Proxy-Authorization,Remote-User,Remote-Groups,Remote-Email,Remote-Name'
expose:
- 443
restart: unless-stopped

View File

@ -14,19 +14,19 @@ toc: false
The following table is a support matrix for Authelia features and specific reverse proxies.
| Proxy | Standard | Kubernetes | XHR Redirect | Request Method |
|:---------------------:|:--------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------------------------:|:---------------------------------:|:---------------------------------:|
| [Traefik] | {{% support support="full" link="../../integration/proxies/traefik.md" %}} | {{% support support="full" link="../../integration/kubernetes/traefik-ingress.md" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Caddy] | {{% support support="full" link="../../integration/proxies/caddy.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Envoy] | {{% support support="full" link="../../integration/proxies/envoy.md" %}} | {{% support support="full" link="../../integration/kubernetes/istio.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [NGINX] | {{% support support="full" link="../../integration/proxies/nginx.md" %}} | {{% support support="full" link="../../integration/kubernetes/nginx-ingress.md" %}} | {{% support %}} | {{% support support="full" %}} |
| [NGINX Proxy Manager] | {{% support support="full" link="../../integration/proxies/nginx-proxy-manager/index.md" %}} | {{% support %}} | {{% support %}} | {{% support support="full" %}} |
| [SWAG] | {{% support support="full" link="../../integration/proxies/swag.md" %}} | {{% support %}} | {{% support %}} | {{% support support="full" %}} |
| [HAProxy] | {{% support support="full" link="../../integration/proxies/haproxy.md" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [Traefik] 1.x | {{% support support="full" link="../../integration/proxies/traefikv1.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Skipper] | {{% support support="full" link="../../integration/proxies/skipper.md" %}} | {{% support %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} |
| [Apache] | {{% support %}} | {{% support %}} | {{% support %}} | {{% support %}} |
| [IIS] | {{% support %}} | {{% support %}} | {{% support %}} | {{% support %}} |
| Proxy | Standard | Kubernetes | XHR Redirect | Request Method |
|:---------------------------------------:|:-------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------------------------:|:---------------------------------:|:---------------------------------:|
| [Traefik] ([guide](/i/traefik)) | {{% support support="full" link="/i/traefik" %}} | {{% support support="full" link="../../integration/kubernetes/traefik-ingress.md" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Caddy] ([guide](/i/caddy)) | {{% support support="full" link="/i/caddy" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Envoy] ([guide](/i/envoy)) | {{% support support="full" link="/i/envoy" %}} | {{% support support="full" link="../../integration/kubernetes/istio.md" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [NGINX] ([guide](/i/nginx)) | {{% support support="full" link="/i/nginx" %}} | {{% support support="full" link="../../integration/kubernetes/nginx-ingress.md" %}} | {{% support %}} | {{% support support="full" %}} |
| [NGINX Proxy Manager] ([guide](/i/npm)) | {{% support support="full" link="/i/npm" %}} | {{% support support="unknown" %}} | {{% support %}} | {{% support support="full" %}} |
| [SWAG] ([guide](/i/swag)) | {{% support support="full" link="/i/swag" %}} | {{% support support="unknown" %}} | {{% support %}} | {{% support support="full" %}} |
| [HAProxy] ([guide](/i/haproxy)) | {{% support support="full" link="/i/haproxy" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} |
| [Skipper] ([guide](/i/skipper)) | {{% support support="full" link="/i/skipper" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} | {{% support support="unknown" %}} |
| [Traefik] 1.x ([guide](/i/traefik/v1)) | {{% support support="full" link="/i/traefik/v1" %}} | {{% support support="unknown" %}} | {{% support support="full" %}} | {{% support support="full" %}} |
| [Apache] | {{% support %}} | {{% support %}} | {{% support %}} | {{% support %}} |
| [IIS] | {{% support %}} | {{% support %}} | {{% support %}} | {{% support %}} |
Legend:

View File

@ -15,12 +15,22 @@ aliases:
---
The __Authelia__ team takes security very seriously. Because __Authelia__ is intended as a security product a lot of
decisions are made with security being the priority. This section discusses these decisions as well as considerations
users should make when implementing __Authelia__.
decisions are made with security being the priority and we always aim to implement security by design.
## Coordinated vulnerability disclosure
__Authelia__ follows the [coordinated vulnerability disclosure](https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure)
model when dealing with security vulnerabilities. This was previously known as responsible disclosure. We strongly
urge anyone reporting vulnerabilities to __Authelia__ or any other project to follow this model as it is considered
as a best practice by many in the security industry.
__Authelia__ follows the [coordinated vulnerability disclosure] model when dealing with security vulnerabilities. This
was previously known as responsible disclosure. We strongly urge anyone reporting vulnerabilities to __Authelia__ or any
other project to follow this model as it is considered as a best practice by many in the security industry.
If you believe you have identified a security vulnerability or security related bug with __Authelia__ please make every
effort to contact us privately using one of the [contact options](../../policies/security.md#contact-options) below.
Please do not open an issue, do not notify us in public, and do not disclose this issue to third parties.
Using this process helps ensure that users affected have an avenue to fixing the issue as close to the issue being
made public as possible. This mitigates the increasing the attack surface (via improving attacker knowledge) for
diligent administrators simply via the act of disclosing the security issue.
## Policy
Please view our [security policy](../../policies/security.md) for more information.

View File

@ -75,6 +75,14 @@ Lastly Authelia's implementation of Argon2id is highly tunable. You can tune the
(time), parallelism, and memory usage. To read more about this please read how to
[configure](../../configuration/first-factor/file.md) file authentication.
## Protections against return oriented programming attacks and general hardening
Authelia is built as a position independent executable which makes Return Oriented Programming (ROP) attacks
significantly more difficult to execute reliably.
In addition it is built as a static binary with full relocation read-only support making this and several other
traditional binary weaknesses significantly more difficult to exploit.
## User profile and group membership always kept up-to-date (LDAP authentication provider)
This measure is unrelated to the File authentication provider.
@ -216,9 +224,9 @@ to port 587 (_the `submission` port, a common alternative that uses STARTTLS ins
[docs-config-smtp-port]: ../../configuration/notifications/smtp.md#port
[cleartext]: https://cwe.mitre.org/data/definitions/312.html
[service-submissions]: https://www.rfc-editor.org/rfc/rfc8314#section-7.3
[port-465]: https://www.rfc-editor.org/rfc/rfc8314#section-3.3
[smtp-auth]: https://www.rfc-editor.org/rfc/rfc6409#section-4.3
[service-submissions]: https://datatracker.ietf.org/doc/html/rfc8314#section-7.3
[port-465]: https://datatracker.ietf.org/doc/html/rfc8314#section-3.3
[smtp-auth]: https://datatracker.ietf.org/doc/html/rfc6409#section-4.3
## Protection against open redirects

View File

@ -11,58 +11,82 @@ aliases:
---
The __Authelia__ team takes security very seriously. Because __Authelia__ is intended as a security product a lot of
decisions are made with security being the priority.
decisions are made with security being the priority and we always aim to implement security by design.
## Coordinated vulnerability disclosure
__Authelia__ follows the
[coordinated vulnerability disclosure](https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure) model when
dealing with security vulnerabilities. This was previously known as responsible disclosure. We strongly urge anyone
reporting vulnerabilities to __Authelia__ or any other project to follow this model as it is considered as a best
practice by many in the security industry.
__Authelia__ follows the [coordinated vulnerability disclosure] model when dealing with security vulnerabilities. This
was previously known as responsible disclosure. We strongly urge anyone reporting vulnerabilities to __Authelia__ or any
other project to follow this model as it is considered as a best practice by many in the security industry.
If you believe you have identified a security related bug with Authelia please do not open an issue, do not notify us in
public, and do not disclose this issue to third parties. Please use one of the [contact options](#contact-options)
below.
If you believe you have identified a security vulnerability or security related bug with __Authelia__ please make every
effort to contact us privately using one of the [contact options](#contact-options) below. Please do not open an issue,
do not notify us in public, and do not disclose this issue to third parties.
Using this process helps ensure that users affected have an avenue to fixing the issue as close to the issue being
made public as possible. This mitigates the increasing the attack surface (via improving attacker knowledge) for
diligent administrators simply via the act of disclosing the security issue.
## Contact Options
Several contact options exist however it's important you specifically use a security contact method when reporting a
security vulnerability or security related bug. These methods are clearly documented below.
### GitHub Security
Users can utilize GitHub's security vulnerability system to privately [report a vulnerability]. This is an easy method
for users who have a GitHub account.
### Email
Please utilize the [security@authelia.com](mailto:team@authelia.com) email address for security issues discovered. This
email address is only accessible by key members of the team for the purpose of disclosing security issues within the
__Authelia__ code base.
Users can utilize the [security@authelia.com](mailto:security@authelia.com) email address to privately report a
vulnerability. This is an easy method of users who do not have a GitHub account.
This is the preferred method of reporting.
This email address is only accessible by members of the [core team] for the purpose of disclosing security
vulnerabilities and issues within the __Authelia__ code base.
### Chat
If you wish to chat directly instead of sending an email please use one of the
[chat options](../information/contact.md#chat) but it is vital that when you do that you only do so privately with one
of the maintainers. In order to start a private discussion you should ask to have a private discussion with a team
member without mentioning the reason why you wish to have a private discussion so that provided the bug is confirmed we
can coordinate the release of fixes and information responsibly.
[chat options](../information/contact.md#chat) to direct / private message one of the [core team] members.
## Credit
Please avoid this method unless absolutely necessary. We generally prefer that users use either the
[GitHub Security](#github-security) or [Email](#email) option rather than this option as it both allows multiple team
members to deal with the report and prevents mistakes when contacting a [core team] member.
Users who report bugs will optionally be credited for the discovery in the
[security advisory](https://github.com/authelia/authelia/security/advisories) and/or in our
[all contributors](https://github.com/authelia/authelia/blob/master/README.md#contribute) configuration/documentation.
The [core team] members are identified in [Matrix](../information/contact.md#matrix) as room admins, and in
[Discord](../information/contact.md#discord) with the `Core Team` role.
## Process
1. User privately reports a potential vulnerability.
2. The core team reviews the report and ascertain if additional information is required.
3. The core team reproduces the bug.
4. The bug is patched, and if possible the user reporting te bug is given access to a fixed version or git patch.
5. The fix is confirmed to resolve the vulnerability.
6. The fix is released.
7. The security advisory is published sometime after users have had a chance to update.
1. The user privately reports a potential vulnerability.
2. The report is acknowledged as received.
3. The report is reviewed to ascertain if additional information is required. If it is required:
1. The user is informed that the additional information is required.
2. The user privately adds the additional information.
3. The process begins at step 3 again, proceeding to step 4 if the additional information provided is sufficient.
4. The vulnerability is reproduced.
5. The vulnerability is patched, and if possible the user reporting the bug is given access to a fixed binary, docker
image, and git patch.
6. The patch is confirmed to resolve the vulnerability.
7. The fix is released and users are notified that they should update urgently.
8. The [security advisory] is published when (whichever happens sooner):
- The CVE details are published by [MITRE], [NIST], etc.
- Roughly 7 days after users have been notified the update is available.
[MITRE]: https://www.mitre.org/
[NIST]: https://www.nist.gov/
## Credit
Users who report bugs will at their discretion (i.e. they do not have to be if they wish to remain anonymous) be
credited for the discovery. Both in the [security advisory] and in our
[all contributors] documentation.
## Help wanted
We are actively looking for sponsorship to obtain security audits to comprehensively ensure the security of Authelia.
As security is imperative to us we see this as one of the main financial priorities.
We are actively looking for sponsorship to obtain security audits to comprehensively ensure the security of _Authelia_.
As security is really important to us we see this as one of the main financial priorities.
We believe that we should obtain the following categories of security audits:
@ -70,5 +94,11 @@ We believe that we should obtain the following categories of security audits:
* Penetration Testing
If you know of a company which either performs these kinds of audits and would be willing to sponsor the audit in some
way such as doing it pro bono or at a discounted rate, or wants to help improve Authelia in a meaningful way and is
way such as doing it pro bono or at a discounted rate, or wants to help improve _Authelia_ in a meaningful way and is
willing to make a financial contribution towards this then please feel free to contact us.
[coordinated vulnerability disclosure]: https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure
[security advisory]: https://github.com/authelia/authelia/security/advisories
[report a vulnerability]: https://github.com/authelia/authelia/security/advisories/new
[core team]: ../information/about.md#core-team
[all contributors]: https://github.com/authelia/authelia/blob/master/README.md#contribute

View File

@ -22,6 +22,17 @@ prevent automatic upgrade of the `major` version.
We generally do not recommend automated upgrades of critical systems but instead recommend ensuring you are notified an
upgrade exists.
## Supported Versions
The following information is indicative of our support policy:
- We provide support to user questions for 3 `minor` versions at minimum
- We provide bug fixes (as a `patch`) to the latest `minor` version
- We provide vulnerability fixes:
- As workarounds in the [security advisory](https://github.com/authelia/authelia/security/advisories) (if possible)
- As patches in the [security advisory](https://github.com/authelia/authelia/security/advisories)
- To the last 3 `minor` versions upon request
## Major Version Zero
A major version of `v0.x.x` indicates as per the [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) policy
@ -35,6 +46,7 @@ It is important to note that each component has its own version, for example the
v4.40.0 but another component such as the [Helm Chart](https://charts.authelia.com) version may be v0.9.0.
This means that a breaking change may occur to one but not the other as these components do not share a version.
## Exceptions
There are exceptions to this versioning policy.

View File

@ -35,28 +35,32 @@ authelia crypto certificate ecdsa generate --help
### Options
```
--ca create the certificate as a certificate authority certificate
-n, --common-name string certificate common name
--country strings certificate country
-b, --curve string Sets the elliptic curve which can be P224, P256, P384, or P521 (default "P256")
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration duration duration of time the certificate is valid for (default 8760h0m0s)
--extended-usage strings specify the extended usage types of the certificate
--file.ca-certificate string certificate authority certificate to use when signing this certificate (default "ca.public.crt")
--file.ca-private-key string certificate authority private key to use to signing this certificate (default "ca.private.pem")
--file.certificate string name of the file to export the certificate data to (default "public.crt")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for generate
-l, --locality strings certificate locality
--not-before string earliest date and time the certificate is considered valid formatted as Jan 2 15:04:05 2006 (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
-p, --postcode strings certificate postcode
--province strings certificate province
--sans strings subject alternative names
--signature string signature algorithm for the certificate (default "SHA256")
-s, --street-address strings certificate street address
--bundles strings enables generating bundles options are 'chain' and 'privkey-chain'
--ca create the certificate as a certificate authority certificate
-n, --common-name string certificate common name
--country strings certificate country
-b, --curve string Sets the elliptic curve which can be P224, P256, P384, or P521 (default "P256")
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration string duration of time the certificate is valid for (default "1y")
--extended-usage strings specify the extended usage types of the certificate
--file.bundle.chain string name of the file to export the certificate chain PEM bundle to when the --bundles flag includes 'chain' (default "public.chain.pem")
--file.bundle.priv-chain string name of the file to export the certificate chain and private key PEM bundle to when the --bundles flag includes 'priv-chain' (default "private.chain.pem")
--file.ca-certificate string certificate authority certificate to use when signing this certificate (default "ca.public.crt")
--file.ca-private-key string certificate authority private key to use to signing this certificate (default "ca.private.pem")
--file.certificate string name of the file to export the certificate data to (default "public.crt")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for generate
-l, --locality strings certificate locality
--not-after string latest date and time the certificate is considered valid in various formats
--not-before string earliest date and time the certificate is considered valid in various formats (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
-p, --postcode strings certificate postcode
--province strings certificate province
--sans strings subject alternative names
--signature string signature algorithm for the certificate (default "SHA256")
-s, --street-address strings certificate street address
```
### Options inherited from parent commands

View File

@ -39,12 +39,13 @@ authelia crypto certificate ecdsa request --help
--country strings certificate country
-b, --curve string Sets the elliptic curve which can be P224, P256, P384, or P521 (default "P256")
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration duration duration of time the certificate is valid for (default 8760h0m0s)
--duration string duration of time the certificate is valid for (default "1y")
--file.csr string name of the file to export the certificate request data to (default "request.csr")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for request
-l, --locality strings certificate locality
--not-before string earliest date and time the certificate is considered valid formatted as Jan 2 15:04:05 2006 (default is now)
--not-after string latest date and time the certificate is considered valid in various formats
--not-before string earliest date and time the certificate is considered valid in various formats (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
-p, --postcode strings certificate postcode

View File

@ -35,27 +35,31 @@ authelia crypto certificate ed25519 request --help
### Options
```
--ca create the certificate as a certificate authority certificate
-n, --common-name string certificate common name
--country strings certificate country
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration duration duration of time the certificate is valid for (default 8760h0m0s)
--extended-usage strings specify the extended usage types of the certificate
--file.ca-certificate string certificate authority certificate to use when signing this certificate (default "ca.public.crt")
--file.ca-private-key string certificate authority private key to use to signing this certificate (default "ca.private.pem")
--file.certificate string name of the file to export the certificate data to (default "public.crt")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for generate
-l, --locality strings certificate locality
--not-before string earliest date and time the certificate is considered valid formatted as Jan 2 15:04:05 2006 (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
-p, --postcode strings certificate postcode
--province strings certificate province
--sans strings subject alternative names
--signature string signature algorithm for the certificate (default "SHA256")
-s, --street-address strings certificate street address
--bundles strings enables generating bundles options are 'chain' and 'privkey-chain'
--ca create the certificate as a certificate authority certificate
-n, --common-name string certificate common name
--country strings certificate country
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration string duration of time the certificate is valid for (default "1y")
--extended-usage strings specify the extended usage types of the certificate
--file.bundle.chain string name of the file to export the certificate chain PEM bundle to when the --bundles flag includes 'chain' (default "public.chain.pem")
--file.bundle.priv-chain string name of the file to export the certificate chain and private key PEM bundle to when the --bundles flag includes 'priv-chain' (default "private.chain.pem")
--file.ca-certificate string certificate authority certificate to use when signing this certificate (default "ca.public.crt")
--file.ca-private-key string certificate authority private key to use to signing this certificate (default "ca.private.pem")
--file.certificate string name of the file to export the certificate data to (default "public.crt")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for generate
-l, --locality strings certificate locality
--not-after string latest date and time the certificate is considered valid in various formats
--not-before string earliest date and time the certificate is considered valid in various formats (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
-p, --postcode strings certificate postcode
--province strings certificate province
--sans strings subject alternative names
--signature string signature algorithm for the certificate (default "SHA256")
-s, --street-address strings certificate street address
```
### Options inherited from parent commands

View File

@ -38,12 +38,13 @@ authelia crypto certificate ed25519 request --help
-n, --common-name string certificate common name
--country strings certificate country
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration duration duration of time the certificate is valid for (default 8760h0m0s)
--duration string duration of time the certificate is valid for (default "1y")
--file.csr string name of the file to export the certificate request data to (default "request.csr")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for request
-l, --locality strings certificate locality
--not-before string earliest date and time the certificate is considered valid formatted as Jan 2 15:04:05 2006 (default is now)
--not-after string latest date and time the certificate is considered valid in various formats
--not-before string earliest date and time the certificate is considered valid in various formats (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
-p, --postcode strings certificate postcode

View File

@ -35,28 +35,32 @@ authelia crypto certificate rsa generate --help
### Options
```
-b, --bits int number of RSA bits for the certificate (default 2048)
--ca create the certificate as a certificate authority certificate
-n, --common-name string certificate common name
--country strings certificate country
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration duration duration of time the certificate is valid for (default 8760h0m0s)
--extended-usage strings specify the extended usage types of the certificate
--file.ca-certificate string certificate authority certificate to use when signing this certificate (default "ca.public.crt")
--file.ca-private-key string certificate authority private key to use to signing this certificate (default "ca.private.pem")
--file.certificate string name of the file to export the certificate data to (default "public.crt")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for generate
-l, --locality strings certificate locality
--not-before string earliest date and time the certificate is considered valid formatted as Jan 2 15:04:05 2006 (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
-p, --postcode strings certificate postcode
--province strings certificate province
--sans strings subject alternative names
--signature string signature algorithm for the certificate (default "SHA256")
-s, --street-address strings certificate street address
-b, --bits int number of RSA bits for the certificate (default 2048)
--bundles strings enables generating bundles options are 'chain' and 'privkey-chain'
--ca create the certificate as a certificate authority certificate
-n, --common-name string certificate common name
--country strings certificate country
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration string duration of time the certificate is valid for (default "1y")
--extended-usage strings specify the extended usage types of the certificate
--file.bundle.chain string name of the file to export the certificate chain PEM bundle to when the --bundles flag includes 'chain' (default "public.chain.pem")
--file.bundle.priv-chain string name of the file to export the certificate chain and private key PEM bundle to when the --bundles flag includes 'priv-chain' (default "private.chain.pem")
--file.ca-certificate string certificate authority certificate to use when signing this certificate (default "ca.public.crt")
--file.ca-private-key string certificate authority private key to use to signing this certificate (default "ca.private.pem")
--file.certificate string name of the file to export the certificate data to (default "public.crt")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for generate
-l, --locality strings certificate locality
--not-after string latest date and time the certificate is considered valid in various formats
--not-before string earliest date and time the certificate is considered valid in various formats (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
-p, --postcode strings certificate postcode
--province strings certificate province
--sans strings subject alternative names
--signature string signature algorithm for the certificate (default "SHA256")
-s, --street-address strings certificate street address
```
### Options inherited from parent commands

View File

@ -39,12 +39,13 @@ authelia crypto certificate rsa request --help
-n, --common-name string certificate common name
--country strings certificate country
-d, --directory string directory where the generated keys, certificates, etc will be stored
--duration duration duration of time the certificate is valid for (default 8760h0m0s)
--duration string duration of time the certificate is valid for (default "1y")
--file.csr string name of the file to export the certificate request data to (default "request.csr")
--file.private-key string name of the file to export the private key data to (default "private.pem")
-h, --help help for request
-l, --locality strings certificate locality
--not-before string earliest date and time the certificate is considered valid formatted as Jan 2 15:04:05 2006 (default is now)
--not-after string latest date and time the certificate is considered valid in various formats
--not-before string earliest date and time the certificate is considered valid in various formats (default is now)
-o, --organization strings certificate organization (default [Authelia])
--organizational-unit strings certificate organizational unit
-p, --postcode strings certificate postcode

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