New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(server): trusted header authentication #8778
base: main
Are you sure you want to change the base?
Conversation
What is the use-case or problem solved by this? What are the security implications, for example if a potentially malicious client has the ability to set this header themselves? |
One use case is to use with reverse proxy and dedicated IAM. For example, Caddy as reverse proxy, and authelia/authentik/keyclock as IAM. See:
There are some other use cases of having auth header as well #1604, though I may misunderstand what the OP means.
The implication would be that the operator of the stack (proxy, IAM server, and immich), if choosing to use this feature, must configure correctly, for example, https://www.authelia.com/integration/trusted-header-sso/introduction/#trusted-remote-networks . That is, if the operator blindly set IMMICH_TRUSTED_REMOTE_NETWORKS, and the proxy does not use IAM or sanitize On the other hand, be default, this feature is not enabled, and if the malicious client set the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can add this feature, but can you clean up the pull request before I look at it?
- All the automated checks are failing
- There is a describe.only block
- The web changes likely don't work in the production build (env variables don't mean anything for a static build).
- Like all other auth settings, this should be system config instead of an environment variable.
- You should add an e2e test for this feature
I don't really see a case for this feature. Authentication via external IAM is already better covered with the existing oauth implementation, and the request in #1604 is not solved here - that request is for the ability to configure a header inside of the mobile app. |
@truongsinh - can you explain why you would need to use this authentication mechanism over the already existing OAuth implementation and integration? Does that also not allow external IAM via authelia/authentik/keyclock? |
While Immich already supports OAuth, trusted header authentication presents unique advantages for our self-hosted community. This method allows seamless integration into personal network setups with reverse proxies that handle authentication, enhancing user convenience significantly.
Given we're discussing the need of trusted auth header, I'll hold off for now. If there is a consensus, I'll continue to address all the comment above (btw I'm a little embarrassed about having |
This PR implements trusted header authentication
To quote from https://www.authelia.com/integration/trusted-header-sso/introduction/
API test included.
To use it:
IMMICH_TRUSTED_REMOTE_NETWORKS
must be set, for example "10.3.3.0/24, fd00:3::/32, 172.3.4.0/24, 172.3.2.0/24"remote-email
(note, email, not user) must exist in the HTTP request.