keycloak auth before access to proxied content

[bbrendon]

Hi. Is there a way to get caddy to use keycloak to authenticate before accessing proxied content? Preferably only for the auth portion so that caddy could direct proxy to the content after auth is successful as to not introduce another proxy layer.

I think the term for this is forward auth.

Thanks.

[francislavoie]

Caddy does support forward_auth (Caddyfile directive) — Caddy Documentation but as far as I know Keycloak doesn’t directly support forward auth. You need to use a separate app which provides forward auth support to Keycloak as an intermediary. But with that, it should work.

[helmut72]

Thanks for the info. I’m interested too. What is the name of this intermediary app?

[francislavoie]

I think you can use GitHub - mesosphere/traefik-forward-auth. While it has the name traefik, it should work for Caddy as well, because the way Caddy does forward auth is almost identical to Traefik.

[helmut72]

Thank you. Will try it. It’s not specific for Keycloak, but I only know Authelia and Authentik who supports forward auth and that’s a limited choice.

[helmut72]

Have read about and I don’t trust this middleware. It’s starts with lack of useful documentation and all examples are 3-4 years old for Google, even if they mention in their README that it’s generic. I want to use Zitadel.

Last commit is from mid 2022, but what if they stop again like the ones they forked. Also it’s another peace in the chain, which then becomes more error prone. It’s not any MP3 player software, it’s a peace in the security chain.

Really too bad that some IDPs doesn’t support forward auth and Caddy doesn’t support oauth/oidc.

[francislavoie]

@helmut72

and Caddy doesn’t support oauth/oidc

You can use this plugin which does have OIDC support:

GitHub - greenpau/caddy-security: 🔐 Authentication, Authorization, and...

But we have no plans to have official support in the standard distribution of Caddy. It’s too much of a maintenance burden for us to take on.

Re Zitadel, I asked one of the authors on HN some months ago (on a thread about Keycloak) about Forward Auth support and this is what they said: Keycloak: Open-Source Identity and Access Management | Hacker News

[helmut72]

@francislavoie

Thanks for the answer. Yes, I use caddy-security before Caddy adds forward auth. But there were so many refactorings and changes in caddy-security, where I need to refactor also my configurations, that I was happy just to use forward auth with Authelia.

For my problem/challenge now (to have a perfect homelab), where I now also need saml and unfortunately need to drop Authelia until it supports saml, I remembered caddy-security and spend nearly the whole weekend with caddy-security. But I guess there are some incompatibilities between Zitadel and caddy-security:
“server initialization failed: failed configuring identity provider: failed to fetch jwt keys for OAuth 2.0 authorization server: invalid jwks key: jwks unsupported key usage”

Anyway, I have canceled caddy-security. Compared to this many changes in the past, caddy-security feels nowadays if development is a bit stalled.

Then I searched again for a solution and find your question in Hacker News. After the answer from Zitadel I felt struggled in a dead end street:
Zitadel don’t want to have forward auth, Caddy don’t want to have oauth/oidc.

Then I think again if I really do it the right way and if a reverse proxy is the right place for managing authentication for apps, that don’t support oidc or saml (*). There are a lot of apps out there who supports oidc/saml directly and it’s only some old/“legacy” apps or apps from small projects, where there is something like a header based auth.

After my brainstorming I decided that the authentication process belongs to the app itself.

Then I have tried another peace of software (oauth2-proxy) and compared to caddy-security, it worked after 20min with Zitadel. So I will either prepend oauth2-proxy in the docker-compose for apps, that don’t use Apache or use the oidc module in Apache. OIDC module for Apache need to be tested next days, but development and community looks good.

The only thing what could happen with oauth2-proxy are 2 IP addresses in x-forwarded-for and the app behind shows the “wrong” IP in their log. Apache shouldn’t be a problem.

Thanks for your input, where I find a suitable solution for me.

*) It’s the same question I had in the past: do I use Caddy (or Apache/Nginx) for the webserver part too for some apps, when this instance of Caddy is just meant to be a reverse proxy or not?

I also decided here that a reverse proxy is a reverse proxy and not the webserver for an app, if an app requires a webserver (eg. LAMP stacks), because if the reverse proxy do the webserver part too, the app is too much “glued” to the reverse proxy.

[bbrendon]

Great discussion. Thank you. I think the path of least resistance for the future is to migrate to Authentik. Now that it’s more legit I feel more confident about it sticking around. I’ll be trying caddy with that instead of Keycloak.