This part of the IAM space (SSO and AuthN) is so crowded with products, both paid and open source. When you look at governance, certification, lifecycle management, approvals, etc. there is almost nothing by comparison. A couple not so great commercial products and very little open source. Hopefully that changes.
Keycloak: Open-Source Identity and Access Management
71–80 of 243 posts
Re: Keycloak: Open-Source Identity and Access Management
#72Keycloak is great, using it in several projects. The only thing I've been missing is support for IdP discovery services, such as https://seamlessaccess.org/
Re: Keycloak: Open-Source Identity and Access Management
#73Re: Keycloak: Open-Source Identity and Access Management
#74Earlier quoted context omitted.
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
What is your opinion on ORY, specifically ORY Kratos? We have been building on Kratos for some time now and find that it is not super well documented, but it is still a very pleasant experience and their ORY Cloud project is backed by support from their team. How does Zitadel differ/compare? Do you have similar goals as an organization?
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...
Re: Keycloak: Open-Source Identity and Access Management
#75First of all it is not clear if it is stand alone OR SAAS product?
Re: Keycloak: Open-Source Identity and Access Management
#76In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect. Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. It's a pity. A better documentation is contained in the administration web ui itself. There are so many "hints" and tooltips for almost every option there is. It really helped me a lot. Keycloak is good software. I…
You should really be building your own multi-stage container so you can prebake KC_FEATURES and KC_DB into the image.
Re: Keycloak: Open-Source Identity and Access Management
#77In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect. Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. It's a pity. A better documentation is contained in the administration web ui itself. There are so many "hints" and tooltips for almost every option there is. It really helped me a lot. Keycloak is good software. I…
> In Keycloak nothing made sense to me until I got myself familiar with OAuth 2.0 and OpenID Connect.
Hot take: OAuth2 is a really shitty protocol. It is one of those technologies that get a lot of good press, because it enables you to do stuff you wouldn't be able to do in standardized manner without resorting to abysmal alternatives (SAML in this case). And because of that it shines in comparison. But looking at it from a secure protocol design perspective it is riddled with accidental complexity producing unnecessary footguns.
The main culprit is the idea to transfer security critical data over URLs. IIUC this was done to reduce state on the involved servers, but that advantage has completely vanished, if you follow today's best practices to use the PKCE, state and nonce parameter (together with the authorization code flow). And more than half of the attacks you need to prevent or mitigate with the modern extensions to the original OAuth concepts are possible because grabbing data from URLs is so easy: An attacker can trick you to use a malicious redirect URL? Lock down the possible redirects with an explicitly managed URL allow-list. URLs can be cached and later accessed by malicious parties? Don't transmit the main secret (bearer token) via URL parameters, but instead transmit an authorization code which you can exchange (exactly) once for the real bearer token. A malicious app can register your URL schema in your smartphone OS? Add PKCE via server-side state to prove that the second request is really from the same party as the first request...
It could have been so simple (see [1] for the OAuth2 roles): The client (third party application) opens a session at the authorization server, detailing the requested rights and scopes. The authorization server returns two random IDs – a public session identifier, and a secret session identifier for the client – and stores everything in the database. The client directs the user (resource owner) to the authorization server giving them the public session identifier (thus the user and possible attackers only ever have the possibility to see the public session identifier). The authorization server uses the public session identifier to look up all the details of the session (requested rights and scopes and who wants access) and presents that to the user (resource owner) for approval. When that is given, the user is directed back to the client carrying only the public session identifier (potentially not even that is necessary, if the user can be identified via cookies), and the client can fetch the bearer token from the authorization server using the secret session identifier. That would be so much easier...
Alas, we are stuck with OAuth2 for historic reasons.
Re: Keycloak: Open-Source Identity and Access Management
#78Have used and brought keycloak into many companies over the years as a solution. Steep learning curve a little. But it essentially works as designed either as the IDP (rare in my exp) or as a IAM broker more common. Big companies need it because their hands are tied to old and inflexible vendor's APIs. However they can with some effort craft a branded and modern UI/UX. Backend works with just about anything old Auth…
The secret to making keycloak UI/UX good is to disregard the account console and build your own with the new accounts API (which the accounts2 console also uses).
Also, if you just use one broker you can skip the login experience entirely.
Re: Keycloak: Open-Source Identity and Access Management
#79First of all it is not clear if it is stand alone OR SAAS product?
It's the open source project that RedHat SSO is derived from, in the same way that OKD is the open source project that OpenShift is derived from.
Re: Keycloak: Open-Source Identity and Access Management
#80[deleted]