Important: When using these guides, it’s important to recognize that we cannot provide a guide for every possible
method of deploying a proxy. These guides show a suggested setup only, and you need to understand the proxy
configuration and customize it to your needs. To-that-end, we include links to the official proxy documentation
throughout this documentation and in the See Also section.
Authelia by default only generally provides support for versions of products that are also supported by their respective
developer. As such we only support the versions Traefik officially provides support for. The versions and lifetime
of support for Traefik can be read about in the official
Traefik Deprecation Notices documentation.
It should be noted that while these are the listed versions that are supported you may have luck with older versions.
We can officially guarantee the following verions of Traefik as these are the versions we perform integration testing
with at the current time:
It’s strongly recommended that users setting up Authelia for the first time take a look at our
Get started guide. This takes you through various steps which are essential to
bootstrapping Authelia.
Important: You should read the Forwarded Headers section and this section as part of any proxy configuration.
Especially if you have never read it before.
Important: The included example is NOT meant for production use. It’s used expressly as an example to showcase
how you can configure multiple IP ranges. You should customize this example to fit your specific architecture and needs.
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.
Traefik by default doesn’t trust any other proxies requiring explicit configuration of which proxies are trusted
and removes potentially fabricated headers that are likely to lead to security issues, and it is difficult to configure
this incorrectly. This is an important security feature that is common with proxies with good security practices.
In the example we have four commented lines which configure trustedIPs which show an example on adding the following
networks to the trusted proxy list in Traefik:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
fc00::/7
See the Entry Points documentation for more information.
Traefik utilizes the ForwardAuth Authz implementation. The
associated Metadata should be considered required.
The examples below assume you are using the default
Authz Endpoints Configuration or one similar to the
following minimal configuration:
The examples below also assume you are using the modern
Session Configuration which includes the domain, authelia_url, and
default_redirection_url as a subkey of the session.cookies key as a list item. Below is an example of the modern
configuration as well as the legacy configuration for context.
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. Some of these values can
automatically be replaced with documentation variables.
Documentation Variable Configuration
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 accessible 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 to use that specific domain
This example uses a docker-compose.yml similar to the one above however it has two major differences:
A majority of the configuration is in YAML instead of the labels section of the docker-compose.yml file.
It connects to Authelia over TLS with client certificates which ensures that Traefik is a proxy
authorized to communicate with Authelia. This expects that the
Server TLS section is configured correctly.
The client certificates can easily be disabled by commenting the cert and key options in the http.middlewares
section for the forwardAuth middlewares and the certificates in the http.serversTransports section.
The TLS communication can be disabled by commenting the entire tls section in the http.middlewares section for
all forwardAuth middlewares, adjusting the authelia router in the http.routers section to use the
authelia-net@docker service, and commenting the authelia service in the http.service section.
docker-compose.yml
This file is part of the dynamic configuration and should have the path
${PWD}/data/traefik/config/dynamic/traefik.yml. Please see the Traefik service and the volume that mounts the
${PWD}/data/traefik/config in the docker compose above.
Authelia provides the means to be able to authenticate your first factor via the Proxy-Authorization header, this
is compatible with Traefik.
If you have a use-case which requires the use of the Authorization header/basic authentication login prompt you can
call Authelia’s /api/verify?auth=basic endpoint to force a switch to the Authorization header.
If Traefik and Authelia are defined in different docker compose stacks you may experience an issue where Traefik
complains that: middleware authelia@docker not found.
This can be avoided a couple different ways:
Ensure Authelia container is up before Traefik is started: