mod_auth_openidc

y-core-rule-set/ With Nginx that is no longer properly supported and needed their Plus version anyways: https://docs.nginx.com/nginx-waf/admin-guide/nginx-plus-mods... sudo apt-get install nginx-plus-module-modsecurity If I want to do that myself with the regular Nginx, I suddenly have to compile a bunch of stuff myself, which becomes far less pleasant and a bit more long winded: https://www.linode.com/docs/guides/securing-nginx-with-modse... sudo apt-get install bison build-essential ca-certificates curl dh-autoreconf doxygen \ flex gawk git iputils-ping libcurl4-gnutls-dev libexpat1-dev libgeoip-dev liblmdb-dev \ libpcre3-dev libpcre++-dev libssl-dev libtool libxml2 libxml2-dev libyajl-dev locales \ lua5.3-dev pkg-config wget zlib1g-dev zlibc libxslt libgd-dev sudo apt install git cd /opt && sudo git clone https://github.com/SpiderLabs/ModSecurity cd ModSecurity sudo git submodule init sudo git submodule update sudo ./build.sh sudo ./configure sudo make sudo make install cd /opt && sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git cd /opt && sudo wget http://nginx.org/download/nginx-1.14.0.tar.gz sudo tar -xvzmf nginx-1.14.0.tar.gz cd nginx-1.14.0 sudo ./configure --add-dynamic-module=../ModSecurity-nginx <Configure Arguments> sudo make modules sudo mkdir /etc/nginx/modules sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules (old versions in the example, but same principle) At that point I might as well look in the direction of OWASP Coraza: https://coraza.io/ When it comes to ACME and Let's Encrypt, I can use mod_md out of the box with Apache: https://httpd.apache.org/docs/2.4/mod/mod_md.html It's experimental but works nicely in my experience, whereas with Nginx, I have to go with Certbot separately: https://certbot.eff.org/ If I want everything in a single package, I can just use Caddy instead (which is a lovely web server). And that's before I get into weird Nginx behavior when I try to use it with containers, where the whole web server crashes, just because it cannot find the DNS record for a container that hasn't been created yet, along the lines of: nginx: [emerg] host not found in upstream "my-app" where trying to use the suggested fix leads to: nginx: [emerg] "proxy_redirect default" cannot be used with "proxy_pass" directive with variables and using other values often breaks app redirects. Due to these experiences, I'll absolutely say that you can do more with Apache, in ways that will be less of a pain, except for the whole "getting your entire web server hacked" or "brought down by any sizeable amount of traffic" bit. Nginx is really good for hosting static content or acting as a basic reverse proxy, but will be harder to get various bits of the greater ecosystem into it, as opposed to how Apache works. Then again, I fully acknowledge that someone will come along and say "ModSecurity isn't very useful, you should just put your site behind Cloudflare if you need a WAF." or maybe even "Don't handle OpenID Connect in your ingress, even if that means that in the case of 5 APIs you'll need OIDC libraries and configuration for each of them, which will look quite different in various languages." but that doesn't change the fact that some things are just more doable in one option instead of another. OpenResty or Caddy increasingly feel like better choices for a lot of stuff, but not bare Nginx. Use Nginx when you want to handle simple use cases (reverse proxy, serving static files) with good performance, security and a sane configuration format.

me time self-hosting is nice and I don't have anything too precious on those servers that a sub-optimal WAF would cause me that many headaches. I guess it's cool that I can, even down to decent rulesets: https://owasp.org/www-project-modsecurity-core-rule-set/ though the OWASP Coraza project also seems nice: https://coraza.io/

