On 19/10/2023 21:53, Aleksandar Lazic wrote:

As I'm quite newbie at WASM I will mainly create any "echo all params" file in shell/perl/go/js or any other language and convert it to WASM :-).

Exactly the same here! And that's why it is good. You can "just" pick your favorite one [provided a transpiler exists] and roll with it :-)

Though your point about whether it's a fad or not is fair. It's always hard to say, and borad WASM adoption has been "coming" for a long time already.

Well that's another option to add a c bases wasm runtime into addons directory similar to promex.

Sounds quite reasonable to start with an addon indeed.

Agree that a outh2 filter would be very nice. I have also thought about that but it's not an easy task, at least for me, because the oauth2 flow is quite complex

Implementing the full OAuth2 flow is non-trivial, but also not THAT bad from a client's perspective. It's just (rightfully) out of scope for HAProxy. And it sticking to providing "only" JWT parsing+querying makes a lot of sense.

But nonetheless, at the moment the best option is something like the very popular https://github.com/oauth2-proxy/oauth2-proxy on the side, which doesn't integrate particularly nicely with HAProxy, so being able to bake things in a 3rd-party extension at runtime would be much nicer.

and there are very nice tools out there like keycloak which handles this task very well.

This is a tangent, but I feel compelled to expand on Keycloak a bit.

First, it deserves praise, for being a very mature (and very full-featured) OpenID+SAML+OAuth2+... server. And pretty much the only (mature one) that is also open source and maintained. And even amongst newer ones, the list of similar projects that are "serious" [1] is very short (Ory's suite is essentially the only one I know of at the moment).

Which is why we decided on it and deployed it ourselves a year ago, and have used it ever since.

But there are significant limitations we wish we knew at the time:
- Multi-node session replication (think HAProxy stick-table peering) has reliability issues particularly around rebalancing, causing regular session loss if you depend on it too much (for example with autoscaling) https://github.com/keycloak/keycloak/issues/14040 - There is no such thing as transparent rolling updates. Any update, even minor/patch ones, means disconnecting everyone. (in-memory-only user sessions + versioning of these + no version migration not even for n->n+1) - No public API, so theme-ing means one of these absolutely soul-crushing template systems, or a CSS hackjob full of !important rules - And a lot of "surprising" quirks you just have to know about, because it was clearly meant more for internal corporate use originally

That said, it does work well otherwise, with decent performance even at fairly large scale (400k+ active sessions in a single realm). So it is still a decent solution. I'm just not sure I'd pick it again today if I had to choose.

Tristan

[1]: By serious, I mean intended for usage when malicious clients are not just a theoretical threat. So with a very defensive design, comprehensive error handling that always fails closed, etc. There is an endless list of "friendlier" options if those are not things one desires, and that doesn't make them bad. Tis just a tradeoff.

Reply via email to