ffo

I would love to chat with you guys.

Hit me up with a mail florian(at)zitadel.com

We know them ;-)

From the IAM perspective (If the service is an IAM) I agree. But as SaaS provider I don’t want to use multiple realms because in that case my client would need to understand multiple issuers.

Also Keycloak has a cutoff of around 400 ish realms last time I checked ;-)

Currently we provide a container image as well as K8s support.

The v2 will allow us to extend our support to a plain binary as well as serverless containers (Knative et. al)

Keycloak is a great tool but definitely not has B2B features like user management for each business customer, self service and delegated access management as well as self service federation.

If you feel that I am mistaken, feel free to point out the docs to that ;-)

Haha or the good old netsend fun on school pcs ;-)

Hm, interesting it need to check that ;-)

Hi there

First and most importantly, thank you for maintaining such a cool project with caddy! I use it all the time as nginx alternative (even though of being an nginx fan in the past).

We do not directly support "forward auth" concepts. But what you could do is to use OpenID Connect to Authenticate the user prior of allowing traffic to flow to upstream services. That's more or less what the oauth2-proxy does as well.

The reason why we are not so fond of "forward auth" is that in many setups authentication needs to scale beyond on ingress and in that case it makes more sense to create a centralised session for a user with an identity system.

If you are intrigued to discuss this subject I would encourage you to join our discord https://zitadel.ch/chat

We too ;-)

Well thank you for your time. Let me check with the team. I am certain we can release 2.X with a Postgresql support ;-)

I created an issue for further tracking https://github.com/zitadel/zitadel/issues/3598

Will do ;-)

Thank, we hear you! Currently we are discussing two things for this subject.

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?

Thank you ;-) we will keep you posted.

Thanks for the feedback.

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 :-)

Agreed, I mean that's why we built our solution completely open source in an open saas model and certified [1] our solution. We even provide our pentest results publicly, after mitigation of course [2].

The value we provide, when you are using our cloud, is the operational peace of mind, global scalability with data residency and access to deep technological knowledge.

We wrote some word about that in our blog [3] as well.

1. https://zitadel.ch/blog/openid-connect-certification

2. https://zitadel.ch/blog/pentest-results-h1-2021

3. https://zitadel.ch/blog/saas-vs-self-hosted

Love it, we will definitely create a post here in the next 2-4 weeks.

True, we think that for most setups and early explorations K8s is too much of a beast. TBH we are in the process of switching our cloud from K8s to Cloud Run which is kind of close to Knative but without the ops hustle ;-)

Thank you, v2 will be ready in the next 2-4 weeks. We are already running it internally ;-)

Thank you too. Feel free to join our chat and ask questions any time https://zitadel.ch/chat (discord)

Well to keep it brief, we see it the following way. Use:

- 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...

2. https://zitadel.ch/pricing/v2

Maybe https://github.com/zitadel/zitadel could be an alternative to you.

Its written in Go, can be self-hosted or used from a cloud service.

It will also soon (end of May) provide SAML 2.0 support besides the current OpenID Connect and OAuth support.

Disclaimer: I am one of the authors ;-)

You might want to have a look on zitadel [1]

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

1. https://github.com/zitadel/zitadel/

2. https://zitadel.ch/blog/zitadel-vs-keycloak

We will also extend the certification to more RP profiles and OP as well in the coming months

Maybe the sell there leftover ingress bandwidth to apple :-)

hey don't forget samesite ;-)

From a design perspective you are right.

But from a threat model I would dare to say, if you control the platform (OS, Cloud Service) you can easy bypass encryption or deploy your own keys as well.

In the end it is still a trust question.

Oh yes, they are hideous.

Thank you, this really well summarises my article.

Totally agree with your point here. Would love to see a TB implementation depending on hardware keys. But yeah it is gone.

If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)

To use ip binding as means already fails today. I mean CG-NAT and the slow adoption of ipv6 also did help dig that grave and I would argue that with that you can't rely on the IP because it is volatile anyway.

From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.

With the Developer Beta 2 it was more consistent in staying somewhat in the region. But still if you IP is consistently changing it is hard to adapt. Btw. Oftentimes Geo Databases are wrong as well.