6 ms·
> There is no standard, really, for identity aware proxies, and therefore no way for an app to recognize a standard token. How crazy is using the HTTP REMOTE_U
by cdcarter 6y ago
> There is no standard, really, for identity aware proxies, and therefore no way for an app to recognize a standard token.
How crazy is using the HTTP REMOTE_USER header for this?
- jrockway 6y agoIt's fine, but you need network layer authentication and authorization. You don't want someone with network access to be able to act as any user -- i.e `kubectl port-forward important-app 80; curl -H "Remote-User: the-ceo@you.io" -X DELETE localhost/fire-all-employees` So you need some way for important-app to be able to recognize that the remote-user header is valid. You can use mTLS and make important-app reject connections from anything that doesn't present your proxy's client certificate. You can sign the header. The header signing is pretty popular; google's Identity Aware Proxy sends a JWT there. I have written an auth system that's done this twice. For the first iteration I used JWT. For jsso2 I use a PASETO-signed protocol buffer. Neither of these implementations has any support in the wild, so whatever you choose, you will be modifying the code of every app you run. There is some support in the open-source world for your suggestion; there are many pieces of OSS that support a raw username in a header. Grafana does, Dex does (allowing you to pretend this is all OIDC for apps that don't support headers). But... it's pretty insecure. It means that you trust anyone who can run apps in production or access the network to act as any human user. No serious company would accept that; you can't let random engineers pretend to be the CEO in the HR system. (That's another argument against self-hosting auth; insider risk is higher.)