Keycloak – Open-source identity and access management interview
console.substack.com
console.substack.com
But as I somehow ended up being the de-facto responsible person for all things related frontend, I find that Keycloak is lacking some stuff there. My biggest problem at the moment is that you can’t add an endpoint + new page next to your login/registration process. For example, I now need to add a page that explains what data protection measures we take. My only easy option is to add a normal HTML page and link to it, but then it doesn’t inherit from my template and I have to maintain this file separately. Otherwise I have to extend Keycloak’s functionality to register an endpoint myself and then point this endpoint to a method that reads my ftl template and parses it.
Apart from that, I’ve been struggling with UI changes that made once straight forward functionality hard to work with. For example role assigning inside a client, which is now hidden behind multiple screens, where before it was a matter of picking a user and client and just arranging the roles.
I feel like there’s a good need for a UX expert in the team because it seems that Keycloak is becoming one of those pieces of software we pay consultants to come and explain to us, because it is cheaper than us doing it by reading the manual and trying different combinations
( We offer consultancy for this..., info@actidoo.com )
I’ve also found this solution in the past, but it is too complex for me. Just to define a page, I would write an SPI, do a config in the admin panel and the corresponding documentation I would need to write for my colleagues. One of those is bound to get forgotten and not get updated, which brings me to square one, keeping a HTML file updated.
That’s why I would prefer a solution in which I register the endpoint programmatically and make it parse the template. I do it once and I don’t need to config the instances afterwards (we have dev, staging and prod)
I really liked it. Setting up and using it with LDAP was easy, Google and other sso integration was a search and some settings away, it ran on docker without problems. There were some problems with caching and refreshing user data but that arose from the complex architecture. The keycloak UI was at times a little clunky but the documentation was good.
I would recommend it to anyone.
There’s also a book now which I can highly recommend: https://www.amazon.com/Keycloak-Management-Applications-prot....
It has some holes in the installation section because it does not cover the most recent containerisation story but it’s pretty good for Keycloak configuration for various purposes.
It does 10 x what you likely need, but when some enterprise customer asks you to for support for their baroque idp setup or for their crazy password complexity requirements, with Keycloak you can always Just Say Yes.
Been there, done that, AWS can never claim their documentation is correct to me anymore.
Would like to cheerlead for fully opensource Zitadel project here however.
Main repo https://github.com/zitadel/zitadel
Zitadel team clearly understand OpenID, Auth0, Keypass, etc specs and have all previous experience to implement identity management right for SaaS, B2C and B2B project scenarios.
SaaS Product with Authentication and Authorization https://zitadel.com/docs/guides/solution-scenarios/saas
Simplify Your SaaS: Multi-Tenancy and Delegated Access Management with ZITADEL Organizations https://www.youtube.com/watch?v=Cx_WgyY4TOo
ZITADEL Roadmap https://github.com/orgs/zitadel/projects/6/views/1
Zitadel took a very good direction into allowing to "build my own login and register ui"
Sprint Demo - ZITADEL 2.28.0 https://www.youtube.com/watch?v=hpQ4zrV48LY
[Epic] Login API and improvement of Register API #5015 https://github.com/zitadel/zitadel/issues/5015
https://github.com/zitadel/typescript
Previously had a look at Ory, Keycloak and many others.
Found those solutions either to be more "enterprisy" and over-engineered rather than something which can co-exist in my small team brain.
Zitadel is currently not much better in this aspect either, but they're working on it.
Only the Ory stack currently has full API supports for fully customized login/registration screen.
Keycloak is not open source enough?
It's fine to talk about alternative solutions but you could at least compare and contrast the solutions together and provide some insight into why you are plugging another product...
Americans use the term 'no-brainer' as a positive thing - a decision so good, easy and obvious that even someone with no brain would make it.
That's in contrast to a most colloquialisms about decisions made without brain power - calling a decision 'thoughtless' or 'dumbass' would instead be a negative thing.
Suntory Time! - Lost in Translation https://www.youtube.com/watch?v=FiQnH450hPM
There I just have one project for each … project because they are separated.
I just saw that something like that works in Zitadel too, so I only have to run one instance. But is this meant to work like that? Or should I rather spin up one instance per project?
We support multiple approaches for multi-tenancy.
In a typical setup you will only need an instance (a virtual Zitadel system). This already supports B2C and B2B deployments.
If you want to host multiple customers, fully isolated, you could create an instance for each customer. However this is only necessary if you want to become a Zitadel service provider in most cases ;-)
Some docs for this:
Organization vs Instance: https://zitadel.com/blog/multi-tenancy-with-organizations Instance: https://zitadel.com/docs/concepts/structure/instance Organization: https://zitadel.com/docs/concepts/structure/organizations
Hope this helps!
Thanks for the kind words!
As you already pointed out we are currently working on two major improvements. A new resource based API which allows creating your own login/register and many more things (1) and a login/register sdk for typescript (2). This decision was definitely influenced by our great community and helps us shape the product.
We dearly believe the market needs a modern open source identity platform that can replace Auth0 Personal opinion, do not fight me for this ;-) I often think of what we do as GitLab vs. GitHub. Going with an open core/source product against a well established cloud only/closed source player. From Keycloak we took inspiration in the ability to self-host. We think it is important to allow people to control their critical user data.
[1] i.e https://github.com/zitadel/zitadel/tree/main/proto/zitadel/s... [2] https://github.com/zitadel/typescript
For local development, we end up using dex (https://dexidp.io). When we need support group/role, we use dex and glauth(https://glauth.github.io). Both dex and glauth can be configured with yaml files. We just created a few yaml files and a docker compose file, every engineer can be brought up the whole environment in a few seconds.
Also https://www.authelia.com and https://github.com/goauthentik/authentik look pretty promising, if you need more advanced features from them.
In my team, we docker-compose-up KC and the realm gets configured at boot time, by passing the path to a previously exported configuration, which we store in got.
The configuration holds realm data and users.
We used keycloak-config-cli [1] it compares a config file stripped of IDs to your Keycloak installation and makes the relevant updates through the REST API.
To the second sentence: I don’t know what the benefit is either but in some environments you are not able to use any cloud provider or other external service to realize the auth layer so you are stuck with things like keycloak. Hope this thread discusses some other solutions which you can self host.
Setting up basic forward auth or OIDC was super easy though.
I mentioned Ory above but you get both options - either as a managed service or run on your own infra
I have clients that definitely prefer combination of open source + owner-controlled + lower costs ;)
Keycloak looks like a big complicated monster, so I would prefer to stay away except that it looks like I will be required to have all that complexity to support all the use-cases we are looking at.
https://zitadel.com/docs/apis/saml/endpoints
https://zitadel.com/docs/guides/integrate/identity-providers...
https://zitadel.com/docs/concepts/features/selfservice#mfa--...
https://zitadel.com/docs/guides/migrate/introduction#multi-t...
https://zitadel.com/blog/zitadel-as-sso-provider-for-selfhos...
we really tried quite hard, since it was backed by CNCF, but it could just be a case of being a tad too immature for prime time.
it seems keycloak is now CNCF though
The only thing nicer in Kratos from Keycloak is the standalone self-service UI with JSON identity declaration. If someone from the Keycloak team is reading this, please, let’s have a talk about bringing that feature to Keycloak, then Keycloak will be perfect. The template approach is a bit of a hassle.
Source: deployed both stacks in production systems.
Also my experience with Keycloak in the past was that you can't do zero downtime deployment, or true configuration as code.
Very impressive ecosystem nevertheless.
Show HN: Ory Kratos https://news.ycombinator.com/item?id=31679811
Most HN comments are still relevant
IIRC, if you're using an external identity provider, and you want clustering, you can just deploy Keycloak containers and load balance between them. You can then load a shared cache if you want (or need).
My memory is fuzzy right now, but although it isn't the leanest solution, I don't remember it as terrible. Ours wasn't a very custom solution anyway, we just hit an LDAP in the back and that was all.
Configuration sucked, but that's because Keycloak can do an awful lot.
I do recall the gossip protocol presenting problems back then, but now I believe the helm chart just works.
If you actually want to transport configuration across environments (DEV, QA, PROD), then you want to export realms and have it load by KC on startup or import it using the UI.
We've had a number of folks migrate from Keycloak due to some of this clunkiness, but I do know they've done some major overhauls recently (moving to Quarkus amongst other things).
It also used to be super resource intensive if you have a large number of realms (which is what Keycloak calls tenants and Cognito calls user pools). From this 2022 link, more than 100-200 can cause issues: https://github.com/keycloak/keycloak/discussions/11074
Pretty happy with this setup, though it has less features than Keycloak, it's easier to administrate from code.
[1] https://github.com/lldap/lldap [2] https://www.authelia.com/
edit: BTW authelia looks very promising. Thank you for the link! The bus factor seems a bit low for such a mission critical application, at least when evaluating it as an alternative for production. But I really like how open the core team is about that.
You can apparently build an "optimized" image[1] so it doesn't do it at runtime, but I didn't want to build a custom image, and I felt like the KeyCloak philosophy didn't align with my own.
In general I found myself avoiding Java applications because of their memory footprint.
[1] https://www.keycloak.org/server/containers#_creating_a_custo...
I can only assume it's a cultural thing since reflection and abstraction is used so much.
Rust apps are always nice since they are generally <20MB or something.
However, it's a different story when picking the solution for my day job, where RAM is abundant, but developer time is in short supply.
What was your original goal? Which services are linked to your lldap? How many users? Does it simplify things or make it more complex?
1. My original goal was not having 5 different passwords for my own server because although I have a password manager it's still a bit annoying. Also just for learning.
2. You can see the services here[1], since my entire setup is provisioned from GitHub with Terraform and Ansible.
3. I have about 5 users.
4. I would say simplify so far, but it depends on what kind of complexity you care about, and which services you want to integrate.
[1] https://github.com/RedlineTriad/private_server/tree/master/s...
I "solved" that problem by having configuration management deploy same password (hash) on all of my servers. Requires keeping the repo with password hashes relatively safe and of course changing them is a bit of a process but extremely easy and low tech if there is already CM in place.
But I wouldn't want to figure out how to write the password hash into the databases of each application like grafana, or grocy.
The lldap config I use is here if you want it for any examples or something: https://github.com/RedlineTriad/private_server/tree/master/s...
From their system info page: https://door.casdoor.com/sysinfo, it only consumes about 10MB memory and with no less features (more features actually) than Keycloak
I think I looked at:
- Keycloak
- Zitadel
- Authelia
- Authentik
And maybe a few more, but I never heard of Casdoor before today, and even now there are few Reddit references to it.
JVM programs have high initial memory usage, but they scale up very well.
Discussed here https://github.com/keycloak/keycloak/discussions/9713 and https://stackoverflow.com/questions/75082532/keycloak-suppor...
We also experience a few front-end issues, like when a token expires, the browser tab goes back to the login page. If you leave the tab a while then press login, the token it is using will have expired. Rather than automatically retrieving a new token and posting the login again, the user gets an error message and has to authenticate again.
If you have two tabs in that state, you log one back in, switch to the other tab, if you refresh that tab, all is well, login proceeds automatically. If you press "login" instead, you get an error page telling you "already logged in" rather than just redirecting you back to the app... it also loses the redirect url so you have to press "back" instead.
Will see if we can fix these when we have time, it would be nice to contribute back.
I was also very intimidated by the ORY stack. I didn't know how all the pieces fit together. And to self-host you pretty much need to run and orchestrate it on k8s. I'm not an auth expert, I just want a login thingy for my website/app.
I'm not affiliated with it in any way, but I really liked what ZITADEL[1] is doing, in case anyone else is researching their options. It has a very simple interface to get started with, but also a ton of features. It being written in Go is a huge benefit since that makes it much easier for me to throw it up on my vps and calling it a day.
That's what the docker image is for: https://www.keycloak.org/getting-started/getting-started-doc...
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:21.1.1 start-dev
But both systems can restart crashed containers. That's not an issue at all. Kubernetes does it automatically. Docker does not do it automatically but you just need to supply proper option for `run` (or just in docker-compose.yaml).
Also, Docker and Podman know how to restart containers if needed, depending on a policy you set.
If you want something even smaller, take https://github.com/containers/bubblewrap or https://github.com/arachsys/containers and run them under the process monitor of your choice, like runit or s6.
They will restart when crash, and after reboot.
It's starting multiple minutes.
You're supposed to "compile" it, creating your own image, hosting it somewhere (and it's huge). And then this "compiled" image will be fast. Well, fast in Java terms.
I was shocked when I read the instructions and realized I had to build a secondary container.
On top of this, there are some keycloak options (parameters and env vars) which are valid only at the time of compiling a new container, where others are valid only at runtime
Anyway, they changed the default behavior a few releases ago. In the past you had to pass --auto-build to avoid having to build, but now the default behavior is to auto build. If you instead want to optimize you have to do extra steps: https://www.keycloak.org/server/configuration
Starting a few minutes? It looks like there must be some DNS problem somewhere. Or maybe it's the download build time? In any case, I'd measure the second startup time.
Java can be blazingly fast if done right. (And C++ can be stupidly slow if done wrong.)
Those services were all built to not be restarted so they've never optimized for it. More recent Java frameworks and projects do try to optimize restarts due to kubernetes adoption etc.
You may have have seen those magical Java applications that both implement a decent amount of functionality (so not just a toy), and start in a couple of seconds, but the rest of us will believe it when we see it.
I wonder how they're developed, it feels like a throwback to the punch-card era.
While I don't have much love for Microsoft, you should take a look at dotnet. Applications written on top of dotnet (even using massive frameworks like ASP.NET + EF) actually do start in a few seconds, which is at least an order of magnitude faster than anything similar in Java.
Ok, great. Well if I'm buying my auth I at the very least need some kind of 2FA, MFA or something. I don't care about anything other than user/pass and MFA. But every service wants to charge you well over $100/mth for any kind of MFA. Why can't they just forward the transactional SMS/Email charges on? Or better yet just give the authenticator app options.
I feel like user/pass + MFA isn't asking for the world and not including any kind of MFA to me feels like potentially worse security than "rolling my own" simple bcrypt + regular old sessions and then can add on MFA too using well defined standards and libraries.
Now I do like these open-source options but again, they seem faaaar too complex for what I want. I could definitely implement simple session and hashing auth much quicker than setting up any of these. Which I completely understand as this is complicated enterprise identity systems here. I don't need that though!
Anyway rant over. Anyone else have this experience or am I alone?
Very interesting to have a per request model, instead of MAUs. I think I prefer that too.
In fact the general advice I've heard is "just use bcrypt"
You ask any question on a lot of sites and communities (twitter, reddit, stack overflow) just about anything to do with auth and you'll get slammed with comments preaching about this.
I think Hacker News is somewhat an outlier in this I will say, as in previous threads this doesn't seem to be anywhere near as common.
They always have the same "you think you know better than the 1000s of auth and security experts working on Auth0 or xyz". Which, no obviously not. But there's clearly defined standards such as bcrypt and how to handle sessions etc; and even the OWASP cheatsheets too.
I feel I could implement an auth service wrong too with calling their API if I really tried.
Heya, it depends!
I think if you have one app and don't plan to have any others, it can make sense to use an open source library like Devise/Omniauth (Rails) or Spring Security (Spring/Java). Passport.js is pretty good for javascript. You can also use some of the simpler SaaS options like Supertokens or Clerk.
If you plan to have more than one app, especially if you want commercial off the shelf software to hang off it, then you should start looking at auth servers (Keycloak and FusionAuth are both such servers, as are others mentioned in sibling threads).
Then the choice becomes SaaS or self hosted. If you are looking for ease of use, SaaS is where it's at. Most every auth server has a hosted version; Auth0 is the most popular one but I believe the free tier is 7k users and MFA options are limited. FusionAuth doesn't have a free SaaS option, but if you stand it up in EC2 or some other provider, we offer TOTP MFA, unlimited SAML, OIDC and social connections, and unlimited users and clients (we call them Applications). But of course you run it yourself, which is not free.
Anyway, lots of options out there. Based on the little I've seen here, I'd probably recommend an auth server (because you have many apps). Self-hosted or SaaS probably depends on your appetite for running an auth server; I don't have context to recommend one way or another.
FusionAuth seems really great too, in my journey down this path I've come across quite a few people using your hosted service on very large apps who have nothing but praise, so kudos!
One question I have is, when you say multiple apps, are you speaking in a sense of they are at all related? Or every small app/project you have related or not?
If you think that people will want to subscribe to more than one app, or if you think you'll want to be able to have a single view of customers/users across multiple apps, that's when I'd extract auth to an auth server. You can use a dedicated auth server or have other apps rely on one app which uses a library/framework.
Think of it as normalizing user profile info. Just like when you normalize data, you get wins (one place to change things, consistent data structure) and you lose things (more complex, have to do joins across tables [or in the auth case, use tokens]).
If you don't ever forsee the need to look across all your users, or for users to log into multiple apps, and you don't need some of the isolation and features an auth server can offer, then it makes sense to continue to silo each set of user data in each app.
You can always make the investment to migrate to an auth server later. Of course, the longer you wait, the more hairy it will be.
Hope that helps, and thanks for the shout out to FusionAuth. If you want to download the free Community version to kick the tires for your own needs, here's the link: https://fusionauth.io/download
You'll likely need to integrate with stuff like OIDC if you're planning to sell your software to enterprises with their own existing authentication mechanism (which isn't all that hard if you pick the right software stack as Apache and Nginx can do that layer for you!) but in other cases I don't see the need for it.
It's important to know your stuff when you're designing a security barrier, though. Good auth can be hard if your development framework doesn't already take care of edge cases. Things like JWT and refresh tokens can be a pain to get right and MFA can be even worse. Grabbing someone else's auth solution can sure be the quickest, easiest option, but there's no real need for all of that if your system doesn't need all that much complexity.
Personally, I would go with Keycloak or a similar product, but not integrate directly. With both Apache and Nginx you can let the web server do all the OpenID Connect work for you for paths you specify. All you need to do is take the header your reverse proxy hands you (make sure this can't be spoofed) and take that as your account ID. You'll have all the fancy enterprise features like MFA and LDAP integration at the ready if your customers demand it, but more importantly you don't need to bother with implementing refresh tokens, WebAuthn, TOTP generation, or password resets.
More importantly, this stuff can be hosted on your own hardware without any cloud subscriptions. You can outsource auth to an external provider later if you run into scaling issues, but you probably don't have to because servers are fast these days.
I'd guess that for most platforms that work with a simple username and password, rolling your own auth is probably a lot cheaper and easier. With 2FA this becomes trickier to pull off, but depending on your platform you may be able to build it in the same time it takes to properly configure, style, test, and document an external auth setup.
Seems like at least the official nginx solution for this requires their paid subscription: https://github.com/nginxinc/nginx-openid-connect
Got any tips for how to do it with their open-source solution?
Apache is a lot easier to configure, though.
You're not alone. I take it a step further and don't deal with passwords. I use login through email, in which I send a nonce to the user's email. The users enter that nonce to log in. This is what many online bank apps do. That reduces the security surface area to CSRF, securing cookies and session expiry. Most popular frameworks should handle that part of it.
Initially people told me to use a login link or 'magic link'. However it quickly became clear that they also wanted to receive the code on a different device to the one they logged in with.
How do you keep the user logged in? Do you just keep a token in-memory on your frontend app?
TOTP codes / authenticator apps should be the least overhead so I'm not sure why they don't offer that at the lower tiers.
It stores its configuration in the database. It means that I can't just configure it in some yaml configmaps. There's no easy supported way to test some changes on test server and then move those changes to production. You need to click around in its UI and you better do it well, it's a security tool after all.
There's adorsys/keycloak-config-cli which is third-party solution which is supposed to somewhat mitigate this issue (you supply a config and it'll try to adjust keycloak instance to this config), but it's absolutely not first-party solution and does not work as well.
Please just store users in the database. Let me specify everything in config yamls, so I can change it and restart the server and that's about it. That's how gitops is supposed to work.
OIDC allows an arbitrary number of identity providers to register themselves - so there's not really a clear way to distinguish "config" vs "data" here.
That said - They've recently improved importing and exporting realms, and it really solved a lot of my pain. Mainly - you can now directly import/export realms in the UI, and the server doesn't need to be stopped.
Still a little more finicky than I'd like, but way less risky than having to reconfigure by hand.
[1] https://github.com/mrparkers/terraform-provider-keycloak
For my hobbyist project, I'm currently using the terraform provider, but that is third-party. [1]
I'm really torn on this, because on the one hand, Keycloak is undeniably a great tool with a lot of features that make it possible to integrate with almost anything you throw at it, but on the other hand, if you want to set it up in a reproducible, declarative way, you either have to trust a third party to maintain a provider, or the first party that already deprecated stuff way too early once - which is why I'll still use it for personal projects, but can't in good conscience recommend it in a professional capacity.
[1] https://registry.terraform.io/providers/mrparkers/keycloak/l...
I would use it again for sure.
Running it in production is a no-brainer, the only problem we got was some bad behaviours of some clients that issue a token for every API call as it can put some stress on Keycloak, has to implements some rate limiting in front ok Keycloak to avoid that.
I try to ease its usage with Clojure with https://github.com/jgrodziski/keycloak-clojure I wrote some documentation about Keycloak concepts here: https://cljdoc.org/d/keycloak-clojure/keycloak-clojure/1.30....
Compared to Keycloak, Casdoor has:
1. Support high-concurrency and use less memory (Go v.s. Java) 2. More modern SPA-style web UI (with React and Ant Design), more CDN friendly 3. full-fledged RESTful API 4. Support a lot of provider types: OAuth, SMS, Email, CAPTCHA 5. More powerful authorization (powered by Casbin), Casbin is a popular authorization solution with a lot of integrations for DBs and applications: https://casbin.org/
SaaS hosting is also provided at: https://casdoor.com/ for anyone who don't want to self-host
Is this a feature or an anti-feature?
An open-source Identity and Access Management (IAM) / Single-Sign-On (SSO) platform powered by Casbin and AI gateway with web UI supporting OAuth 2.0, OIDC, SAML and OpenAI ChatGPT
Why would an IAM/Oauth2 platform need Chatgpt? Is this just buzzword bingo?
In the context of Go vs Java this is a kind of weird unsubstantiated claim. For example if you think a garbage collector leads to higher memory use; Go uses a garbage collector, just like Java. There are loads of applications which support high concurrency in Java. Such as Elasticsearch and Apache Kafka.
I tried to set up Keycloak but after fiddling with it for awhile before giving up and trying something else. It felt really weird that I was just extracting a tar and running a jar instead of some pre-packaged solution, but that might just be me.
authentik was pretty easy to set up for my homelab, but maybe I'm missing something given all the positive recommendations for Keycloak?
I did not really try authentik yet since all the advanced features I needed worked with Keycloak, but I do have it running in a container to play with at some point in time.
I also checked out some other options along the way, and ultimately realized that pretty much all of the options come with enterprise-oriented features that are just added complexity for the self-hosting use case.
Ultimately, I've gotten at least somewhat familiar with all the complexities of Authentik, so I'd have a hard time switching off. Would definitely love to see a solution geared towards selfhosting that's more barebones, though.
It seems straightforward to have Keycloak proxy the authentication via OIDC but it's less clear to me how to get apps to check with Keycloak to determine if user X is in group Y and is therefore allowed to access resource Z. The main benefit in a setup like this is the ability to query a single source of truth when it's necessary to audit a user's capabilities within the org.
Is this an achievable or reasonable use case for keycloak? Or should I integrate my apps around a different Zanzibar clone which is designed to quickly serve granular permissions?
This leads among other things to the Admin UI becoming basically unusable: https://github.com/keycloak/keycloak/issues/20453
We currently have to implement a workaround where we create multiple Keycloak clusters and will have to write some glue to manually route to the correct one based on the realm, but that seems like unnecessary overhead.
The upgrade path for keycloak is also similarly broken in my experience. Especially the total change in one of the recent versions broke a lot of things, which they are still fixing. Add no visible LTS or security patching on top, and you end up with something, that isn't usable for any enterprise rollout.
The alterntive to using a tried and tested solution is to build it yourself - but are you really confident you will do a better job than professionals in the field?
https://www.ibm.com/docs/en/control-desk/7.6.1.x?topic=check...
https://owasp.org/www-project-web-security-testing-guide/lat...
The general problem is that if you just go and blab about what software you're running, if you ever have a version with a known vulnerability (or a zero-day) then the attacker immediately knows what payload to run against you, in fact you can potentially be programmatically attacked from Shodan/etc.
Obviously it's better to simply never run any insecure software, but forcing them to run a search for payloads against you will hopefully create an opportunity for them to trip alarms and generally increase the attack time.
I am not super duper concerned about leaking what the gateway app is in general, as a sibling mentions it's pretty unavoidable that an attacker is going to fingerprint a server if they really want to, I generally agree (without knowing which is which) that there are clearly a couple of them that have distinctive UI looks lol.
On the other hand, leaking version info is probably a bridge too far in my opinion - if you do ever end up with a vulnerable JVM/library/appserver/gateway, now it can be programmatically identified by an attacker. Things like log4shell or the Jakarta Struts vuln have a long long tail of shit that's gonna be vulnerable forever.
It's not the end of the world, but honestly I really, really dislike the way "security by obscurity!" tends to be used (more often than not) as a thought-terminating cliche. The line is supposed to be that "obscurity as the only method is not security" and that's true, but, obscurity is generally an important part of defense-in-depth. There's no reason to hand an adversary more information about the system than necessary, them blundering around your obscurity and triggering security alerts for patched attack payloads/etc or weird errors that don't normally crop up increases the chance of detection.
People treat it as "anything that increases obscurity is a bad thing" and no, actually that's generally a good thing (as OWASP acknowledges). Just not if your system is designed such that it doesn't work if obscurity fails. Building a secure system and then adding obscurity is a net increase over a secure system without the obscurity.
Should your application be secure if you hand them a classfile list? Sure. Is it a good idea to actually hand them one? No. Same for network maps/IP ranges/etc. Is it something they could figure out eventually? Sure, but make them work for it, and hope they try to connect somewhere that isn't allowed for that container/VLAN and alarms go off. Security and obscurity are two great tastes that go great together, because obscurity increase the chances that an attacker trip alarms in a way that catches attention.
Was there a specific trivial information leakage you were worried about?
Sometimes it’s better to do just the thing you want, and nothing more. Othertimes it’s better to rely on tried and tested solutions.
I’m still scratching my head over the crazy unnecessary feature in log4j2 that lead to their massive security vulnerability recently. A feature that I had never heard of nor would have ever used.
The trade off isn’t always obvious between reduced attack surface of bespoke solutions vs the many eyes on popular public solutions.
This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads. It can also make for an easy source of blacklisted botnet IPs. This stuff takes maybe five minutes to set up and it weeds out a lot of the automated crap.
You're just wasting a bit of your own resources for no gain here. If you want to "do something about it", throw that IP onto temporary blacklist (temporary because those IPs will inevitably rotate and might be actual dynamic ISP IPs that can be given to different user next time)
> This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads.
How does that help ?
Attackers have limited resources, so slowing them down with slowloris, or tricking them to use the wrong attacks provides protection. Dedicated attackers may notice the WordPress trick or may just run every payload against you, but automated scanners that are trying to be efficient will not. Hopefully a WAF can detect that much more noisy attack and deny-list their IP address(es), and other more traditional defences kick in.
If you trap them in the wp-login stage, they probably won't get to the next part of their automated attack that you may actually be vulnerable to. Plus, with a bit of luck, criminals will ignore your server after finding out their bots keep getting stuck when they attack you.
If there's some kind of vulnerability in your software, you'd probably want to try to get bots to submit payloads for another type of software that won't do anything. An Apache 0day won't affect a Caddy server, and many PoCs will check if the target is vulnerable before attacking. Theoretically the attackers could patch that out, but many of them are too lazy to do that.
The UI might look a little outdated, but that's a admin ui anyhow. Lately even that got better.
Cannot recommend KC enough. Even kenning locally on our dev boxen, it never failed on us.