By following instructions on forward_auth (Caddyfile directive) — Caddy Documentation to integrate Caddy reverse proxy with Authelia via forward_auth, https://www.company.com/api/*****, protected resources will be redirected to https://auth.company.com where Authenlia is deployed. After a successful authentication with Authenlia, I’d like to generate a brand new Caddy Session ID to be returned to user browsers and I’d like to add some logics:
if there exists a valid Caddy SessionID for requets https://www.company.com/api/*****? If NO, then forward_auth; If YES, directly route requests to my application server backend for those /api/****
when there exists NO valid Caddy Session ID, AND forward_auth has returned 2XX response, the Caddy will generate a brand new Caddy Session ID
at this moment, I need to generate some internal session data and store them as session attributes for this newly generated Caddy Session ID. Pls keep in mind, there are session attributes only available on the server side. In brief, like the Java HttpSession.setAttribute(String key, String value) method
2. Error messages and/or full log output:
N/A
PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.
3. Caddy version:
the latest
4. How I installed and ran Caddy:
a. System environment:
b. Command:
PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.
c. Service/unit/compose file:
PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.
d. My complete Caddy config:
PASTE OVER THIS, BETWEEN THE ``` LINES.
Please use the preview pane to ensure it looks nice.
If you’re using Authelia, then it’s setting a cookie after successful authentication so that subsequent requests can skip the expensive auth checks and just get passed through.
Why do you need an additional mechanism? If you need to pass through information from Authelia to your app, then use copy_headers to pass it response headers from Authelia as request headers to your backend.
@francislavoie Thanks for your help! However, IMHO, the Authelia (auth.mycompany.com) works as an “external” Identity Provider for my web apps sitting behind our reverse proxy, Caddy, e.g. www.mycompany.com/facebook/, www.mycompany.com/tiktok/, that is, having context-path based routing with Caddy. the generated authelia_session is only for the authenticating purpose with that particular IdP or authenticator. In practice, we could switch from Authelia to KeyCloak, Okta. We should have our own dedicated SessionID for www.mycompany.com between user browser and our reverse proxy, Caddy, with which we could decide how this session should be managed based on our own security requirements, such as Session Inactive Timeout, Session Max Timeout, HttpOnly, SameSite etc, or our own countermeasures for possible Session Fixation. Keeping our Caddy dedicated web apps session could bring us such benefits:
1. checking locally on reverse proxy if there exists such a Caddy session cookie for each incoming request is easier, more resource efficient than forward_auth/reverse_proxy it to the external IdP (extra TCP Handshaking, TLS connection between Caddy and the Authelia)
2. keeping such a Caddy session could enhance security posture for our web apps behind the Caddy reverse proxy, for instance, we could set life time for the authelia_session cookie as short as possible, i.e 5 minutes, which would make our IdP almost immediately unavailable for threat actors after successful authentication, reducing exposure of possible attack surfaces associated with Authelia, that is, possible supply chain vulnerabilities
3. using such a Caddy session can easily realizing/implementing Single Sign On between our web apps under the exact same domain, www.mycompany.com, furthermore, the authelia_session is by default created for top domain mycompany.com, that is, valid for all sub domains, *.mycompany.com, which will cetainly result in trouble, such as broken access control, for other web apps residing under other sub domain, such admin.mycompany.com/crm
4. having such a Caddy session with possible session attributes on reverse proxy side could make our protected web apps independent from the concret IdP, the concrete authentication method used during the initial session evaluation process,
In that case, that’s an application-level concern, it doesn’t have anything to do with Caddy. Your app should write the cookie, Caddy will proxy it along as normal.
It doesn’t sound like a good idea for each individual web app sitting behind the Caddy reverse proxy that is integrated with an authentication Gateway to have to write cookies and handle session management respectively. Ideally speaking, those concerned web apps in the abovementioned scenario could be stateless and session management, authentication are handled in one single place, reverse proxy, which is the biggest benefits, IMO
this is a screenshot of Logs of Authelia docker container showing the authelia authentication proxy has verified each individual request although the user has already been authenticated/identified because the frontend of the web app has a timer that periodically execute ajax call of https://traefik.ciso.com/api/overview (local hostname) every second. If the reverse proxy were to have its own session cookie, it would know the current user session is valid, and would NOT establish new TLS connection to Authelia for verifying this incoming request
Personally, I think that is very much the intended behaviour of a forward-auth IAM server and well within the capabilities of its design and implementation and there are security concerns when it comes to offloading this to Caddy itself.
I have to question whether this is simply a case of massively premature optimisation. Are these requests really causing any concern at all, other than extra logs you can filter out? Is this really a problem that requires solving? It really doesn’t seem to me like it is.
But if you’re sure it is a problem for you, and you’re sure you want to offload this responsibility from Authelia to Caddy itself - that’s your prerogative. But your question at the start of the thread was, how can Caddy handle this for you?
And the answer is that, unfortunately, it can’t right now. There is no functionality in Caddy currently which can implement the specific logic you’ve requested. You would need to write a custom module to extend Caddy with this functionality. There are no standard modules which can be configured to generate this secondary session ID at the reverse-proxy layer.
