11 KiB
title | description | lead | date | draft | images | menu | weight | toc | aliases | |||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SWAG | An integration guide for Authelia and the SWAG reverse proxy | A guide on integrating Authelia with SWAG. | 2022-06-15T17:51:47+10:00 | false |
|
351 | true |
|
SWAG is a reverse proxy supported by Authelia. It's an NGINX proxy container with bundled configurations to make your life easier.
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.
Introduction
As SWAG is a NGINX proxy with curated configurations, integration of Authelia with SWAG is very easy and you only need to enabled two includes.
Note: All paths in this guide are the locations inside the container. You will have to either edit the files within the container or adapt the path to the path you have mounted the relevant container path to.
Get Started
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.
Requirements
SWAG supports the required NGINX requirements for Authelia out-of-the-box.
SWAG Caveat
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.
There are two potential ways to achieve this:
- Adjust the default
authelia-server.conf
as per the included directions. - 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 tohttps://app.example.com
(if they visithttps://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 as the
issuer
will behttps://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
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
.
## 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;
## 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 guide (which can be used with SWAG) and run Authelia as it's own subdomain.
Trusted Proxies
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.
To configure trusted proxies for SWAG see the NGINX section on 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 port9091
- 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
- You will have to adapt all instances of the above URL to be
- 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.
It uses the nginx image from [linuxserver.io] which includes all of the
required modules including the http_set_misc
module.
It also includes the nginx-proxy-confs mod where
they have several configuration examples in the /config/nginx/proxy-confs
directory. This can be omitted if desired.
If you're looking for a more complete solution [linuxserver.io] also have an nginx container called SWAG which includes ACME and various other useful utilities.
{{< details "docker-compose.yaml" >}}
---
version: "3.8"
networks:
net:
driver: bridge
services:
swag:
container_name: swag
image: lscr.io/linuxserver/swag
restart: unless-stopped
networks:
net:
aliases: []
ports:
- '80:80'
- '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'
TZ: 'Australia/Melbourne'
URL: 'example.com'
SUBDOMAINS: 'www,whoami,auth,nextcloud,'
VALIDATION: 'http'
CERTPROVIDER: 'cloudflare'
ONLY_SUBDOMAINS: 'false'
STAGING: 'true'
cap_add:
- NET_ADMIN
authelia:
container_name: authelia
image: authelia/authelia
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 9091
volumes:
- ${PWD}/data/authelia/config:/config
environment:
TZ: 'Australia/Melbourne'
nextcloud:
container_name: nextcloud
image: lscr.io/linuxserver/nextcloud
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 443
volumes:
- ${PWD}/data/nextcloud/config:/config
- ${PWD}/data/nextcloud/data:/data
environment:
PUID: '1000'
PGID: '1000'
TZ: 'Australia/Melbourne'
whoami:
container_name: whoami
image: docker.io/traefik/whoami
restart: unless-stopped
networks:
net:
aliases: []
expose:
- 80
environment:
TZ: 'Australia/Melbourne'
...
{{< /details >}}
Prerequisite Steps
In the SWAG /config
mount which is mounted to ${PWD}/data/swag
in our example:
- Create a folder named
snippets/authelia
:- The
mkdir -p ${PWD}/data/swag/nginx/snippets/authelia
command should achieve this on Linux.
- The
- Create the
${PWD}/data/swag/nginx/snippets/authelia/location.conf
file which can be found here. - Create the
${PWD}/data/swag/nginx/snippets/authelia/authrequest.conf
file which can be found here.- Ensure you adjust the line
error_page 401 =302 https://auth.example.com/?rd=$target_url;
replacinghttps://auth.example.com/
with your external Authelia URL.
- Ensure you adjust the line
Protected Application
In the server configuration for the application you want to protect:
- Edit the
/config/nginx/proxy-confs/
file for the application you wish to protect. - Under the
#include /config/nginx/authelia-server.conf;
line which should be within theserver
block but not inside anylocation
blocks add the following line:include /config/nginx/snippets/authelia/location.conf;
. - Under the
#include /config/nginx/authelia-location.conf;
line which should be within the applicationslocation
block add the following lineinclude /config/nginx/snippets/authelia/authrequest.conf;
.
Example
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name whoami.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
# Authelia: Step 1.
#include /config/nginx/authelia-server.conf;
include /config/nginx/snippets/authelia/location.conf;
location / {
# Authelia: Step 2.
#include /config/nginx/authelia-location.conf;
include /config/nginx/snippets/authelia/authrequest.conf;
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_app whoami;
set $upstream_port 80;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}