public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-15 18:56:24 +00:00
Code Issues Releases Wiki Activity

Add Immich review

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2022-08-04 12:26:52 +12:00
parent d0aa79dd2e
commit fdbf331ea7
32 changed files with 254 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
manuscript/docker-swarm/traefik-forward-auth/index.md
View File

@@ -23,7 +23,7 @@ This is the role of Traefik Forward Auth.
When employing Traefik Forward Auth as "[middleware](https://doc.traefik.io/traefik/middlewares/forwardauth/)", the forward-auth process sits in the middle of this transaction - traefik receives the incoming request, "checks in" with the auth server to determine whether or not further authentication is required. If the user is authenticated, the auth server returns a 200 response code, and Traefik is authorized to forward the request to the backend. If not, traefik passes the auth server response back to the user - this process will usually direct the user to an authentication provider (*[Google][tfa-google], [Keycloak][tfa-keycloak], and [Dex][tfa-dex-static] are common examples*), so that they can perform a login.
Illustrated below:
![Traefik Forward Auth](../../images/traefik-forward-auth.png){ loading=lazy }
![Traefik Forward Auth](/images/traefik-forward-auth.png){ loading=lazy }
The advantage under this design is additional security. If I'm deploying a web app which I expect only an authenticated user to require access to (*unlike something intended to be accessed publically, like [Linx][linx]*), I'll pass the request through Traefik Forward Auth. The overhead is negligible, and the additional layer of security is well-worth it.