Upstream dropped LDAP support with v5.7.0

[nebulon]

Just to inform users here about the upcoming Firefly III v5.7.0 having dropped LDAP support in favor of a future support via generic auth proxy.

Currently this is unclear to us if this already works or what exactly is meant by this. Also we have to see what will happen during a migration with the previously known LDAP users and if they can become local users automatically.

If anyone here knows more about the generic auth proxy in Laravel, it would be great to collect some potential solutions.

[nebulon]

We have release a new major version package due to the LDAP change in upstream Firefly.
Once the app is updated, all users have to reset their passwords using the password reset flow and the email address from the Cloudron user profile (as that was set previously with LDAP)
If that email address for some reason is different, open a webterminal into the app and run the following commands to get the list of addresses known in Firefly:

php artisan db
> SELECT email FROM users;

If any issues arise, you can always restore to the previous version for a start to get back to working state. Then raise the issue in this thread, so we can debug the situation.

[infogulch]

Could we switch to using proxyAuth instead? Perhaps with some small enhancements?

I see that you guys are already on the case at issue #5847. It seems like a small addition to the proxyAuth addon would enable it to authenticate users for firefly iii:

• The addon should indicate the authenticated user making the request to the app in headers like "Remote-User" and "Remote-Email", these headers should be configurable via proxyAuth configuration.
• The addon should filter these headers from the external request so they can't be spoofed.
• Configure the app to use these headers by setting AUTHENTICATION_GUARD* environment variables as indicated by the author.

[nebulon]

@infogulch that's an interesting take on the auth here. Currently the proxyAuth addon does not set such headers, but this might be indeed very useful.

[infogulch]

This is my preferred way to do auth in general. The biggest benefits to this design are 1. it's dead simple to consume authorization as the application, 2. it never touches any secrets so there's no opportunity for the application to mishandle it (like accidentally logging a password), and 3. the proxy prevents all unauthorized requests from reaching protected paths at all, reducing the scope of application vulnerabilities at those paths to attackers who also have an account on your cloudron.

[infogulch]

Just to connect things, this is what I was aiming at in the proxyAuth addon thread.

Cloudron uses the ngx_http_auth_request_module to forward auth requests to the /http-auth route, then to 127.0.0.1:3001/auth . See: https://git.cloudron.io/cloudron/box/-/blob/master/src/nginxconfig.ejs#L292

I found this article that describes how to configure nginx and the auth server to provide the user back to the app by using the X-Forwarded-User header: https://redbyte.eu/en/blog/using-the-nginx-auth-request-module/

This is the same strategy used by Firefly III in #5847.

I think we could reenable authentication in firefly iii (and other apps that use this authentication stragegy) with the addition of a few headers returned by the service at :3001 and in the nginx config. I think defaulting to hard-coded X-Forwarded-User would be a good starting place.

[girish]

@infogulch thanks for this! I have implemented the proxy headers for the next release - https://git.cloudron.io/cloudron/box/-/commit/c63709312d3f774f5695396aa019a25a7a537250 . Tested against firefly and it works well!

[infogulch]

@girish Wow that's great! Thanks for implementing this, I hope that it can be used for other apps in the future.

Did you happen to check whether the x-forwarded-* headers are stripped from the original request? Theres a potential impersonation vuln if we're not careful with these headers in particular.

[girish]

@infogulch said in Upstream dropped LDAP support with v5.7.0:

Did you happen to check whether the x-forwarded-* headers are stripped from the original request? Theres a potential impersonation vuln if we're not careful with these headers in particular.

Right... The headers are always set/cleared across all locations in the nginx proxy auth config. It's in our e2e tests as well (though they have not passed yet).