[HN Gopher] Keycloak: Open-Source Identity and Access Management
___________________________________________________________________
Keycloak: Open-Source Identity and Access Management
Author : memorable
Score : 345 points
Date : 2022-05-04 09:59 UTC (13 hours ago)
(HTM) web link (www.keycloak.org)
(TXT) w3m dump (www.keycloak.org)
| s1mon wrote:
| Does Keycloak or any of the alternatives mentioned here do a good
| job of supporting localization? What about customization of the
| email messages for lost password flows?
| mooreds wrote:
| Can't speak for Keycloak, but FusionAuth supports localization
| of both user facing HTML and email/SMS messages. (Not the admin
| screens, alas.)
|
| More details here: https://fusionauth.io/docs/v1/tech/core-
| concepts/localizatio...
|
| 15 languages have user facing translations:
| https://github.com/FusionAuth/fusionauth-localization/
|
| Disclosure: I work for FusionAuth.
| adlerhurst wrote:
| zitadel allows to change the texts of emails and login texts,
| but at the moment only for languages already supported at the
| moment of writing en, it, de
|
| disclaimer: I'm one of the authors of ZITADEL
| donatzsky wrote:
| Ory Kratos and Hydra are API only and so don't provide a UI.
| Localisation then is entirely up to you.
| jcadam wrote:
| Keycloak is great if you need an SSO solution. We had a large
| number of small in-house applications at my previous job and
| managing logins was becoming a pain.
|
| At my current job we use Okta. While the documentation is better,
| I don't think I prefer it over KC.
| JacobiX wrote:
| I've integrated keycloak for SSO in our apps, we have a one-to-
| one mapping between keycloak realms and the tenants in our apps,
| works great and it can glue together many disparate IdP/auth
| solutions: onelogin, LDAP/AD, etc. At one moment we needed to
| implement a custom OTP method, so we developed a plugin by
| implementing a simple SPI (the auth flow is configurable). It is
| a very stable piece of software, we have a combination of
| Terraform+ansible scripts to deploy it, and once it is done we
| forget about it until we need to upgrade the version using the
| same scripts. The biggest drawback IMHO is the documentation
| quality ...
| orthoxerox wrote:
| Keycloak is a great piece of software if you have to authenticate
| against AD (on prem, not Azure AD). It's the best way to isolate
| all the crap like "user accounts live in this OU, but admin
| accounts live only in that OU. Oh, and we also have another
| domain where contractors live in the same OUs. And the groups
| that map to application roles are the same, but live in
| differently named OUs" and provide a simple OAuth 2.0/OIDC
| authentication/authorization interface to all this mess.
| kitsune_ wrote:
| Documentation is its weak point, other than that it works as
| intended.
| jcmontx wrote:
| I like IdentityServer4 even though is not supported anymore
| [deleted]
| zmmmmm wrote:
| Recently deployed Keycloak as a front end to hide legacy auth in
| our org and put OAuth in front of it. Despite the apparent
| complexity under the hood, it works great and no complaints so
| far. By and large, it just does what it says on the tin and
| works.
| littlecranky67 wrote:
| As others mentioned, Keycloak is a good choice if you need a
| self-hosted IAM solution and are familiar with Java development.
|
| If you don't need selfhosted, I can recommend using Amazon AWS
| Cognito as a OAuth2/IAM solution - it is included in the free
| tier for up to 50.000 MAUs, plus the signup/lost password mails
| etc. are sent through Amazon SES, which heavily increases the
| inboxing rate. You could always transition later to a self-hosted
| solution like keycloak. Given both are OAuth2, that transition
| should be smooth.
| mooreds wrote:
| What are your main reasons for recommending Cognito? That it is
| free and easy to get going with?
|
| Have you customized the user login experience?
|
| I only ask because I've heard folks talk about how Cognito does
| the basics right (which is great, no one should roll their own
| auth) and is quick to get started with, and is serverless and
| free (unless you want SAML connections).
|
| But once you get past the basics, it turns into a ton of
| hassle. And there's been little progress in feature
| set/docs/etc (though last year they did do a UI refresh).
|
| * https://twitter.com/zackkanter/status/1488297503455956992
|
| * https://fusionauth.io/blog/2020/11/18/reconinfosec-
| fusionaut...
|
| They also don't let you export your password hashes, so when
| you transition to a self hosted solution, you must force your
| users to reset their passwords (or perform a drip migration). I
| wrote about these options here:
| https://fusionauth.io/blog/2022/02/07/how-to-migrate-from-co...
|
| Disclosure, I work for a Cognito competitor, FusionAuth.
| littlecranky67 wrote:
| I just checked prices of FusionAuth, and clearly your company
| is not interested in smaller side-gig like customers or self-
| funded startup that need to grow. Basic, production cloud
| options (non-eval) start at $162/mo for 10.000 MAUs. Once I
| move the slide to over 10.000MAUs the basic option is gone,
| and the cheapest option suddenly jumps to $1062/mo.
| mooreds wrote:
| Thanks for taking a look. For your use case, I'd probably
| recommend self hosting community edition. FusionAuth price:
| $0.
|
| You could do this on ec2, etc, or there's a heroku 'one
| click deploy':
| https://elements.heroku.com/buttons/mickeymond/fusion-
| auth-h... This is the path most folks using FusionAuth for
| side-gig use.
|
| You can download the community edition here:
| https://fusionauth.io/download
|
| For smaller companies, we recommend business cloud with
| community edition, which starts at $225/month. The basic
| hosted version doesn't have backups and so isn't suitable
| for prod use. I get that this is a lot for a side project
| (I wouldn't use it for one). Or a self-funded startup--I
| remember one startup where the entire application was
| running on about $75/month in hosting spend on heroku. No
| way would I have paid $225/month for auth.
|
| We have a slightly complicated pricing model (with both
| hosting and licensed editions, creating a matrix that is
| not typical), but I truly appreciate your feedback and will
| share it internally.
|
| Edit: Added startup anecdote.
| littlecranky67 wrote:
| Yes, I mostly recommend it because it is free and I've used
| before, plus I've been on several projects where we used
| Keycloak. For me, Cognito's 50.000 monthly active users is
| probably all I will ever need, and as you said, its quick to
| get started. Keycloak is the other way around, you will have
| to invest beforehand into learning and running it. Also, if
| you allow self-signup by your users, Email inboxing is a
| serious issue. So even if you run Keycloak yourself, you must
| think how you are going to deliver emails - which will bring
| you to other SaaS services like MailChimp or AWS SES anyway.
|
| I can't speak about FusionAuth or Auth0, but yes, other SaaS
| might be as good as Cognito as well - but I do not know their
| free tiers.
|
| Disclaimer: I am not working for any of those, just a small
| side-gig SaaS builder/WebDev speaking of my experience.
| mooreds wrote:
| Thanks for sharing your rationale, makes a ton of sense.
| Cognito's free tier is great and frankly, takes auth off of
| many folks' plate. Which is a good thing.
|
| I've heard similar things about Azure AD B2C. Strangely,
| Google has a comparable offering (
| https://cloud.google.com/identity-platform ) but I've never
| talked with anyone using it.
| mberning wrote:
| 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.
| ffo wrote:
| 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
| altonaut wrote:
| Is there a minimal config to run and setup keycloak with docker
| for local development? Most sources suggest exporting and reusing
| a reale-export.json, but it is missing the user datas and
| includes lots of (default) options and random uuids. There is a
| example repo, but it seems out of date and missing some settings:
| https://github.com/keycloak/keycloak-demo/blob/master/demo-r...
| davidcollantes wrote:
| 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?
| yawniek wrote:
| possibly https://www.ory.sh/
| sascha_sl wrote:
| ORY is amazing, but it also requires significiant investment.
| It's a headless API (so you never have to touch OAuth/OIDC
| internals) for building your own IdP.
| mooreds wrote:
| FusionAuth uses Java to, but if you use Docker/kubernetes, you
| don't really have to think about it:
| https://fusionauth.io/docs/v1/tech/installation-guide/docker
|
| And even if you don't, we install our own Java and manage it
| for you, so there's no Tomcat WAR file installation or anything
| like that.
|
| Disclosure: I work for FusionAuth.
| bfm wrote:
| We are currently evaluating self hosting supabase auth.
| ffo wrote:
| 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 ;-)
| sharkbird2 wrote:
| Keycloak 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/
| psankar wrote:
| 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 proxy or some
| such).
|
| The community support was also relatively not that active like
| other FOSS project that we used (for other areas of the stack).
| Overall, the experience was not so great that we decided to ditch
| both keycloak and gatekeeper. This was about a couple of years
| back. Not sure what the current status is.
|
| Some other alternatives that we wanted to try were from the Ory
| project (Kratos etc.) But we just went with some proprietary AUTH
| solution in our startup.
| Datagenerator wrote:
| Which?
| sz4kerto wrote:
| Keycloak is now running on Quarkus, so startup times are much
| faster (few seconds). But -- KC is not something you start up
| often (in production).
|
| It's reliable, flexible and actively developed, so not a bad
| choice as a self-hosted IAM solution.
| vetinari wrote:
| With Quarkus, they went into other extreme -- if you are
| using docker, to get as fast startup as possible, you have to
| build your image with your configuration/modules used baked
| in.
|
| Overall, I'm pretty satisfied. There are some bumps, but they
| are not Keycloak fault (having two different keytabs for two
| different host names for two different container images
| sharing same IP and reverse name not matching is kind of
| difficult).
| pharmakom wrote:
| There is an auto-build option so building a custom Docker
| image is an optimisation.
| nird wrote:
| We have been using it for 6-7 years now. Have been able to run
| very stable and integrated a lot of external IdP's to offer
| proper SSO on mulitple of our software stacks. Added a lot of
| other open source pieces of software we run for our backoffice
| needs (hashi vault, adminbro, etc.). So far very happy with it.
| Running in clustered mode without issues and as such little
| issues with the startup times. It probably helps that we have a
| solid background in Java based development and deployment and
| are less worried about the amount of memory it uses for the
| full suite.
| lifeisstillgood wrote:
| This fascinated me - where and how does this fit into other
| identity providers (and thence into SSO).
|
| I kind of yearn for client certificates everywhere simply
| because I can grok how that remains secure as we pass through
| layer after layer. the rest I just worry about
| bayesian_horse wrote:
| keycloak can broker between identity providers. It can use
| social logins as identity providers, connect to ldap,
| kerberos and others for user federation, and then provide
| SAML and OpenIDC to other applications.
| paulmd wrote:
| As someone who has superficially looked into it a couple
| times and gotten pushed away by the complexity: what do
| you recommend for a backend? Is there another container
| that provides an LDAP service I could use? Or Kerberos?
|
| I am rebuilding my homelab soon and I am interested in
| having centralized auth across all systems and as many
| applications as feasible, using my centralized fileserver
| as an IDP source via some application or another, as well
| as using Keycloak for some one-off projects where I don't
| really want to write a user layer.
| sn0wf1re wrote:
| Personally I just use Keycloak as the backend(storing the
| user and group information). I provision it with
| terraform since I find it easier to use than the webUI.
| nird wrote:
| Exactly this. OIDC and SAML integrations with customers
| IdP's. Map identity metadata from the customer into our
| realm so they can provide data in any way they want and
| we map it down to our standard which allows our
| applications to stay clean when using this metadata for
| business logic.
|
| We have also added an event plugin to keycloak to push
| login events to a queue for other services to consume.
|
| We also offer local keycloak identities in case a
| customer does not or can not provide their own
| identities, and have added haveibeenpwnd logic to check
| password strength/reuse for these local keycloak
| identities.
| brightball wrote:
| Does it support webAuthn?
| mooreds wrote:
| Yup. Here's the doco for configuring it:
| https://www.keycloak.org/docs/latest/server_admin/#_webauthn
| brightball wrote:
| Thanks! Didn't see it when I was browsing.
| bayesian_horse wrote:
| Yes
| jeroenhd wrote:
| Yes, I've seen it used both as primary factor and as a second
| authentication factor (I'm not sure you would ever need it as
| 2FA, but whatever). Requires some setup, though.
| schipplock wrote:
| 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. It never failed for me. Even upgrading
| from 7.x.x to 16.x.x somehow just worked.
|
| Yes, their docker image is fat, but it's also very flexible. Now
| that they are basing Keycloak on Quarkus instead on Wildfly, the
| docker image should shrink in size.
| quay.io/keycloak/keycloak 18.0.0
| a6bd0f949af0 15 hours ago 562MB
| quay.io/keycloak/keycloak 18.0.0-legacy
| 421e95f49589 46 hours ago 753MB
|
| ok, still big :).
|
| Beware: they aren't using Docker Hub anymore. Newer versions are
| on Quay only (https://quay.io/repository/keycloak/keycloak).
|
| I'm happy with Keycloak. Also nice folks around Keycloak.
| tamarok wrote:
| For the most part I am also happy with Keycloak, but they could
| do a far better job documenting things, especially their
| language adapters. For example the "Readme" for the `keycloak-
| connect` Node.js package has a link to documentation, but that
| documentation fails to document anything around the package.
|
| Likewise I had better luck once I understood OpenID and then
| treating Keycloak as an extension of that. I even ended up
| writing my own code to deal with the bearer token passed to our
| API, because I couldn't find anything. If anyone is interested
| I can share it, but it isn't anything amazing.
|
| Most of my best help came from outside of the Keycloak support
| groups and instead reaching out to other people who use
| Keycloak.
| password4321 wrote:
| > _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.
| [deleted]
| freedomben wrote:
| 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
| consumers of that documentation).
|
| Usually documentation isn't great because writing (and
| maintaining!) good documentation is really hard. It's a
| continual effort and it takes engineer time away from bug
| fixes and feature dev, two things for which there is never
| ending demand for.
|
| Edit: Pro-Tip: With Red Hat projects (like Keycloak, OKD,
| etc) it's always worth looking at the RH product docs as well
| as "open source" docs. For example if you use OKD, check
| OpenShift docs as well as OKD docs. You do (unfortunately and
| I wish they'd remove this) usually have to log in to a Red
| Hat account but you don't have to pay. You can create a free
| account and use that.
| _jal wrote:
| 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.
| pas wrote:
| 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?
| yencabulator wrote:
| Isn't the existence of separate RH product docs (that
| require log in) a validation of the parent's point?
| password4321 wrote:
| Thank you for taking the time to share your first-hand
| perspective!
| smcnally wrote:
| > This is one area where incentives don't align correctly for
| open source projects that offer commercial support.
|
| This is true in some[0] cases. It's also true that
| documentation is key source of customer acquisition and
| retention.
|
| Projects get traction by making it useful out of the box[1]
| for some use-cases, making it appealing for hackers to config
| and extend, teasing features the former would pay for and the
| latter could figure out the buy v build.
|
| Projects that do this well also learn shittons from real-
| world usage and feedback informing their roadmap and new
| opportunities to pursue.
|
| [0] True when the perspective is " _If we make the docs too
| good we 're losing revenue_" / " _Everyone using Feature X
| gratis is a loss in MRR_. " It's an understandable view
| that's held widely. It's not often a significant revenue
| factor in my experience, and ~never when accounting for
| product and market insights gained by wider adoption.
|
| [1] https://news.ycombinator.com/item?id=31259034
| chrisoverzero wrote:
| > Beware: they aren't using Docker Hub anymore. Newer versions
| are on Quay only
|
| Oh, right, Quaycloak.
| zeepzeep wrote:
| Quaaludes... what?
| mooreds wrote:
| > Beware: they aren't using Docker Hub anymore.
|
| Do you know why? Is it because of the docker hub pricing
| changes?
|
| I found this discussion on the mailing list but didn't see a
| reason why: https://lists.jboss.org/pipermail/keycloak-
| user/2019-March/0...
| mkdirp wrote:
| Pretty sure it's because the core devs are RH employees, who
| owns Quay. Seems reasonable to keep things on your own infra.
|
| Having said that, I know there has been some falling out
| between RH and Docker some time ago, which was one of the
| reason RH ended up creating Podman.
| papercrane wrote:
| This is the publicly stated reasoning:
|
| https://lists.jboss.org/pipermail/keycloak-
| user/2019-March/0...
|
| Mostly I think the answer is just that it's a Red Hat project
| and Red Hat wants to use their ecosystem.
| [deleted]
| paulmd wrote:
| > 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.
|
| To echo everyone else: the Keycloak documentation does not do a
| good job of hand-holding you at all, and the number of possible
| ways you can configure and use the system and the amount of
| jargon and terminology used is massively overwhelming to
| someone trying to get started. It would be very helpful to have
| some "white paper"-esque summaries that walk you through some
| simple, typical use-cases.
|
| I looked through the docs quickly before making this post and
| as an example here's a basic task for initial setup ("hook up
| an IDP", basically giving keycloak its database of users), and
| it's utterly incomprehensible to any human being who doesn't
| already know how to work the system and really essentially
| worthless even then. It's just... reading me the command line
| options and a couple config files? What do any of those values
| even mean? This is _core functionality_ for Keycloak, and the
| documentation consists of "yeah, here's a command line with
| placeholders and a text file syntax, good luck bitches!".
|
| https://www.keycloak.org/server/configuration-provider
|
| Honestly I feel like you could do better simply by jumping into
| the UI and playing with options, it's not _entirely_
| unintuitive what 's going on in the UI, but the docs are
| basically incomprehensible.
|
| I actually know of several projects that have pretty much
| bogged down because of Keycloak configuration or role/privilege
| mis-configuration issues and it's not hard to see why. It's the
| turing tar-pit of IDP, everything is possible and nothing is
| easy (or documented). Which is a shame because it seems like an
| awesome piece of software, just inscrutible to the un-
| initiated.
|
| As others are noting, I'm sure some of this is due to OAuth2
| being an inscrutable piece of shit in general, same thing, it
| tries to do everything and it's so un-opinionated that you end
| up with a bunch of basically incompatible implementations that
| are each effectively their own "standard" anyway.
|
| (posted this on the wrong child, moving it to the parent)
| jonkoops wrote:
| We're actually working on a new version of the Administration
| UI at the moment (I'm one of the devs) so this is useful
| feedback. We're looking for folks to try it out, so take a look
| at https://github.com/keycloak/keycloak-admin-ui/.
|
| You can try it out on the latest Keycloak by passing the
| --features=admin2 flag on startup.
| newera2016 wrote:
| We have way too many issues with KeyCloak. Sometimes I wonder
| why did we integrate this. One of the main issue is when you
| authorize by Github but cancel the authentication, it
| redirects to KeyCloak page rather than our login page.
| Couldn't find any solution yet.
| mpfundstein wrote:
| isnt it open source?
| tamarok wrote:
| Will this have an impact on the auth screens and the related
| theming?
| sascha_sl wrote:
| You should really be building your own multi-stage container so
| you can prebake KC_FEATURES and KC_DB into the image.
|
| https://www.keycloak.org/server/containers
| schipplock wrote:
| We still use an old version without Quarkus :). But yes,
| that's the way to go.
| yrro wrote:
| Can you disclose the number of users & apps you have? Are you
| using Keycloak or do you pay for Red Hat Single Sign-On (for
| context, that's the name of the downstream product that Red Hat
| sell subscriptions for).
| X-Istence wrote:
| The downside to using Red Hat Single Sign-On is that it is a
| vastly inferior product to using Keycloak upstream as it is
| so many versions behind.
|
| This means that bug fixes and features haven't trickled down
| yet. Although RH SSO 7.5 jumped from Keycloak version 9.0.17
| (in RH SSO 7.4) to 15.0.2 so there's some improvement
| there... but Keycloak just released 18.0.0...
| schipplock wrote:
| We are using keycloak, not SSO. There is no long-term-support
| keycloak version available, so we are considering buying into
| Redhat SSO.
| 0xbadcafebee wrote:
| > Newer versions are on Quay only
|
| Thanks for mentioning this, I didn't realize Keycloak is a
| RedHat product. I'll plan to move to something else. Anything
| RedHat makes turns into a catastrophe.
| Perseids wrote:
| > 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.
|
| [1] https://aaronparecki.com/oauth-2-simplified/#roles
| sascha_sl wrote:
| For most Keycloak users, a very tiny subset of OIDC is being
| used too. Usually there is no three way relationship between
| a third party developer, an API provider and a user anymore.
| You could rip scopes out of Keycloak and few users wouldn't
| be able to cover their use cases. Rarely is there more than
| one set of scopes being used with the same client.
|
| Keycloak also supports some very obscure specs, my favourite
| probably being "Client Initiated Backend Authentication"
| which can enable a push message sent to authenticator app
| type authentication flow using a lot of polling and/or
| webhooks.
| e1g wrote:
| 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 army of rubbish JWT/OAuth libs.
| littlecranky67 wrote:
| 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.
| e1g wrote:
| Even for 100% FE solutions, the current best practice
| from OAuth authors [1][2] is to use authorization code +
| PKCE (optionally, +dPoP). The implicit flow is deprecated
| (since PKCE), and from OAuth 2.1 it will be removed
| entirely.
|
| [1] https://datatracker.ietf.org/doc/html/draft-ietf-
| oauth-secur...
|
| [2] https://auth0.com/docs/get-started/authentication-
| and-author...
| dwaite wrote:
| 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
| misunderstanding about what CORS is meant to accomplish)
| make this a per-tenant/per-installation allowlist of
| origins on the AS.
|
| Auth0 and Ping Identity (my employer) document CORS
| settings for products. I'm not sure about AWS and you
| might need to add CORS via API gateway. Azure AD supports
| CORS for the token endpoint, but they may limit domains
| in some manner (such as redirect uri of registered
| clients).
|
| FWIW, I created a demo ages ago (at
| https://github.com/pingidentity/angular-spa-sample),
| which by default is configured to target Google for
| OpenID Connect and uses localhost for local
| development/testing. It hasn't aged particularly well in
| terms of library choices, but I do keep it running.
|
| A deployment based on older Angular is also at
| https://angular-appauth.herokuapp.com to try - IIRC I
| used a node server just to deal with wildcard path
| resolution of the index file, but there's otherwise no
| local logic.
| zmxz wrote:
| SPA is HTML/JS served by the _server_. We don 't need
| client-only solutions. We need devs to understand how
| HTTP and browsers work.
|
| It means that we simply keep using what actually works,
| i.e. serverside component that obtains authorization and
| we use simple mechanisms to ensure token stays at the
| server and FE speaks to the server which in turn speaks
| to the target app. Proxying is not that difficult of a
| problem and we don't have to run in circles, inventing
| different flows only to cater to devs who can't learn
| their field.
| spion wrote:
| You've misidentified the problem.
|
| We need CDN solutions for front-ends because that's the
| best way to deliver great, scalable performance for
| complex SPAs.
|
| We also need a purely client-side flow for mobile
| (native) apps.
|
| Additionally, the authorization code flow (with PKCE) in
| Keycloak still supports pure client side authorization.
| Its more complex than the implicit flow, but it doesn't
| really matter as any library (including keycloak-js) will
| take care to ensure its done correctly.
| Perseids wrote:
| 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
| imglorp wrote:
| We're still on the older one and looking forward to the Quarkus
| improvement specifically for boot times. Even with an empty DB,
| the old one takes several minutes to load and come up. It's the
| long pole in our install.
|
| Very happy with KC otherwise. We make heavy use of its nice API
| to create providers and clients at install time.
| erwincoumans wrote:
| Thanks for the thumbs up!
|
| >> 562MB
|
| Curious, why is the Quay image/container so large? Is there a
| way to list the contents without downloading it?
| yrro wrote:
| The base image (registry.access.redhat.com/ubi8-minimal) is
| about 100 MiB. ID
| CREATED CREATED BY
| SIZE COMMENT a6bd0f949af01b5680767225c3ac2b428
| d9b6921a6a9a420f6189f2523931c4c 18 hours ago ENTRYPOINT
| ["/opt/keycloak/bin/kc.sh"]
| 0 B buildkit.dockerfile.v0 <missing>
| 18 hours ago EXPOSE map[8443/tcp:{}]
| 0 B buildkit.dockerfile.v0 <missing>
| 18 hours ago EXPOSE map[8080/tcp:{}]
| 0 B buildkit.dockerfile.v0 <missing>
| 18 hours ago USER 1000
| 0 B buildkit.dockerfile.v0 <missing>
| 18 hours ago RUN /bin/sh -c microdnf update -y &&
| microdnf install -y java-11-openjdk-headless && microdnf
| clean all && rm -rf /var/cache/yum/* && echo
| "keycloak:x:0:root" >> /etc/group && echo
| "keycloak:x:1000:0:keycloak user:/opt/keycloak:/sbin/nologin"
| >> /etc/passwd # buildkit 272 MB buildkit.dockerfile.v0
| <missing>
| 18 hours ago COPY /opt/keycloak /opt/keycloak # buildkit
| 192 MB buildkit.dockerfile.v0 1ecf95eda522cf8db8
| 4ac321e43a353deea042480ed4e97e02c5290eb53390c3 5 days ago
| 20.5 kB <missing>
| 5 days ago
| 107 MB Imported from -
| Turbots wrote:
| base698 wrote:
| Recently been using it and have been happy with it. Being able to
| plug some of our existing providers in and have one solution to
| integrate with has been the big win.
| vosper wrote:
| 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 PassportJS or something, but I'd
| like all the nice Okta stuff (MFA, password policies, SAML SSO,
| maybe federation) but integrated with my existing DB. Or is that
| just too much to ask?
| mooreds wrote:
| 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 store arbitrary data (a
| blob, basically) about a user.
|
| * 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.
|
| If you want to have all PII in one place, the former option is
| best. If you want to maximize your flexibility, the latter is
| what I'd suggest.
|
| If you want to keep the user data in your database, I'd look at
| a library (as you suggest). It's a different class of solution
| than a standalone auth provider like Keycloak.
| vosper wrote:
| > 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!
| mooreds wrote:
| 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.
| maxbaines wrote:
| Using Keycloak for all authentication both in the cloud under
| Linux and within Windows Enterprise Environments. Use it for SSO
| for Node-RED, Grafana, Aspnet & VueJS apps. Was fairly easy to
| move from Auth0.
| rad_gruchalski wrote:
| Went through so many of these systems and keep coming back to
| keycloak exactly because of its monolithic architecture and
| authorisation services.
|
| There are so many great things in keycloak, I very much like SPIs
| and authorisation services (uma2).
| jcon321 wrote:
| have a keycloak dev server been running for 6 years with
| literally 0 maintenance... it's a well crafted piece of software
| pax wrote:
| Slightly off-topic: Could anybody recommend a lightweight, self-
| hosted php IAM that would handle new accounts (with email
| confirmation), password recovery, maybe user groups? I've been
| using Wordpress a couple of times just for the user management,
| not very proud of that but I didn't know better :/
| mekster wrote:
| SSO is not a blogging system. You don't choose by the language.
| pax wrote:
| I'm not looking for SSO. Did I use IAM wrongly? I'm talking
| about tiny apps that do require a protected back-end access,
| generally for somewhat bootstrapped CSOs. Not looking for
| anything fancy, but rather quick and dirty. For example,
| updating a SQLite db via gSheets API. PHP as that's default
| for shared hosting.
| mooreds wrote:
| Geez, I don't know of any. If you have to stick with PHP (as
| opposed to using some of the other solutions mentioned in
| comments), I'd probably look to a framework. For example,
| here's Laravel's offering:
| https://laravel.com/docs/9.x/authentication#authentication-q...
| EtienneK wrote:
| Keycloak is great! Just wish it didn't need so much RAM (2GB at
| least).
| advaitruia wrote:
| Other open source auth solutions: Ory, SuperTokens.com , Supabase
| / GoTrue
|
| If anyone has evaluated these / Keycloak, I'd be happy to have a
| discussion on it
| mekster wrote:
| What are your experiences?
|
| There are also Authentik, Authelia, Dex and gluu.
|
| There was a bad review of gluu in Reddit.
|
| https://www.reddit.com/r/selfhosted/comments/fxotbi/experien...
| adlerhurst wrote:
| i'm biased but another solution is zitadel. Would be happy to
| discuss :)
| sirmike_ wrote:
| Have 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 related whilst supporting a newer modern Auth
| schemes.
|
| I am surprised IBM has not made RHEL ruin it yet.
|
| To say IBM is a slightly better steward of their open source
| efforts than Oracle never leaves one with much comfort.
| 0xbadcafebee wrote:
| RedHat never needed anyone's help to ruin things. Their
| solutions are poorly designed bloated crap that "can get the
| job done" if you run them within a RedHat platform and don't
| mind banging your head against a brick wall. Just because
| they're open source darlings doesn't mean we can't call a spade
| a spade.
| sascha_sl wrote:
| 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.
| password4321 wrote:
| Is Keycloak something that is intended to be exposed publicly, or
| is this something typically used behind a VPN or equivalent
| protection?
| mooreds wrote:
| It depends on what your needs are. If you are using it for CIAM
| (customer identity and access management) then you are probably
| going to be putting it on the internet. If using it for
| internal IAM (identity and access management, also known as
| workforce identity) you can keep it inside your network.
|
| I believe Keycloak works either way.
| password4321 wrote:
| Thanks. I was mostly wondering how comfortable "Hacker News"
| is exposing it publicly... going on zero experience and just
| gut feeling I put it at about the same level as RDP.
| mooreds wrote:
| Ah, I get what you are asking. I think it's far more secure
| than RDP because the protocols it's based on have learned
| lessons from RDP.
|
| Here's a document they have about securing Keycloak: https:
| //www.keycloak.org/docs/latest/server_admin/#mitigatin...
|
| I too would be interested to hear from any folks running
| this software in prod how they deal with securing a public
| endpoint.
| navbaker wrote:
| Transitioning a preexisting web stack in our corporate network
| from Identity Server to Keycloak has been my extremely rough
| intro to the world of auth. I would say I'm _almost_ there, but
| have one issue holding me up. We have a few different data
| enclaves, including one that requires users to sign an NDA and be
| added to an AD group. I've been searching high and low to see if
| Keycloak has a simple flag to say "don't let anyone in that isn't
| a member of this AD group". Does that exist or do I have to
| create groups in Keycloak itself and add users manually?
| cpitman wrote:
| Sounds like you want to configure a Group Mapper:
| https://www.keycloak.org/docs/latest/server_admin/#_ldap_map...
| mekster wrote:
| I've integrated keycloak for SSO between several self hosted apps
| and boy I had no idea what I was doing but copy paste config from
| left and right from various sites which worked in the end but
| does SSO have to be this complicated?
|
| Can someone recommend a simpler solution to integrate SSO with
| online tools (like NextCloud, Discourse, Wiki.js, Gitea etc)?
|
| Does anyone have experience with Authentik?
| zmxz wrote:
| I've used many solutions, even built my own in the end. Problem
| is that there's no software that can make SSO easy to
| understand if you don't know everything about SSO to begin
| with.
|
| SSO is not that complicated to work with, the docs are just
| stupidly difficult to read and the point of the whole process
| is rarely explained. Learning how without knowing why is nearly
| impossible.
| mooreds wrote:
| > even built my own in the end.
|
| Can you tell me more about this?
|
| Did you end up building your own from the ground up, or
| leveraging existing libraries?
|
| Is it open source/available for others to use?
| doctor_eval wrote:
| 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 (at the time).
|
| This meant we needed to know not only about Keycloak itself, but
| also about Wildfly's special quirks, the clustering system
| (Infinispan??), Java and Docker.
|
| Now it's packaged with Quarkus, which is another dependency to
| learn about, and to be honest despite the quality of the finished
| product, all those dependencies have become pretty off-putting.
|
| So while I can recommend Keycloak's functionality, if you're not
| already deploying Java apps as part of your job, I suspect it
| will present a pretty serious administrative burden to deploy
| into serious production.
| ffo wrote:
| 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
| jordemort wrote:
| I was interested in Zitadel, but because it requires
| Kubernetes, it can't replace Keycloak in my docker-compose
| managed homelab setup. If you could just run it as a
| standalone container, I'd give it a shot.
| stebenz wrote:
| Sounds like you would be interested in v2
| (https://zitadel.ch/v2) as in it will be provided as single
| binary, which you should be able to use in our homelab
| setup.
|
| There are a lot of other improvements, but if that's the
| only dealbreaker, v2 should take care of it.
| js4ever wrote:
| Wow I was not expecting that! Usually offering only a
| Kubernetes version is the new way to force small users to
| the SaaS version.
| ffo wrote:
| 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 ;-)
| jordemort wrote:
| Yep, that's the only dealbreaker for me - I'll keep an
| eye out for v2!
| ffo wrote:
| Love it, we will definitely create a post here in the
| next 2-4 weeks.
| getcrunk wrote:
| Your v2 pricing model is lame. I was literally pulling
| out my credit card when I saw the original pricing.
| doctor_eval wrote:
| Apache 2.0 and golang. Thank you! That's exactly what I
| was looking for. I'll check out v2 asap.
| ffo wrote:
| Thank you, v2 will be ready in the next 2-4 weeks. We are
| already running it internally ;-)
| sebmellen wrote:
| 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?
| ffo wrote:
| 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
| sebmellen wrote:
| Make sense, thank you for the answer! I do think the
| turnkey solution middleground is badly needed and I'm
| excited to see where ZITADEL goes. We've already
| committed heavily to Ory on this project, but maybe on
| the next one we'll be able to explore ZITADEL!
| ffo wrote:
| Thank you too. Feel free to join our chat and ask
| questions any time https://zitadel.ch/chat (discord)
| collegeburner wrote:
| 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?
| joekrill wrote:
| That's really surprising to me. I've been building some
| things with Ory Kratos myself and I find the documentation
| pretty good. There's definitely room for improvement but
| I'm typically able to find what I need pretty easily. I
| certainly find it much more usable than the Keycloak docs.
| voidcommonstock wrote:
| Another OAuth2 server, that's well on the other side of the
| heavyweight spectrum vs. keycloak:
|
| https://github.com/curveball/a12n-server
| jbaczuk wrote:
| I knew I could smell Java when I went to their website...
| marcosdumay wrote:
| Languages (actually, ecosystems) do have specific smells. You
| can perceive them on every artifact. It's an interesting
| observation.
| mooreds wrote:
| 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 (Redhat SSO is the commercial
| offering for Keycloak, FusionAuth has paid editions with
| support). FusionAuth is much less expensive (compare
| https://marketplace.redhat.com/en-us/products/red-hat-single...
| with https://fusionauth.io/pricing .)
|
| * Both offer the ability to self-host.
|
| * Both develop in the open (we use GitHub issues, they use a
| mailing list).
|
| Differences:
|
| * They're OSS, we are free as in beer.
|
| * I haven't found a compelling hosting solution for Keycloak,
| most folks self host. FusionAuth offers a hosted product if
| you'd like.
|
| * Keycloak has more niche features (CAS SSO support) and a
| bigger community.
|
| * FusionAuth has better, more straightforward docs.
|
| * FusionAuth user UI customization is easier.
|
| * FusionAuth supports a number of languages with client
| libraries for easier config management. I only saw a python
| client library for Keycloak.
|
| * FusionAuth supports unlimited tenants, limited only by your
| server's resources. We have folks running thousands of tenants.
| Last time I looked Keycloak had issues around 400 realms (their
| term for tenants): https://keycloak.discourse.group/t/maximum-
| limit-of-realms/8...
|
| Disclosure: I work for FusionAuth.
| abraae wrote:
| 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.
| oauea wrote:
| > Disclosure: I work for FusionAuth.
|
| Don't worry, that was obvious.
| mooreds wrote:
| Ha ha, fair enough. I've found it better to err on the side
| of transparency.
| freedomben wrote:
| I would offer two suggestions that might improve
| reception:
|
| 1. Put that disclaimer _at the top_
|
| 2. Shrink it to no more than a couple sentences and link
| to a blog post or something for the detailed comparison.
| It looks pre-canned and kind of spammy the way it is now
| mooreds wrote:
| Thanks, I appreciate that feedback. I agree that I was
| over enthusiastic. Unfortunately I can't edit the post
| now, but will do better next time.
| maxbaines wrote:
| For me this is all kind of opaque, apart from a theme put into
| a folder and some Environment Variables set i don't touch
| anything in Keycloak, first had no requirement to consider it
| and second very likely would be doing something maybe not best
| practice i.e oidc, oauth based.
|
| Its the only java app we run in stack, but doesn't matter to me
| in Docker and within Windows we run a portable java from a
| subfolder of keycloak so not System wide in Path
| advaitruia wrote:
| > 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)
| littlecranky67 wrote:
| Was working at a Java shop once which used Keycloak as a
| central IAM solution. As an FE Dev, I was tasked to
| customize/style the login-page provided by Keycloak, and
| quickly faced what you described: Pretty heavily Java-based,
| even to edit HTML templates I had to recompile using a full
| blown Java/JVM stack.
|
| As an FE dev without Java background, this became pretty
| difficult. But once we finished that with the help of some of
| the BE Java devs, it ran (and still runs) quite stable and also
| the KeycloakJS adapter I integrated was alright without much
| surprises.
| spacemanmatt wrote:
| Java backend/React frontend dev here.
|
| I customized Keycloak 10 login page a while back, and it did
| not require anything but markup. My Keycloak 18 instance runs
| the same customization now, unchanged.
| psnehanshu wrote:
| Why customize the FE when you can use the keycloak-js[1] NPM
| library to integrate with any JS framework?
|
| [1] https://www.npmjs.com/package/keycloak-js
| littlecranky67 wrote:
| Because that is not how you customize the _login /signup_
| page that lives inside Keycloak (and its Docker image, if
| you use docker).
| oauea wrote:
| > even to edit HTML templates I had to recompile using a full
| blown Java/JVM stack
|
| Next time check the docs and turn off the theme cache: https:
| //www.keycloak.org/docs/latest/server_development/#cre...
|
| > While creating a theme it's a good idea to disable caching
| as this makes it possible to edit theme resources directly
| from the themes directory without restarting Keycloak.
| la6472 wrote:
| First of all it is not clear if it is stand alone OR SAAS
| product?
| mooreds wrote:
| It is typically self-hosted.
|
| A quick google turned up this Keycloak SaaS offering:
| https://www.cloud-iam.com/
| sascha_sl wrote:
| 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.
| amaccuish wrote:
| I like Keyloack, but omg it's ridiculously difficult when using
| the docker container to import a CA cert. May Java Keystore burn
| in hell.
| oauea wrote:
| I think keycloak is fantastic. The only thing I don't really like
| is how the user profile is deeply baked into the code. It seems
| they're working on improving this, but at least currently, it is
| not possible to have users that do not use a "First name" and a
| "Last name". Which is rather annoying when using it for things
| like game servers, where people just want to go by their
| username.
| spacemanmatt wrote:
| I've been running Keycloak for 4 years now, starting with version
| 10.
|
| I like a well-disciplined stack and Keycloak is a star. And
| that's huge considering my other big players are Vert.x and
| PostgreSQL.
| seymon wrote:
| I which all the keycloak login and email themes would be more
| flexible and could use custom client attributes, realm settings
| etc.
|
| Another missing thing is multi tenancy within a realm. Because
| managing a huge number of realms is a configuration nightmare.
| deependra wrote:
| https://wso2.com/asgardeo/
| burn_321 wrote:
| jcroll wrote:
| Spring has an oauth2 authorization server that is currently in
| early release: https://github.com/spring-projects/spring-
| authorization-serv...
|
| I'm building something with it currently and it's quite nice,
| especially if you are already familiar with spring security.
| Documentation is quite sparse tho.
| bfm wrote:
| Relevant discussion comparing KeyCloak to the Ory stack
| https://news.ycombinator.com/item?id=25763320
| xupybd wrote:
| I've been investigating an authorization application to use with
| the SAFE stack. I'm testing Keycloak and it looks good so far.
| pharmakom wrote:
| Similar scenario here. Drop me a comment if you want to share
| anything learned.
| dbrgn wrote:
| Does someone here know how Keycloak compares to Gluu?
| mooreds wrote:
| From what I've heard, Keycloak is better supported and has a
| bigger community that Gluu (12k stars vs 300 stars on GH). They
| are both open source and in Java. I've heard from users that
| Gluu can be a resource hog.
| offminded wrote:
| I had to decide between Keycloak and Supertokens just last week..
| Gone through both of their documentation and repos and decided to
| go with Supertokens. Backend and Frontend flexibility and their
| instant Discord support to my questions was a huge plus for me.
| n3t wrote:
| Can I use Keycloak for the following use case?
|
| I have a few services on my family server (say, Gitea, Grafana,
| finance tracking app etc.). I'd like to have a SSO but also limit
| which users can use which services (e.g. my significant other can
| use Grafana but no Gitea).
|
| Is integrating above services with Keycloak enough? Or would I
| need another components? Or maybe I've got it wrong and should
| reconsider the architecture?
| mooreds wrote:
| This is a very common auth situation (wanting to have a central
| place to control access to multiple applications).
|
| The biggest hurdle I see is do all of your apps support SAML or
| OAuth/OIDC for authentication/authorization? The SSO tax is a
| real thing.
| p_l wrote:
| It will definitely work - Keycloak can provide its own user
| database, or it can use external one, as well as do some
| crazier things that go outside of the scope you mentioned.
|
| In simplest setup (non-HA, local user database), you would
| create users inside Keycloak, assign them to different groups,
| then create applications (which handle configuration for
| individual applications like grafana and gitea) and create
| rules that specify that only users that belong to specific
| group can login to specific application.
|
| You can also allow linking multiple external SSOs this way to
| single keycloak identity, and even include login through
| kerberos5 or client certificates.
| fjni wrote:
| This will work. But learning curve is steep as others have
| said.
| spicyusername wrote:
| For those that may not be aware, Keycloak is the upstream of Red
| Hat's SSO solution "Red Hat Single Sign-On", so there is a lot of
| weight behind it's development.
| deependra wrote:
| Another Opensource IAM provider is WSO2.
|
| Now they offer a cloud solution too.
|
| https://wso2.com/asgardeo/
| topspin wrote:
| I've used both the opensource WSO2 and Keycloak. That latter is
| better designed and suffers fewer glitches, which is important
| when dealing with the complexities of oidc/oauth2. It's not
| that WSO2 doesn't do what it says on the tin; it works.
| Keycloak just works so well it's almost fun.
|
| One feature Keycloak lacks compared to WSO2 is SCIM (System for
| Cross-domain Identity Management). That actually matters to me.
| There is a third party Keycloak extension[1] that implements
| SCIM, but I can't speak to it.
|
| [1] https://github.com/Captain-P-Goldfish/scim-for-keycloak
| contactgalaxy wrote:
| [deleted]
| burn_321 wrote:
| d4a wrote:
| I have been using Keycloak for the past couple of years in my
| homelab for SSO. It works really well, but there's a bit of a
| learning curve.
| mooreds wrote:
| What would you say have been the positives and negatives of it?
| Is the learning curve above and beyond OIDC/OAuth? How much did
| you have to customize it?
| sascha_sl wrote:
| Keycloak just assumes you know OIDC terminology, and it has
| some quirks that you might not expect (e.g. until recently,
| client credential grants created a refresh token).
|
| It also, concerningly, uses some OIDC terminology outside of
| OIDC. There are two kinds of scopes in Keycloak. OIDC scopes
| (that are a set of mappers and represent permissions) and
| which client and realm roles can be included in a token
| (including the famous "Full Scope allowed" option that'll
| dump all roles into your token if you use the default OIDC
| scope).
|
| A lot of behavior is also just implicit. Particularly in the
| Authentication Flow Editor. You just gotta know what you want
| if you want to customize them. The Audience mapper is another
| tricky one, relying on the (not OIDC) scope to figure out
| which client to put into the "aud" claim.
| Loic wrote:
| Slightly 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
| MrTawti wrote:
| I used Keycloak about 4 or 5 years ago in a former job. It did
| work very well. Note however, that we did not need to customize
| anything nor did we have to deal with scaling (in house web-app
| where it was rare to have more than 100 people using on it at any
| given day).
|
| Right now, I'm looking into https://supertokens.com/ I have not
| used it in any capacity but it does seem much more approachable
| -at least to me- and allows for much flexibility (code wise on
| your own Backend).
|
| I would be interested in hearing if anyone here has any feedback.
| miovoid wrote:
| It's Java based :--(
| nickserv wrote:
| I'm not a big fan of Java personally, as in I would not start a
| side project with it.
|
| But in this case it's actually a great choice. Static typing,
| stable, mature, good performance, known by tons of engineers
| all over the world... And heavily used in the enterprise market
| which has a very real need for SSO.
| fjni wrote:
| My biggest issue in the version I was evaluating: Some service
| providers use "email" as username (in fact many do.) Keycloak
| doesn't make it easy to prohibit users from changing their own
| email, making it trivial to impersonate someone else and gain
| access one shouldn't have.
|
| https://keycloak.discourse.group/t/hide-disable-email-change...
| mooreds wrote:
| Did they offer some kind of verification path?
|
| So you could only allow an email change if the user proved they
| owned the new email account by clicking a link or entering a
| code sent to that account?
|
| Seems like a natural option.
|
| Of course, allowing you to disallow email changes seems pretty
| reasonable too.
| fjni wrote:
| The issue if I remember correctly was that you could require
| the email to be verified. But while that verification was
| pending, it would already use the new email as the user's
| asserted attribute.
| sascha_sl wrote:
| Keycloak actually makes it very easy now, assuming you have
| account-api and account2 feature flags set (default these
| days). You remove "manage-account" inside the "account" client
| from the default roles. Do mind this breaks the account console
| for those users (which is what you probably want anyway).
| fjni wrote:
| I don't remember exactly, but I think this also took away the
| ability for users to manage their factors (I.e. register a
| new hardware token)
| pharmakom wrote:
| My biggest complaint with Keycloak is that the documentation is
| poor. You _will_ need to set various flags to fit your use-case.
| Lots of googling and SO to get things running. Some of the
| options have changed since 17.x so many guides are outdated.
| sascha_sl wrote:
| This was definitely true for the Wildfly/JBoss version, but on
| Quarkus configuring Keycloak is mostly trivial now[1]. The only
| options I had to set outside environment variables in
| production are related to Infinispan discovery.
|
| [1]: https://www.keycloak.org/server/all-config
| miovoid wrote:
| It's Java based :-(
| whazor wrote:
| Authentik is also worth checking out: https://goauthentik.io/
|
| The biggest benefit is that Authentik supports Forward Auth out
| of box. This means that you might not need oauth2proxy.
| gabereiser wrote:
| I've been a keycloak advocate since my jboss days (really the
| only good thing that came out of jboss). I have never heard of
| authentik and I'm so glad you mentioned it, it looks amazing! I
| had been contemplating doing a similar project but this would
| satisfy that need. Thank you.
| dugite-code wrote:
| Just be careful with Athentik, it is an extremely young,
| rapidly developing project. So expect the odd pitfall
| gabereiser wrote:
| Yeah, needs battle hardening, but I like what they are
| doing and the features it offers so bookmarked and starred!
| deadbunny wrote:
| Getting cert errors for me when visiting that link. Using a
| self signed cert by the looks of it?
|
| Edit: Ok now. Looks like they use Let's Encrypt which will
| default to a self signed cert if it can't get a LE one for
| whatever reason IIRC.
| p_l wrote:
| Arguably best is to not have proxied oauth at all and instead
| implement oauth in your software.
| CGamesPlay wrote:
| This looks awesome! I dropped Keycloak because it's 2 GiB of
| RAM was too much for me to commit to SSO on my tiny VPS, so I
| just switched to static htpasswd management. But this looks
| like it might be a great replacement.
|
| It seems to support groups/selective access to services through
| group membership, which is great. Does it support username
| authentication or does it require that an LDAP server or other
| OIDP is used as a source of truth?
| kirbyfan64sos wrote:
| Do note that Authentik, being a Python project, still uses a
| decent amount of RAM IMO.
|
| I _think_ Keycloak 18 should use less memory? Might be worth
| a try.
| eclipsenet wrote:
| Looks like it got the internet hug-o-death or something b/c it
| looks like it's down.
| hamandcheese wrote:
| I was interested in Authentik, but I was perusing the docs and
| was extremely put off by the way in which Authentik manages
| itself as well as additional "outposts".
|
| > The docker integration will automatically deploy and manage
| outpost containers using the Docker HTTP API.
|
| > This integration has the advantage over manual deployments of
| automatic updates (whenever authentik is updated, it updates
| the outposts)
|
| NO. I do not want software I use to update itself automatically
| in prod. And I especially do not want to give a docker socket
| to it so that it can automatically add new components.
|
| https://goauthentik.io/docs/outposts/integrations/docker
___________________________________________________________________
(page generated 2022-05-04 23:01 UTC)