feat: forward auth

[james-d-elliott]

This adds basic support for forwarded authentication similar to caddy and traefik. This replaces Authelia SSO as it effectively covers exactly the same use cases.

[james-d-elliott]

I've drafted this for now as it'd be nice to get some commentary. Specifically surrounding upgrade paths and how you want to handle it, but also on the idea of just dropping a provider specific implementation for Authelia/Authentik etc. The naming will also be super familiar to end users.

If you'd prefer to retain both then I'm up for that too. I have added some TODO items with useful features we should probably add at some point.

Also can't say thanks enough for the initial implementation of the Authelia provider, really helped me on my way to getting to this point.

[tobychui]

@james-d-elliott Cool!

I am currently at work and can't review your work right now, but it seems something is missing from the fork you are editing (regarding the Authentik PR merge).

Could you maybe have a quick check if you have pull the latest commit and merge it into your branch from v3.2.1? This could help prevent future merge conflict.

[james-d-elliott]

Ah yep can do. Didn't realize main wasn't the freshest commit. I'll rebase accordingly.

[james-d-elliott]

This is done. The last commit represents my changes where both Authentik and Authelia are removed, replaced with a single provider compatible with the Caddy/Traefik forward auth implementations. I've yet to test it, but plan to and to add unit testing.

Would also be willing to add an integration suite similar to the other proxies we support (provided we can bootstrap the config with files which I suspect is possible): https://buildkite.com/authelia/authelia/builds/43005

[james-d-elliott]

Sorry about all the changes, after testing there were a few issues. They should all be resolved. The only thing left is functional testing and some unit tests.

[JokerQyou]

Great work! It would be really nice to have a unified forward auth implementation (previously when I worked on the Authentik one I found no spec and can only refer to Caddy for some internal logic).
I currently do not have spare time for code reviewing. But I can test the branch in my LAN infra some days later.

[james-d-elliott]

Thanks for any time you have to spare. Also definitely understandable regarding the lack of a spec. Considering the difficulties that poses it's really impressive. It's something I have personally thought there was value in working on actually.

I helped steer the implementation of the Caddy one, though I would definitely not claim I did most of the work either. This implementation has slightly more standard features the Caddy one (though I would not doubt you can do everything you want) but it should be functionally identical, and should also be functionally identical to the traefik one. I would imagine Authentik has a matching implementation for one of these.

It would be wise to consider the traefik implementation the reference implementation since they were the first to implement it.

[james-d-elliott]

For reference I am not entirely sure how the config file here maps to everything. I suspect that part of this will be wrong in my implementation but I'd like it to be right so I can put it into our E2E/Integration Testing.

[tobychui]

@james-d-elliott That is the endpoint config you are referring. I think the configurations of forward auth should lies outside of the endpoint config (as some kind of global config or being stored in database). The endpoint config should only store which auth types this endpoint should use (e.g. forward auth / basic auth).

I suspect that part of this will be wrong in my implementation

Which part(s) are you referring here? I can take a look real quick.

[james-d-elliott]

I think the typedef.go changes may need a very close look (my gut just tells me something is off there), as well as the typedef315.go file. For reference really early WIP on the Authelia side (mostly scaffolding): authelia/authelia#9306

[james-d-elliott]

Just so it's clear, I'd like to add zoraxy to our CI suite, and programmatically configure endpoints and the SSO without the GUI, if that's possible. There's no rush on this, and if it's not actually possible I can work around it.

[tobychui]

The typdef.go changes seems ok.

The changes you propose will require another new upgrader module (instead of the original typedef315.go, a new one like typedef322.go will be needed to upgrade the config from pre-3.2.2 to 3.2.2 format). The 315.go is for upgrading the config file from pre-3.1.5 to post3.1.5. So this file should not be changed in this PR I think.

I will take some time in the weekend to read all the changes.

[tobychui]

I have read all the changes and it looks good to me.
But since I do not have any forward auth instance for testing, I will first release v3.2.1 before the end of April and merge this into v3.2.2 (for May / June release).

[tobychui]

@james-d-elliott You mind creating a new PR that targets the v3.2.2 branch? I accidentally deleted the v3.2.1 now I cannot reopen this PR...

[james-d-elliott]

Superseded by #646