Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keycloak: Open-Source Identity and Access Management

keycloak.org

Post reply on HN
Print view View original

191–200 of 243 posts

Re: Keycloak: Open-Source Identity and Access Management

#191

Post by vosper »

mooreds wrote: post #173
vosper wrote: post #161

Is Keycloak a good option if I want to setup a SAML Service Provider using user records from my own MySQL database? I've looked at Okta and Keycloak and it's not really obvious to whether I'm supposed to give up my User table and let the auth system handle it, or whether the user data ends up being spread between my DB and the auth system (I think that's how Okta would be implemented). I know I could roll my own with…

Are you asking if you can use Keycloak with your own user table? Typically these identity providers want to own the user, so would expect you to port the user info, including password hashes, into them. If you have data that is user related but not auth related (application specific data), I've seen a few patterns: * Push it all into the auth provider. Not sure about keycloak, but some providers have the ability to s…

> Are you asking if you can use Keycloak with your own user table?

Yes, that's what I'm asking. Because my User table has relationships with the rest of my database, and I want to keep that (user X owns application-item Y; User X created Comment Z on application-item Y, etc... you get it).

> Create a table in your database with an identifier provided by Keycloak, preferably an immutable one. Then when a user logs in, you can find their identifier, then look up the application specific data.

This looks like a good option to me. I'd be fine with PII in Keycloak, and app-specific stuff in my database, provided there's a solid link between the two. If the user wants to change their email, that goes into Keyclock, and if they do something else that is connected to the application function that goes into the app DB.

Thanks!

Re: Keycloak: Open-Source Identity and Access Management

#192

Post by collegeburner »

ffo wrote: post #74
sebmellen wrote: post #69

Earlier quoted context omitted.

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…

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?

Re: Keycloak: Open-Source Identity and Access Management

#193

Post by mooreds »

vosper wrote: post #191
mooreds wrote: post #173

Earlier quoted context omitted.

Are you asking if you can use Keycloak with your own user table? Typically these identity providers want to own the user, so would expect you to port the user info, including password hashes, into them. If you have data that is user related but not auth related (application specific data), I've seen a few patterns: * Push it all into the auth provider. Not sure about keycloak, but some providers have the ability to s…

> Are you asking if you can use Keycloak with your own user table? Yes, that's what I'm asking. Because my User table has relationships with the rest of my database, and I want to keep that (user X owns application-item Y; User X created Comment Z on application-item Y, etc... you get it). > Create a table in your database with an identifier provided by Keycloak, preferably an immutable one. Then when a user logs in,…

Awesome. And I mistyped. When I said:

> Create a table in your database with an identifier provided by Keycloak, preferably an immutable one.

I really meant:

Create a column in a table in your database with an identifier provided by Keycloak. Preferably an immutable identifer from Keycloak.

So you could just add 'keycloak_id' into your normal users table and then you can pull any keycloak managed data back using an API.

Re: Keycloak: Open-Source Identity and Access Management

#194

Post by Perseids »

e1g wrote: post #97
Perseids wrote: post #77

Earlier quoted context omitted.

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

You're right about the complexity and the steep learning curve, but there's hope that OAuth 2.1 will simplify this mess by forcing almost everyone to use a simple setup: authorization code + PKCE + dPoP. No "implicit flow" madness. Another big problem with OAuth is the lack of quality client/server libraries. For example, in JS/Node, there's just one lone hero ( https://github.com/panva ) doing great work against an…

Honestly, DPoP[1] is pretty horrible. It is a partial re-implementation of TLS client authentication deep inside the TLS connection. What's wrong:

- No mandatory liveliness check. That means you don't know whether the proof of possession was indeed issued right now or has been pre-issued by an attacker with past access. Quoting from the spec[2]: """Malicious XSS code executed in the context of the browser-based client application is also in a position to create DPoP proofs with timestamp values in the future and exfiltrate them in conjunction with a token. These stolen artifacts can later be used together independent of the client application to access protected resources. To prevent this, servers can optionally require clients to include a server-chosen value into the proof that cannot be predicted by an attacker (nonce).""" This is a solved problem in TLS.

- The proof of possession doesn't cover much of an HTTP request, just "The HTTP method of the request to which the JWT is attached" and "The HTTP request URI [...], without query and fragment parts." It doesn't even cover the query parameters or POST body. Given rational: """The idea is sign just enough of the HTTP data to provide reasonable proof-of-possession with respect to the HTTP request. But that it be a minimal subset of the HTTP data so as to avoid the substantial difficulties inherent in attempting to normalize HTTP messages.""" In short: Because it is so damn difficult to do it on this layer. Of course, TLS covers everything in the connection.

