Its the only java app we run in stack, but doesn't matter to me in Docker and within Windows we run a portable java from a subfolder of keycloak so not System wide in Path
If you are intrigued into the differences, you can read some of them here [2]
Oh and judging from your username: it could be interesting to you... because we use eventsourcing and cqrs ;-)
Disclaimer: I am one of the authors
There are a lot of other improvements, but if that's the only dealbreaker, v2 should take care of it.
I'm really impressed with your strategy and v2 looks like a really great upgrade.
What do you not like of the new pricing? The pay-as-you-go approach?
The background to this is, that we got many customers asking for features on the lower tiers and that many of them wanted to have a more linear scaling in their business cases. On the other hand we wanted to make sure, that even from the start you get all security features without paywalling them.
The 25K request roughly translate to 10K user per Month and you will be able to get that without a credit card :-)
How does Zitadel differ/compare? Do you have similar goals as an organization?
- ZITADEL: If you want turnkey solution built for the cloud with a great support for B2B, a strong audit trail and self-hosting, but also the option for SaaS - Ory: If you want flexibility to customize all the stuff but are aware that it is not as turnkey as ZITADEL and Keycloak - Keycloak: If you want turnkey with a high maturity and a lot of features but some lack in regard to B2B, cloud native and support
This more or less reflects my opinion about Ory. I like the way they built their suite because its totally flexible. But it dislike the fact that it does not feel like a turnkey solution and needs some more work than plugin in a OIDC client.
So what we think and aim for is that ZITADEL combines the best of Auth0 and Keycloak [1] while bringing some unique features to the table. For example an unlimited audit trail (built with event sourcing), great self-service capabilities for B2B and B2C cases (customers can manage their own org, user, federation, access) and the possibility to soon run "serverless" (well at least as serverless container). With our cloud service we also allow customer soon to move their data around (see data location [2]). And all of this while being totally open source.
1. Funny image for this https://twitter.com/ffo_sesp/status/1519655412752162818?s=20...
I too would prefer to use PG than Cockroach, if only because I have ops experience with PG. But Cockroach is certainly intriguing.
1) We think providing an embedded DB of some kind for easy to use cases with ZITADEL might be favourable to some of you (think Sqlite or an embedded CockroachDB ) 2) To allow plain Postgresql besides CockroachDB should be an easy thing to do since we already make use of PG wire protocol. We plan to address this in a 2.X release
What do you think of this? Or what DB would on your Wishlist?
My own personal preference would be if you could please support PG, because in that case I could be confident of going into production with what I configure, even if it's less scaleable than CockroachDB. I'd really prefer to be learning about how Zitadel works, rather than learning CDB or trying to remember sqlite cli commands.
I'm happy to give CDB a spin once Zitadel 2.0 comes out, but it will add to the burden of onboarding it into my stack, and I'd think that's something you'd like to avoid going forward :)
I created an issue for further tracking https://github.com/zitadel/zitadel/issues/3598
As an FE dev without Java background, this became pretty difficult. But once we finished that with the help of some of the BE Java devs, it ran (and still runs) quite stable and also the KeycloakJS adapter I integrated was alright without much surprises.
Next time check the docs and turn off the theme cache: https://www.keycloak.org/docs/latest/server_development/#cre...
> While creating a theme it’s a good idea to disable caching as this makes it possible to edit theme resources directly from the themes directory without restarting Keycloak.
I customized Keycloak 10 login page a while back, and it did not require anything but markup. My Keycloak 18 instance runs the same customization now, unchanged.
I ask because Java in other large open source projects (Elastic Search, Cassandra, Android) and it really depends on how its being used (by Keycloak as well)
I've also come across GraalVM which can significantly reduce Java memory consumption (if that is something you are referring to)
But since you asked, basically Keycloak was by far the single largest component of our stack, which didn't sit well with me because by any measure, our application was far more complex than Keycloak.
At the time we were transitioning away from JEE to JSE microservices, and Keycloak was a full-blown JEE application with all the heaviness that we were successfully leaving behind; it took over a minute to start, while our other Java services would launch in less than a second. Of course this didn't impact production at all - but most engineering time is spent in development and testing, where this was a real problem, especially if we were experimenting with and learning about new features.
All of this contributed to my perception of heaviness.
Seems like your other Java services were not an issue though?
Similarities between our products:
* Overall base feature set (OAuth, OIDC, SAML, user management, authentication, RBAC) is similar.
* Both written in Java.
* Both use container technology to hide Java from you :)
* Both offer commercial support (Redhat SSO is the commercial offering for Keycloak, FusionAuth has paid editions with support). FusionAuth is much less expensive (compare https://marketplace.redhat.com/en-us/products/red-hat-single... with https://fusionauth.io/pricing .)
* Both offer the ability to self-host.
* Both develop in the open (we use GitHub issues, they use a mailing list).
Differences:
* They're OSS, we are free as in beer.
* I haven't found a compelling hosting solution for Keycloak, most folks self host. FusionAuth offers a hosted product if you'd like.
* Keycloak has more niche features (CAS SSO support) and a bigger community.
* FusionAuth has better, more straightforward docs.
* FusionAuth user UI customization is easier.
* FusionAuth supports a number of languages with client libraries for easier config management. I only saw a python client library for Keycloak.
* FusionAuth supports unlimited tenants, limited only by your server's resources. We have folks running thousands of tenants. Last time I looked Keycloak had issues around 400 realms (their term for tenants): https://keycloak.discourse.group/t/maximum-limit-of-realms/8...
Disclosure: I work for FusionAuth.
Don't worry, that was obvious.
1. Put that disclaimer at the top
2. Shrink it to no more than a couple sentences and link to a blog post or something for the detailed comparison. It looks pre-canned and kind of spammy the way it is now
You can run many tenants inside a single realm (we do). They can all log in to their account using Google, LI, etc., as well as email/password.
It's only if your tenant requires SSO, e.g. to their corporate idp, that their own realm is required.
Of course you may choose architecturally to put every tenant in their own realm but that is overkill IMO.
But it sure looks like you can have multiple tenants (in your SaaS application) all against one realm in Keycloak if you don't want that level of separation. In fact, here's an article from 2020 discussing that exact architecture: https://medium.com/swlh/using-keycloak-for-multi-tenancy-wit...
I think of realms as part of a trust model. No realm can safely "trust" another realm's user identities. For example, if I own my own realm, I can set up my own bogus idp and pretend to be the user [email protected], even though I don't own that email or have any access to it.
In our case, the exception is the central realm, where all customers who don't need SSO live. In SaaS, this is usually most customers (> 90% for us). Only larger and more security-minded orgs will want their own SSO and hence their own realm. In the central realm, anyone can authenticate through a set of "trusted" idps (Facebook, Google etc.) as well as good old email and password. This does make the central realm vulnerable to compromise of e.g. Facebook.
While Keycloak is a great out-of-the-box solution, my #1 complaint at the time was how heavyweight it was, which was a burden for development, followed closely by its packaging as a J2EE app and bundling with Wildfly (at the time).
This meant we needed to know not only about Keycloak itself, but also about Wildfly's special quirks, the clustering system (Infinispan??), Java and Docker.
Now it's packaged with Quarkus, which is another dependency to learn about, and to be honest despite the quality of the finished product, all those dependencies have become pretty off-putting.
So while I can recommend Keycloak's functionality, if you're not already deploying Java apps as part of your job, I suspect it will present a pretty serious administrative burden to deploy into serious production.