We use Keycloak _a lot_ at work, with many public and private instances. It is an amazing product and I keep discovering features every day.
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
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)
We gave up on Keycloack because it was hard to maintain and add features to it. Now my colleagues are way more happier with an in-house authentication solution that is pretty nimble and we know all the ins and outs.
I worked on a project which used Keycloak for authentication and SSO module between like 10+ java services with a custom UI and custom 2fa solution.
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.
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.
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.
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.
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...
Keyclock is a great project. Much welcomed by all my friends from bloody enterprise caused 1. it’s written in Java and 2. well tested by their cyberops teams.
When adeptima says "Keycloak is a non-brain solution" I believe that is intended as an endorsement.
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.
I currently use Firebase auth for a couple of projects where I don’t want to implement auth. because of 2fa etc.
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?
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 ;-)
We used keycloak for openid identity provider as well. It is fine to setup keycloak once. But it is painful share the setup with other engineers.
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.
It's actually very easy to share a realm configuration.
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.
> But it is painful share the setup with other engineers.
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.
I don’t get it. Keycloak feels like some clunky 90s enterprise software and I mean it only in a bad way.
Had to run it on openshift and it was hell. It’s not really made for containers, clustering is basically impossible, it needs to know it’s default route and I can’t remember the exact issue but found myself patching some obscure startup scripts which templated some XML to start that thing. Can’t recommend but I’d be happy to hear alternatives which are actually modern.
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
Are we using the same piece of software? I have it deployed in production on kubernetes using the bitnami helm chart and everything works like a charm, clustering etc. No need to modify any XML or care about network routes.
We use KC with PostgreSQL as backend data store. Backup is done by backing up the PostgreSQL database.
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.
It's on my list of things that assumes out of the box that you know waaaaaay more about dozens of details than you actually are likely to unless you've already used it for 10 years. To the point that I don't even know what the benefit of using it vs. other options is at all.
I can’t understand your first sentence even after reading it ten times. Maybe it is too long for me.
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.
Which is extra funny when Keycloak is sticking to jargon out of RFCs that nobody else in the SaaS identity space is using. Hooking up Keycloak to a SAML consumer that only documents SaaS configuration is a fun game of try until it works most of the time.
I know the two main competitors that have been adopted by the self hosted community are authentik and authelia, they’re both somewhat under developed for enterprise but at the same time still difficult to grasp for non-full time devOps people. At least in my opinion.
I use authentik for self hosted - it's great but still too powerful and configurable for me or most people who are not auth experts to customise. Just creating a password reset flow requires integrating a dozen moving parts. The only explanation how to do it is a yaml file or a YouTube tutorial.
Setting up basic forward auth or OIDC was super easy though.
use cases that require _everything_ "on-premise" are often government/military, big healthcare, or just huge enterprises that want to control everything (and can afford a team that only runs their auth service).
I mentioned Ory above but you get both options - either as a managed service or run on your own infra
Yep, this is why I have been evaluating it recently. Have a customer that wants SAML 2.0 support, others that want LDAP support, 2FA support, and multi-tenancy support, while being something we can self-host. The other main suggestions I have seen - ORY or Zitadel - tend to be missing at least one of those (from what I can tell).
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.
As far as I can tell, Zitadel cannot be used as a SAML client, only as a provider. One of my requirements is that we use customer-provided (and controlled) SAML for SSO. Otherwise it was looking very promising.
Ory Kratos is nowhere near Keycloak. First of all, one needs at least Kratos+Hydra (there’s an integration method now out of the box yay) but Keycloak still has a flexibility advantage. Keycloak has many more features out of the box comparing to the complete Ory stack.
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.
What's nice about Ory Kratos/Hydra/Oathkeeper is that you can set 'groups' for your individual clients. In Keycloack that'd have to be a realm per client and if you have more than a couple, screw it. Don't know if something changed with Keycloack in last two years, but that's what nudged us towards Ory. Also, not sure how fast keycloack can get (plus caching) if you want to put it on-front of an API as an auth and throttle solution (you probably can't).
I have, and we went back to keycloak- everything the parent says is true, however Ory/Kratos is a lesson in half finished solutions and poor documentation.
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.
Were you using Keycloak also as the identity provider?
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.
I just docker-compose up'd the server and configured it. I don't know when you last needed to mess with it, but the containerised version seems quite easy.
Configuration sucked, but that's because Keycloak can do an awful lot.
I tried Keycloak for my homelab, but I found the resource usage especially on startup to be too high (3 GB memory or something) and since I wanted minimal sever footprint I went with lldap[1] as the user store and authelia[2] to do forward auth using traefik.
Pretty happy with this setup, though it has less features than Keycloak, it's easier to administrate from code.
Did you try the "new" version powered by Quarkus? I think it has a much smaller footprint.
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.
Probably not small enough for a home lab setup, between a 50MB Golang App and 500MB Java App I'd choose the Golang App every time for my home lab, because memory is precious and probably less than 10 people will use it.
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.
I tried the Quarkus version, but it does some kind of build step at container startup, and that is what used the most memory.
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.
I understand your reluctance to use Java, but it's actually pretty good if the developers use small libraries instead of the giant frameworks most Java servers use... a Java server for this kind of stuff will run within 200MB+ comfortably and with very high performance when written properly. Anything using 3GB for this stuff is doing something terribly wrong.
Yeah I know, nothing except maybe the JIT that requires java programs to use more memory than Go, but in practice Java apps are almost always significantly worse.
C# is also pretty bad, but not quite as bad I think.
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.
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 just never heard of it, I went through reddit and looked at what people were using, and awesome-xyz lists, and then went through docs and pages to see which projects had the same priorities as me.
And Authelia looked like the best match.
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.
Thank you for the help on GitHub with running it as a read only image BTW.
Since I try to keep my deployments clean and mostly stateless getting that to work was very nice.
Note that if you want to use KeyCloak for the OpenID but want to still have a LDAP source of truth, you can use LLDAP + KeyCloak together, with LLDAP as the source of truth and KeyCloak giving you the fancy features: https://github.com/lldap/lldap/blob/main/example_configs/key...
It's been pretty good, I never really used LDAP before so I had a bit of a learning curve, but it's not too complicated.
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.
> 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.
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.
As a user of Keycloak on a production project, I'm a little sad there is currently no support for opaque tokens.
Sure, you can treat the access token as an opaque token... but at the end of the day it could be a lot smaller.
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.
When I was building a website and companion app, I researched a lot of the open-source options for auth. My primary requirement was ease of setup and operation. I didn't want to mess around with JVM dependencies and 100% didn't want to start messing around with k8s for such a small project.
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.
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
You absolutely don't have to build a container. You can, and it makes startup a few seconds faster so they recommend it, since it's hardly a pain anyway if you already have CI in place.
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
If you `docker pull` an image, you already "host" it. It's a bunch of local files right on your machine.
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.)
I'm aware Java can be fast, but thats never what I work with. The products I've supported include vmware vcenter, confluence and epo. In all cases, just restarting a service is a "go have a coffee" affair. It really says a lot that something can take longer than a Microsoft exchange server to start but when I see it, I know someone badly wrote a Java app. To be clear I'll happily buy that this is a case of it not done right, but that seems pervasive.
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.
Every newer Java application I've seen is just as dog slow as those older ones. Keycloak itself being a prime example — it was rewritten on top of Quarkus recently, and it didn't help much. You're still expected to build a second image (and maintain it — it wouldn't be a problem if you only had to it once), and it still takes 2-3 minutes to become responsive.
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.
I've only used docker for local dev environments, so I'm curious what happens if the process crashes? Does the docker daemon perform health checks to restart it, or is that the domain of k8s? It's pretty simple to do with systemd.
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).
This is timely. I am stuck on simple authentication for my small apps.
Everyone tells me - "Don't roll your own auth EVER!!!!", and then tells me about some easy-to-use Auth as a service.
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?
This is the first time I've heard of the "don't roll your own auth" crowd. You don't roll your own crypto (unless you're damn good at crypto, and most people aren't) but a simple username+bcrypt/argon2 solution works just fine for most applications.
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 think your 2nd/3rd lend favour towards "don't roll your own auth" - it's hard and more often than not there will be buggy implementations. People aren't good at crypto and they aren't good at authentication workflows either, when an application starts to scale it becomes a liability.
Building auth is hard, but so is properly integrating with external auth providers. You'll be surprised how many applications you'll find online that accept unsigned JWT tokens because many people don't know they need to turn those off. You also need to cater to the specifics of your auth solution (i.e. how to prevent spoofing, how it deals with brute force attempts, how to set up the proper session lengths). You end up learning about things like "OAuth 2 scopes" and other fun terminology that will have you become an expert in the specific auth solution you've chosen before you can reliably roll it out.
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.
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.
Hey really appreciate this advice! It's quite refreshing to here someone who works at an Auth provider not understating the usability of some of these libraries and frameworks.
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?
> 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
The big auth companies have been really good at creating those "Don't roll your own auth EVER!!!" articles.
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.
I like this solution and use it on a system where MFA is not an option, and people log into it very infrequently.
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.
I've gotten by with bcrypt + self generated tokens so many times it's not even funny anymore. Don't listen to these bigots. You don't always need 800 layers of Oauth etc
It's SO FRUSTRATING that these services put MFA behind hundreds of dollars worth of subscriptions. For example, Auth0 goes from $23/month for the "essentials" then jumps to $240/month if you want any sort of MFA.
TOTP codes / authenticator apps should be the least overhead so I'm not sure why they don't offer that at the lower tiers.
I'm curious whose telling you not to roll your own auth. I've worked on far more software that handles its own auth than integrates with Okta/Keycloak/Whatever.
In fact the general advice I've heard is "just use bcrypt"
Oh really?
I mean I'm almost to relived to hear this because the "never roll your own auth" crowd is honestly deafening.
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.
Keep in mind that this site is filled with snake oil salesmen that will try to push anything to you. (Among many honest commenters, obviously.) I've never used third-party authentication and do not plan to. Web frameworks usually handle most of that stuff anyway.
Have a look at Jackson from https://boxyhq.com . Spin up one container and a couple of simple endpoints - voila, up and running. And a really cool team too!
My biggest problem with Keycloak is its configuration.
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.
I feel this problem (I also find configuring keycloak clunky) - but I understand their problem.
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.
I got burned using the k8s operator a while back. The old one, that had custom resource definitions for instances, realms, clients & users was deprecated and the new one is still so far behind in functionality that it's unusable for my purposes. (Iirc even setting up a custom ingress beyond the hostname was a pain, and setting up realms only works via importing exports, no setting up clients at all)
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.
The Terraform provider[1] unfortunately is 3rd party and as such doesn't bring and guarantees of correctness other than that of the maintainer. It would be nice to see Keycloak provide an official solution for configuration management other than the K8s operator which is missing a lot of features.
I suppose you could test your system including the Keycloak configuration to make sure things work as expected after a TF change. You probably want to be doing that anyway, though. It's a fairly comprehensive Terraform provider under active development, I recommend it.
We used keycloak at the Accelerator I worked for. I used it to provide auth and SAML SSO to enterprises while giving our devs an easy to integrate module. It worked great. Theming the login/signup/forgot password pages was simple and easy but would have been easier for the teams if it was React. Nevertheless we built some amazing B2B SaaS software using Keycloak as our identity provider.
Just because of consistency with our design components. You don’t need react for a login page. If your app is already using react and has a lot of custom components, it would have been easier for the dev teams vs having to learn Freemarker.
I use Keycloak a lot for authentication and authorisation and I like its flexibility and richness of features.
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.
Casdoor is another promising open-source IAM solution: https://casdoor.org/ , written in Go and React. All features like OIDC, OAuth 2.0, SAML, CAS, LDAP, WebAuthn and 2FA are all supported.
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
> 1. Support high-concurrency and use less memory (Go v.s. Java)
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's a fact that I also don't know why, maybe not mainly because of GC. Java's high concurrency is not impossible but just requires more efforts to tune the performance
The fact is a "true" fact, I'm not saying something which is wrong. This is all I care about. I don't need to know why. I'm not an expert on programming languages or look into compiler source code either. If you think the "fact" is not true, plz just give your opinions and evidences.
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?
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?
Using Authentik as a part of my selfhosted setup, mostly positive things to say. I tried with Keycloak first but had too much trouble getting the Docker image to work, so switched to Authentik.
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.
I set up Keycloak using Docker and it was very simple to do.
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.
AFAIK it has a bus factor of one, keep that in mind if you are going to build anything "serious" on top of it. I found it easier to configure than Keycloak, it lets you write short Python snippets for custom authorization logic, but it's about as heavy on resources as Keycloak. I hope he develops the project into a successful business, for users' sake if nothing else.
Yes, Django is a quite some decently sized CMS framework, with it's occasional security quirks and attack surface. I expected it to be some lightweight go application to be honest, based on their domain.
My LDAP server is the source of truth for my org's user/password (authentication) and user-group membership (authorization) data. I'd like upgrade to an IdP like Keycloak.
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?
I've been using Keycloak for my free Oracle DB. I have the option to use OCI but I don't want my customer (or players, actually) data to be directly stored on Oracle side because they are not that flexible. Other than that I find Keycloak super easy to use with Kubernetes nowadays though it was such a pain in the ass in the past, because the use of EJB and WildFly. Now they switched to Quarkus and you have a much better environment
Unfortunately, Keycloak currently fails to properly scale for a large-ish (a couple of hundred) number of realms, which can be an issue for use cases with a large number of tenants (as not unusual in a B2B setting): https://github.com/keycloak/keycloak/discussions/11074
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.
Keycloak is the bane of my existence. We use it and I absolutely regret it, although we didn't have any alternative at the time. Bloated and overly complex java stuff with lots and lots of undocumented behaviour. And they are still missing proper devops etiquette.
I still have open issues on github for keycloak. One of them is for example, that you can use whitespaces for names, where keycloak can't actually accept whitespaces. So you find that out after you set the global name..
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.
Heh! I just started using keycloak y'day in combination with oauth2-proxy to give me a way of completely delegating authentication. This way I don't have to worry about auth _in_ any of my apps. Really nice experience so far and fantastic documentation.
Overall, I have enjoyed using Keycloak. However, the docs were poor and I had to spend lots of time scouting the internet to get it configured right. This is quite uncomfortable for a piece of security infrastructure.
Keycloak is great for its flexibility and stability. You can extend the code by implementing service provider interfaces. In some use cases, this enables solutions that are not possible with SaaS products. For example, we created a way for customers to manage sub-accounts, including role assignments and implemented custom synchronization mechanisms. Creating a custom theme allows full customization to your corporate identity. In case anyone is interested: we offer consulting services for Keycloak at https://www.actidoo.com (our website is currently only available in German, but you can contact us at info@actidoo.com)
I’m a bit newbie in this exact field but when Keycloak is used to autenticate an external client, wouldn’t revealing that you’re using Keycloak itself be a security concern? Giving that information to a possible attacker could be dangerous, is it possible to make it totally impossible to understand if someone is using Keycloak or not?
Once you're a Keycloak user you can figure out if someone is using Keycloak within seconds, e.g. I know my credit card company uses it. And this isn't a matter of security, security by obscurity is really bad idea.
I dont quite get why you think it would be a security concern?
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?
> but are you really confident you will do a better job than professionals in the field?
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.
Server information leakage is generally viewed as a security vulnerability, eg by scanning tools utilizing the OWASP guidelines, because it assists in server fingerprinting.
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.
Wait, what server information leakage are we talking about? I didn't think keycloak leaked `x-powered-by`, and there's discussion[1] in their repo that shows they understand the concern. All software can be fingerprinted (if not then it has no user visible behavioral differences). Making it trivial to fingerprint a server isn't a good idea, but avoiding it entirely doesn't make sense.
Was there a specific trivial information leakage you were worried about?
Like every other server revealing they use Apache or Nginx? Yeah, zero days in software are an issue so it's important to be vigilant for any public deployment, but it's also not something to count against unless the software is not being maintained or too slow to fix issues.
I've talked to devs who added PHP headers and fake server name headers to their servers. A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them.
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.
> A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them.
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.
Slowing down automated scripts barely takes any resources. Slowing them down would prevent their batch enumeration, spreading out the load of their attacks. It's not much, but it's probably taking fewer resources than ignoring them.
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.
Imagine an automated scanner and attack tool. First it fingerprints your server, then it attacks with only payloads it thinks may work. If you trick it into thinking you run WordPress, for example, then it will attack you with WordPress payloads that won't affect you, even if it happens to know one that does.
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.
Keycloak: RedHat Engineering at its usual piss-poor level, plus the mediocrity of Java projects, mixed with the complexity of every enterprise customer. Result: "hey, you can get it to work eventually!"
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