It’s Java based :—(
Yup, and to me that's great and goes into the "pros" and not "cons" column.
Keycloak: Open-Source Identity and Access Management
211–220 of 243 posts
Re: Keycloak: Open-Source Identity and Access Management
#212[dead]
Re: Keycloak: Open-Source Identity and Access Management
#213Earlier quoted context omitted.
Love it, we will definitely create a post here in the next 2-4 weeks.
Your v2 pricing model is lame. I was literally pulling out my credit card when I saw the original pricing.
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 :-)
Re: Keycloak: Open-Source Identity and Access Management
#214Earlier quoted context omitted.
Thank you, v2 will be ready in the next 2-4 weeks. We are already running it internally ;-)
Oh yeah I came here to ask "when". 2-4 weeks is brilliant. Hopefully this is my IAM strategy sorted and I can worry about some other stuff instead :) I'm really impressed with your strategy and v2 looks like a really great upgrade.
Thank you ;-) we will keep you posted.
Re: Keycloak: Open-Source Identity and Access Management
#215Earlier quoted context omitted.
Looks nice, but the CockroachDB dependency is kinda a pain for people not already using that. Any plans for alternative db support, like Maria or Postgres?
If CockroachDB supports the PG wire protocol and appears to be a functional subset of PG then in theory we might be able to just point it at a PG database and it might work :) I too would prefer to use PG than Cockroach, if only because I have ops experience with PG. But Cockroach is certainly intriguing.
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?
Re: Keycloak: Open-Source Identity and Access Management
#216Earlier quoted context omitted.
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 ;-)
Make sure you get v2 on the HN front page!
Will do ;-)
Re: Keycloak: Open-Source Identity and Access Management
#217Earlier quoted context omitted.
If CockroachDB supports the PG wire protocol and appears to be a functional subset of PG then in theory we might be able to just point it at a PG database and it might work :) I too would prefer to use PG than Cockroach, if only because I have ops experience with PG. But Cockroach is certainly intriguing.
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 t…
Thanks for taking the time to answer everyone's questions, and for asking me this one.
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 :)
Re: Keycloak: Open-Source Identity and Access Management
#218Slightly out of topic, but based on Caddy, has anybody experience with Caddy Security[0]? It is very easy to install but hard to find other users. [0]: https://github.com/greenpau/caddy-security
(Caddy maintainer here) I don't use that plugin myself but AFAICT most users ask questions on the GitHub repo so probably best to ask for help there if you need it.
As an aside, I've been working on making the Forward Auth usecase viable with Caddy, and we just got it working today https://github.com/caddyserver/caddy/pull/4739
Re: Keycloak: Open-Source Identity and Access Management
#219We are currently using Shibboleth, and would love to get away from using java/Tomcat. It looks like Keycloak also uses java. Is there an alternative to this that doesn't require it?
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 ;-)
Does it/will it support Forward Auth style usage for plugging in with reverse proxies? Asking as a Caddy maintainer, I'm working on this right now and we've been working with Authelia to test it out, would be cool to get it working with another Go auth server! See https://github.com/caddyserver/caddy/pull/4739
Re: Keycloak: Open-Source Identity and Access Management
#220Earlier quoted context omitted.
The problem with the authorization code flow is, it was not build with SPAs in mind. I.e. you always need a server-side component that obtains those tokens. So a 100% client/FE solution based on NextJS/React/angular/vue etc. can not simply be deployed to a CDN and then use Auth0/AWS Cognito/Azure AD whatever without running and hosting your own server-side component.
There is a document meant for best practices for browser-based apps such as SPA/PWA, which includes use of code flow. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-brows... (disclaimer - co-author) The catch is that since the client web origin and AS web origin are often different sites, the AS has to actually implement CORS on their token endpoint. Some implementations unfortunately (perhaps due to a misund…
I appreciate you work on clarifying the situation. But my statement still stands, and you seem to back it up in your draft:
> The JavaScript application is then responsible for storing the access token (and optional refresh token) as securely as possible using appropriate browser APIs. As of the date of this publication there is no browser API that allows to store tokens in a completely secure way.
So with OAuth 2.0 + PKCE and no BE component, the tokens are directly exposed to the client, just as they were with the implicit flow. Also, if I'm not mistaken, PKCE extension is optional in OAuth 2.0, and without it you cannot securely use the code flow (as you would have to expose the client secret).