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

201–210 of 243 posts

Re: Keycloak: Open-Source Identity and Access Management

#201

Post by mooreds »

mberning wrote: post #71

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.

> When you look at governance, certification, lifecycle management, approvals, etc

What do you mean by these?

Are you talking about SOC2/ISO27001 when you say certification?

Are you talking about provisioning/deprovisioning users (SCIM, etc) when you say lifecycle management?

What do you mean by approvals? Role changes requiring designated approval, or something else?

Re: Keycloak: Open-Source Identity and Access Management

#202

Post by beachy »

mooreds wrote: post #200
beachy wrote: post #195

Earlier quoted context omitted.

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…

Separate user spaces are achievable within a single realm. In our case, we do it using an account chooser within our application code. After logging in, you select the account you want to work within.

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 president@whitehouse.gov, 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.

Re: Keycloak: Open-Source Identity and Access Management

#203

Post by freedomben »

_jal wrote: post #164
freedomben wrote: post #145

Earlier quoted context omitted.

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…

I can tell you that at least as of late last year, the OpenShift install docs omitted key details for setting it up. We were unable to do so until contacting RH and getting additional instructions - I forget the all the details, part of it involved creating DNS records mentioned nowhere in the docs.

If you can remember which ones, I'd be interested. I installed OpenShift a dozen or so times using those docs and I don't remember having to add any DNS records that weren't in the docs. I also grepped my notes and don't see anything. That said I do remember the DNS records being on a page that wasn't the one I thought it should be on.

Something I do criticize them for though (this is a problem in broader tech not just Red Hat) is that they are aggressive at culling/cutting old docs. The idea is to keep the docs small and relevant, but unfortunately in my opinion they cut valuable stuff. I always screen grab/print docs at the time in case they get removed because that's been a wide problem.

Re: Keycloak: Open-Source Identity and Access Management

#204

Post by freedomben »

pas wrote: post #167
_jal wrote: post #164

Earlier quoted context omitted.

I can tell you that at least as of late last year, the OpenShift install docs omitted key details for setting it up. We were unable to do so until contacting RH and getting additional instructions - I forget the all the details, part of it involved creating DNS records mentioned nowhere in the docs.

How open is OpenShift? Is there a bug where this is tracked and are people contributing at least through issue comments? And response from committers?

If you have a Red Hat subscription for OpenShift, then yes.

Although, unless it's high priority (like it's breaking functionality and there's no workaround) it's not usually a quick turnaround because it has to get prioritized and added to a sprint. It can take weeks or months. Although I did have a high-pri item fixed in under a day, so it does happen.

Re: Keycloak: Open-Source Identity and Access Management

#205

Post by RandomBK »

psankar wrote: post #2

We tried using keycloak in a startup where I worked. It needed a loooooooot of memory and was very slow to start. It probably needed some JVM tuning, but we were just deploying as a stateful set (for the postgres). The docker images were also huge. We had to use another FOSS project called Gatekeeper as an authentication software along with keycloak, which got obsoleted and replaced with a different project (lukedo p…

In my experience, Keycloak is best treated as a "pet" in the "pet v.s. cattle" spectrum. It takes a while to warm up, so you don't want to be constantly restarting it. I deployed it out-of-sync with the main application deployments.

As an open source option, it's quite powerful and full-featured. It's also quite configurable.

If I had one feature ask, it's that it doesn't play well with infrastructure-as-code ideas. While you can load a new realm from a JSON, it's harder to keep changes synced after that.

Re: Keycloak: Open-Source Identity and Access Management

#206

Post by johnmarcus »

schipplock wrote: post #20

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

I'm litterally about to jump from 8 to 17 this week, so that's good to hear. It seemed seamless on my local setup and was wondering if it was just too good to be true. It's a great piece of software.

You are correct about the documentation. I find the tragedy of open source documentation is that the people who need it most - the novices - are the ones whom could write it best - if they only knew if what they were saying was accurate. And then by the time you become an old-timer, and know thy ways, you just want to wipe your hands and walk away, because your tired....and still not sure if all your knowledge is accurate.

But anyway, once it's all figured out, it runs very reliably.

Re: Keycloak: Open-Source Identity and Access Management

#207

Post by easrng »

littlecranky67 wrote: post #110
e1g wrote: post #97

Earlier quoted context omitted.

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…

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.

It depends on the provider. For Mastodon and Pleroma, there's an endpoint to get generate a client ID/secret that you can call on the client. The flow is basically

  1. Prompt for an instance name
  2. Get a client id/secret from the instance and put it in localStorage
  3. Redirect to the login page
  4. Once you get the callback, get the token using the code and the client ID/secret from localStorage
  5. You're done. No server needed.

Re: Keycloak: Open-Source Identity and Access Management

#210

Post by sigzero »

ffo wrote: post #49
davidcollantes wrote: post #15

We 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 ;-)

Make sure you get v2 on the HN front page!
Post reply on HN