f 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 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-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 (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

permissions and other custom attributes. It's on par with what you'd expect and should serve you nicely. mod_auth_openidc: https://github.com/OpenIDC/mod_auth_openidc This one's a certified OpenID Connect Relying Party implementation for... Apache2/httpd. Some might worry about the performance and there are other options out there (like a module for OpenResty, which is built on top of Nginx), but when coupled with mod_md Apache makes for a great reverse proxy/ingress for my needs. The benefit here is that I don't need 10 different implementations for each service/back end language that's used, I can outsource the heavy lifting to mod_auth_openidc (protected paths, needed roles/permissions, redirect URLs, token renewal and other things) and just read a few trusted headers behind the reverse proxy if further checks are needed, which is easy in all technologies. That said, the configuration there is also hard and annoying to do, as is working with OpenID Connect in general, even though you can kind of understand why that complexity is inherent. Here's a link with some certified implementations, by the way: https://openid.net/developers/certified-openid-connect-imple... Please don't write your security code from scratch and lean in the direction of just gluing various tested options together.

to the protected resources: https://github.com/OpenIDC/mod_auth_openidc It works, but I'm still not happy - I realize that there are many types of attacks that have historically been a problem and that certain OpenID Connect flows try to protect against, in addition to the fact that if I wrote my own security code it'd almost certainly be worse and have vulnerabilities (in the words of Eoin Woods: "Never invent security technology"), and it's a good thing to follow standards... but the whole thing is such a pain. Both OpenID Connect, Keycloak and configuring mod_auth_openidc. Right now I'm moving permissions/roles back into the app DB, because I don't want to have to work with the Keycloak REST API every time I want to change what a user can or cannot do in the system, in addition to permissions which might only apply conditionally (one user might be related to multiple organizations, having different permissions in the context of each). Regardless, it's nice that there are more pieces of software out there to choose from! Do manage your expectations when working with OpenID Connect, though.

ou need to handle authentication, plus you get automatic security updates for your authentication flow in case something happens. There's a reason Okta and its competitors are selling auth as a service: doing auth yourself properly is a massive pain that you need to stay on top of. You need to set up secure hashes, integrate TOTP/FIDO2 with appropriate recovery mechanisms, set up login flows, deal with session expiration, and all that stuff, when all you want is "give me a user ID so I know what data to load". These systems are annoying to develop against (though plenty of libraries are available to do the hard parts for you) but they're great if you just want to secure a backend or web application. I don't know why you needed two extra assertions when you were already authenticated, though. That's sounds like bad integration to me.

's actually cool that there are plentiful options in the space, since OIDC is pretty complex in of itself and attempts at creating something pleasant to actually use are always welcome, I've also heard good things about Authentik: https://goauthentik.io/

int of failure for handling the authentication. A caveat might be that in practice people who try to use mTLS for app development shoot themselves in the foot, because that doesn't play nicely with reverse proxies etc. Oh and also, to reduce needless disk IO, using a single config file approach as opposed to .htaccess can make Apache a bit more performant and easier to reason about: https://httpd.apache.org/docs/current/mod/core.html#allowove...

y single one of my sites, here's a quick look into some common configurations: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-... Let me give you a few examples (if you think these are silly, my summary is at the bottom): > Service discovery Docker actually provides you with DNS out of the box, so your web server can easily refer to services, like such: ProxyPass "/" "http://my_application:80/" More information: https://docs.docker.com/network/ > Load balancing The above will also distribute the traffic based on how many instances you have running, from as many web servers as you have running. Throw in health checks (such as the container running curl against itself, to check that the API/web interface is available when starting up, as well as periodically during operation) so no traffic gets routed before your application can receive them and you're good for the most part: https://docs.docker.com/engine/swarm/services/#publish-ports > TLS encryption Let's Encrypt as well as your own custom certificates are supported by most web servers out there rather easily, even Apache now has mod_md for automating this: https://httpd.apache.org/docs/trunk/mod/mod_md.html Also, if you want, you can encrypt the network traffic between the nodes as well and not worry about having to manage the internal certificates manually either: https://docs.docker.com/engine/swarm/networking/#customize-a... > Authentication and authorization Once again, web servers are pretty good at this, you can configure most forms or auth easily and even the aforementioned Apache now has mod_auth_openidc which supports OpenID Connect, so you can even configure it to be a Relying Party and not worry as much about letting your applications themselves manage that (given that if you have 5 different tech stacks running, you'd need 5 bits of separate configuration and libraries for that): https://github.com/zmartzone/mod_auth_openidc > Metrics aggregation, such as request throughput and response time, Distributed tracing This might be a little bit more tricky! The old Apache outputs its server status with a handler that you can configure (see a live example here: https://issues.apache.org/server-status ) thanks to mod-status: https://httpd.apache.org/docs/2.4/mod/mod_status.html and there's similar output for the ACME certificate status as well, which you can configure. The logs also contain metrics about the requests, which once again are configurable. Other web servers might give you more functionality in that regard (or you might shop around for Apache modules), Traefik, Caddy as well as Nginx Proxy Manager might all be good choices both when you're looking to hook up for something external to aggregate the metrics with minimal work, or want a dashboard of some sort, for example: https://doc.traefik.io/traefik/operations/dashboard/ > Rate limiting In Apache, it's a bit more troublesome (other servers do this better most of the time), depending on which approach you use, but something basic isn't too hard to set up: https://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html > Routing and traffic management, Traffic splitting, Request retries I'm grouping these together, because what people expect from this sort of functionality might vary a lot. You can get most of the basic stuff out of most web servers, which will be enough for the majority of the web servers out there. Something like blue/green deployments, A/B testing or circuit breaking logic is possible with a bit more work, but here I'll concede that for the more advanced setups out there something like Istio and Kiali would be better solutions. Then again, those projects won't be the majority of the ones out there. > Error handling Depends on what you want to do here, custom error pages (or handlers), or something in regards to routing or checking for the presence of resources isn't too hard and has been done for years. Summary: But what's my point here? Should everyone abandon using Linkerd or Istio? Not at all! I'm just saying that even with lightweight technologies and for simpler tech stacks, having and ingress as well as something that covers most of what a service mesh would (e.g. the aforementioned Docker overlay networking, or similar solutions) can be immensely useful. After putting Nginx in front of many of the services for projects at work, path rewriting, as well as handling special rules for certain apps has become way easier, certificate management is a breeze since it can be done with Ansible just against a single type of service, in addition to something like client certs or OIDC (though admittedly, that's mostly on my homelab, with Apache). Once you actually grow past that, or have your entire business built on Kubernetes, then feel free to adopt whatever solutions you deem necessary! But don't shy away from things like this even when you have <10 applications running in about as many containers (or when you have some horizontal scalability across your nodes). Note: you can still have HAProxy or some fancy WAF solution for your org, or anything of that sort as well - I was talking more about the scale of individual projects/applications here. It's really nice that you can layer whatever you need.