8 ms·

I did something similar, though picked Apache with mod_auth_openidc, which is a certified Relying Party implementation: https://github.com/OpenIDC/mod_auth_open

I did something similar, though picked Apache with mod_auth_openidc, which is a certified Relying Party implementation: https://github.com/OpenIDC/mod_auth_openidc https://github.com/OpenIDC/mod_auth_openidc In other words, I can protect arbitrary applications through my reverse proxy and require either certain claims/roles, or simplify auth to the point where my downstream app/API will just receive a bunch of headers like OIDC_CLAIM_sub, OIDC_CLAIM_name, OIDC_CLAIM_email through the internal network, not making me bother with configuring OIDC libraries for all of my APIs and configure them in each stack that I might use, but rather contain all of that complexity in the reverse proxy. Handling headers in pretty much every stack is trivial, be it something with .NET, Java, Node, Python and so on... Basically: user <==> Apache (with mod_auth_openidc) <==> API (with OIDC_ headers, if logged in and authorized) OR <==> Keycloak (for logging in/registration, followed by redirect) Apache probably isn't the ideal tool for this, but was definitely the easiest to setup and also has mod_md nowadays, making renewing SSL certs (with HTTP-01, at least) closer to how Caddy might do it, I don't even need certbot: https://httpd.apache.org/docs/trunk/mod/mod_md.html https://httpd.apache.org/docs/trunk/mod/mod_md.html Now, right now I'm moving away from storing groups in the Keycloak DB because it's actually easier to do that in the app DB and only allow Keycloak to reason about who users are, not what they can do (since interacting with Keycloak's API to manage users is cumbersome), especially when I want custom permissions: like users being assigned to companies, but also having specific permissions for each of those companies, your typical granular system. Personally, I'd definitely say that OIDC feels overcomplicated to work with, so I'm glad that I discovered something like this. There's a whole list of other Relying Party implementations, but nobody really seems to be talking about them: https://openid.net/developers/certified-openid-connect-implementations/ https://openid.net/developers/certified-openid-connect-imple... Also, in regards to Keycloak in particular, most likely you really want to build the "optimized" image, because otherwise the startup times will be annoyingly long: https://www.keycloak.org/server/containers https://www.keycloak.org/server/containers (like the article already points out, but that was a pain point until I got it over with) Oh, and Keycloak is known to be a bit odd in how it sometimes works behind a reverse proxy, I actually needed to put this in the configuration because otherwise connections would sometimes break: SetEnv proxy-initial-not-pooled 1 SetEnv proxy-nokeepalive 1

victor106 3y ago
This is interesting. Thanks for sharing.
mooreds 3y ago
> Now, right now I'm moving away from storing groups in the Keycloak DB because it's actually easier to do that in the app DB and only allow Keycloak to reason about who users are, not what they can do (since interacting with Keycloak's API to manage users is cumbersome), especially when I want custom permissions: like users being assigned to companies, but also having specific permissions for each of those companies, your typical granular system. Have you thought about extracting your authorization to a separate server? It might be overkill if you only have one application, but I've seen demos/had conversations with the folks at cerbos and permit, which both offer open source authorization as a service. That way your user authentication is done by Keycloak, your authorization is done by cerbos/permit/etc, and your application only is responsible for application data/functionality.

victor106 3y ago

This is interesting. Thanks for sharing.

mooreds 3y ago

> Now, right now I'm moving away from storing groups in the Keycloak DB because it's actually easier to do that in the app DB and only allow Keycloak to reason about who users are, not what they can do (since interacting with Keycloak's API to manage users is cumbersome), especially when I want custom permissions: like users being assigned to companies, but also having specific permissions for each of those companies, your typical granular system. Have you thought about extracting your authorization to a separate server? It might be overkill if you only have one application, but I've seen demos/had conversations with the folks at cerbos and permit, which both offer open source authorization as a service. That way your user authentication is done by Keycloak, your authorization is done by cerbos/permit/etc, and your application only is responsible for application data/functionality.