- Validating the proofs, i.e. implementing the server side of the spec, is super complicated, see [3]. And to do it right you also need to check the uniqueness of the provided nonce see [4] which brings its own potential attack vectors. And to actually provide liveliness checks (see above) you have to implement a whole extra machinery to provide server chosen nonces see [5]. I expect several years until implementations are sufficiently bug free. Again, TLS has battle tested implementations ready.

Best of all? There is already a spec to do certificate based proof of possessions using mutual TLS! See [6]. We really should invest our time in fixing our software stack to use the latter (e.g. by adding JavaScript initiated mTLS in browsers) instead of yet another band aid in the wrong protocol layer.

[1] https://tools.ietf.org/id/draft-ietf-oauth-dpop-08.html

[2] https://tools.ietf.org/id/draft-ietf-oauth-dpop-08.html#sect...

[3] https://tools.ietf.org/id/draft-ietf-oauth-dpop-08.html#name...

[4] https://tools.ietf.org/id/draft-ietf-oauth-dpop-08.html#name...

[5] https://tools.ietf.org/id/draft-ietf-oauth-dpop-08.html#name...

[6] https://www.rfc-editor.org/rfc/rfc8705.html

Re: Keycloak: Open-Source Identity and Access Management

#195

Post by beachy »

mooreds wrote: post #50
doctor_eval wrote: post #24

My company used Keycloak for a long time (I'm not there any more) and I agree with everyone here, it works great, but it's hard to understand unless you already know oauth/oidc, and it is a huge binary. 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…

We hear comments like this a lot. Keycloak has a lot of functionality but also a lot of quirks. We have a product, FusionAuth, that folks often consider at the same time. 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 (Re…

Realms are not necessarily equivalent to tenants in Keycloak.

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.

Re: Keycloak: Open-Source Identity and Access Management

#196

Post by yencabulator »

freedomben wrote: post #145
password4321 wrote: post #87

Earlier quoted context omitted.

> Keycloaks documentation seems vast, but isn't. There is also no way to search inside their documentation. This is one area where incentives don't align correctly for open source projects that offer commercial support.

Disclaimer: Former Red Hatter but worked on OpenShift, not Keycloak Working as a person providing commercial support for open source projects, I promise it doesn't actually work that way. Incentives are entirely for creating good documentation. Having crappy docs only hurts project adoption for paying and non-paying customers, increases the support burden, and wastes the time of your employees (who are the primary co…

Isn't the existence of separate RH product docs (that require log in) a validation of the parent's point?

Re: Keycloak: Open-Source Identity and Access Management

#197

Post by doctor_eval »

ffo wrote: post #181
doctor_eval wrote: post #178

Earlier quoted context omitted.

Apache 2.0 and golang. Thank you! That’s exactly what I was looking for. I’ll check out v2 asap.

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.

Re: Keycloak: Open-Source Identity and Access Management

#198

Post by doctor_eval »

advaitruia wrote: post #100
doctor_eval wrote: post #24

My company used Keycloak for a long time (I'm not there any more) and I agree with everyone here, it works great, but it's hard to understand unless you already know oauth/oidc, and it is a huge binary. 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…

> my #1 complaint at the time was how heavyweight it was, which was a burden for development What do you mean by "heavyweight"? 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)

Well just bear in mind that this was about 4 years ago (we were fairly early adopters apparently), and I understand that my comments here are probably no longer fair, and probably don't apply to KC at it is today.

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.

Re: Keycloak: Open-Source Identity and Access Management

#199

Post by doctor_eval »

collegeburner wrote: post #192
ffo wrote: post #74

Earlier quoted context omitted.

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…

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.

Re: Keycloak: Open-Source Identity and Access Management

#200

Post by mooreds »

beachy wrote: post #195
mooreds wrote: post #50

Earlier quoted context omitted.

We hear comments like this a lot. Keycloak has a lot of functionality but also a lot of quirks. We have a product, FusionAuth, that folks often consider at the same time. 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 (Re…

Realms are not necessarily equivalent to tenants in Keycloak. 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.

Ah, thanks. It probably depends on what you mean by tenant; there's no real accepted definition. By tenant, I mean a separate user space, and I think that is analogous to Keycloak realms. (So dan@example.com in tenant 1 has no connection at all with dan@example.com in tenant 2; separate passwords, different profile data, etc.)

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

Post reply on HN