Merge remote-tracking branch 'origin/master' into fix-pp-layout
# Conflicts: # internal/suites/utils.gofix-pp-layout
James Elliott
commit
2d30814365
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -25,3 +25,5 @@ authelia-image-dev.tar
|
|||
|
||||
/authelia
|
||||
__debug_bin
|
||||
|
||||
internal/suites/common/pki/ca/ca.private.pem
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# ===================================
|
||||
# ===== Authelia official image =====
|
||||
# ===================================
|
||||
FROM alpine:3.17.1
|
||||
FROM alpine:3.17.3
|
||||
|
||||
ARG TARGETOS
|
||||
ARG TARGETARCH
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -3,10 +3,12 @@
|
|||
</p>
|
||||
|
||||
[](https://buildkite.com/authelia/authelia)
|
||||
[](https://bestpractices.coreinfrastructure.org/projects/7128)
|
||||
[](https://goreportcard.com/report/github.com/authelia/authelia/v4)
|
||||
[](https://github.com/authelia/authelia/releases)
|
||||
[](https://hub.docker.com/r/authelia/authelia/tags)
|
||||
[](https://hub.docker.com/r/authelia/authelia/tags)
|
||||
[](https://github.com/authelia/authelia/releases)
|
||||
|
||||
[](https://aur.archlinux.org/packages/authelia/)
|
||||
[](https://aur.archlinux.org/packages/authelia-bin/)
|
||||
[](https://aur.archlinux.org/packages/authelia-git/)
|
||||
|
|
|
|||
93
SECURITY.md
93
SECURITY.md
|
|
@ -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
|
||||
|
|
|
|||
412
api/openapi.yml
412
api/openapi.yml
File diff suppressed because it is too large
Load Diff
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"`
|
||||
|
|
|
|||
|
|
@ -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{
|
||||
|
|
|
|||
|
|
@ -7,5 +7,5 @@
|
|||
package cmd
|
||||
|
||||
const (
|
||||
versionSwaggerUI = "4.15.5"
|
||||
versionSwaggerUI = "4.18.1"
|
||||
)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
}
|
||||
}
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
canonifyURLs = false
|
||||
baseurl = "https://authelia-staging.netlify.app/"
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
canonifyURLs = false
|
||||
|
|
@ -1,2 +1 @@
|
|||
canonifyURLs = false
|
||||
baseurl = "https://authelia-staging.netlify.app/"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,13 +526,17 @@ 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. |
|
||||
| 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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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)*
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ images: []
|
|||
menu:
|
||||
contributing:
|
||||
parent: "guidelines"
|
||||
weight: 320
|
||||
weight: 350
|
||||
toc: true
|
||||
aliases:
|
||||
- /docs/contributing/style-guide.html
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: "Amir Zarrinkafsh"
|
||||
date: 2022-06-15T17:51:47+10:00
|
||||
draft: false
|
||||
images: []
|
||||
---
|
||||
|
||||
{{< profile-details name="amir-zarrinkafsh" >}}
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: "Clément Michaud"
|
||||
date: 2022-06-15T17:51:47+10:00
|
||||
draft: false
|
||||
images: []
|
||||
---
|
||||
|
||||
{{< profile-details name="clement-michaud" >}}
|
||||
|
|
@ -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" >}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: "Manuel Nuñez"
|
||||
date: 2022-06-15T17:51:47+10:00
|
||||
draft: false
|
||||
images: []
|
||||
---
|
||||
|
||||
{{< profile-details name="manuel-nunez" >}}
|
||||
|
|
@ -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.
|
||||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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,9 +57,14 @@ The following YAML configuration is an example __Authelia__
|
|||
[Apache Guacamole] 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: guacamole
|
||||
description: Apache Guacamole
|
||||
secret: '$plaintext$guacamole_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +60,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: argocd
|
||||
description: Argo CD
|
||||
secret: '$plaintext$argocd_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +62,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: bookstack
|
||||
description: BookStack
|
||||
secret: '$plaintext$bookstack_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +70,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: cloudflare
|
||||
description: Cloudflare ZeroTrust
|
||||
secret: '$plaintext$cloudflare_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
|
|
@ -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
|
||||
|
|
@ -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,9 +81,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: gitea
|
||||
description: Gitea
|
||||
secret: '$plaintext$gitea_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
@ -100,9 +102,9 @@ will operate with the above example:
|
|||
|
||||
## 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
|
||||
|
|
|
|||
|
|
@ -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,9 +73,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: gitlab
|
||||
description: GitLab
|
||||
secret: '$plaintext$gitlab_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +91,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: grafana
|
||||
description: Grafana
|
||||
secret: '$plaintext$grafana_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +64,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: harbor
|
||||
description: Harbor
|
||||
secret: '$plaintext$harbor_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +47,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: vault
|
||||
description: HashiCorp Vault
|
||||
secret: '$plaintext$vault_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -148,14 +210,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 |
|
||||
|:-------------------------------:|:--------------------------------------------------------------:|:-------------------------------------:|
|
||||
| [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
|
||||
[Refresh Token]: https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,9 +69,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: komga
|
||||
description: Komga
|
||||
secret: '$plaintext$komga_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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 |
|
|
@ -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,9 +85,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: nextcloud
|
||||
description: NextCloud
|
||||
secret: '$plaintext$nextcloud_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +64,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: outline
|
||||
description: Outline
|
||||
secret: '$plaintext$outline_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +65,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: portainer
|
||||
description: Portainer
|
||||
secret: '$plaintext$portainer_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +69,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: proxmox
|
||||
description: Proxmox
|
||||
secret: '$plaintext$proxmox_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +73,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: seafile
|
||||
description: Seafile
|
||||
secret: '$plaintext$seafile_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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,9 +67,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: synapse
|
||||
description: Synapse
|
||||
secret: '$plaintext$synapse_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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,9 +69,14 @@ The following YAML configuration is an example __Authelia__
|
|||
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: synology-dsm
|
||||
description: Synology DSM
|
||||
secret: '$plaintext$synology-dsm_client_secret'
|
||||
secret: '$pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng' # The digest of 'insecure_secret'.
|
||||
public: false
|
||||
authorization_policy: two_factor
|
||||
redirect_uris:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -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 >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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 >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -16,16 +16,16 @@ aliases:
|
|||
---
|
||||
|
||||
| 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" %}} |
|
||||
|:---------------------------------------:|:----------------:|:---------------------------------------------------:|:-------------------------------------------------------------------------------------:|:---------------------------------:|:---------------------------------:|
|
||||
| [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 %}} |
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
* 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.
|
||||
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'
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -15,16 +15,16 @@ 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" %}} |
|
||||
|:---------------------------------------:|:-------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------------------------:|:---------------------------------:|:---------------------------------:|
|
||||
| [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 %}} |
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -35,20 +35,24 @@ authelia crypto certificate ecdsa generate --help
|
|||
### Options
|
||||
|
||||
```
|
||||
--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 duration duration of time the certificate is valid for (default 8760h0m0s)
|
||||
--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-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
|
||||
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -35,19 +35,23 @@ authelia crypto certificate ed25519 request --help
|
|||
### Options
|
||||
|
||||
```
|
||||
--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 duration duration of time the certificate is valid for (default 8760h0m0s)
|
||||
--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-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
|
||||
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -36,19 +36,23 @@ authelia crypto certificate rsa generate --help
|
|||
|
||||
```
|
||||
-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 duration duration of time the certificate is valid for (default 8760h0m0s)
|
||||
--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-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
|
||||
--path.ca string source directory of the certificate authority files, if not provided the certificate will be self-signed
|
||||
|
|
|
|||
|
|
@ -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
Loading…
Reference in New Issue