An analysis of the Keycloak authentication system(security.humanativaspa.it)
security.humanativaspa.it
An analysis of the Keycloak authentication system
https://security.humanativaspa.it/an-analysis-of-the-keycloak-authentication-system/
97 comments
Regardless of whether it's a project run by a big company or a guy in a shed, a security-critical project not fixing critical vulns for 10 months is an important bit of information when judging whether you should use it.
It doesn't really matter whether it's someone's fault, or wrong, or whatever - what matters for the user is that using the project is likely unsafe. Sharing that information is a public service.
It doesn't really matter whether it's someone's fault, or wrong, or whatever - what matters for the user is that using the project is likely unsafe. Sharing that information is a public service.
>a guy in a shed
That should be enough without needing to shame them over timeline.
You can also judge based off issue open/close rate and contribution frequency (GitHub has pretty charts for these if the project is hosted there)
That should be enough without needing to shame them over timeline.
You can also judge based off issue open/close rate and contribution frequency (GitHub has pretty charts for these if the project is hosted there)
The number of software engineers who either don’t understand social contracts or only understand them when it benefits them to do so is frankly appalling.
You said you’re going to do something and now people depend on you having done it. Volunteer organizations fall apart if they can’t trust each other.
You said you’re going to do something and now people depend on you having done it. Volunteer organizations fall apart if they can’t trust each other.
People depending on you is not somethng in your control, therefore you can't be responsible for that. It's up to the people depending on you to make a judgement on whether or not that's a good idea.
Social contracts are not contracts, they do not end up in court, and if you depend on them you have no recourse. The most anyone can say about social contracts is that you are allowed to be disappointed privately. And even then...
Social contracts are not contracts, they do not end up in court, and if you depend on them you have no recourse. The most anyone can say about social contracts is that you are allowed to be disappointed privately. And even then...
No, they end up in the court of public opinion. <gestures around>
And they make you lonely if you keep losing.
And they make you lonely if you keep losing.
This blog post is from another domain, writing, but it’s stuck with me over the years and colored how I see things like open source projects:
https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
> maybe a PR would have been nice?
They did.
> 28/03/2024 – First communication sent with all details and a proposed fix.
And for the second one, a fix existed 2 days after first communication, doing a PR doesn't magically make that go faster.
For the third, a fix was done within a month, but once again was delayed, and didn't land until several months later.
- - -
RH does not provide support contracts for any affordable price. CNCF does not provide support contracts at all.
They did.
> 28/03/2024 – First communication sent with all details and a proposed fix.
And for the second one, a fix existed 2 days after first communication, doing a PR doesn't magically make that go faster.
For the third, a fix was done within a month, but once again was delayed, and didn't land until several months later.
- - -
RH does not provide support contracts for any affordable price. CNCF does not provide support contracts at all.
That was a very articulate and nice way of saying, “what if instead of using the tired old deflection you looked at the facts?”
Keycloak is a Red Hat product and is a dependency for many Red Hat products so I'd love it if people running the open source release can report the bug and get feedback. This isn't a student eating ramen supporting this software, its IBM.
Keycloak has been donated to CNCF in 2023. So it's not a RH / IBM product anymore.
I would even go as far as say that it never was; Red Hat had their own product called "Red Hat Single Sign On" that was, for some time, based on opensource Keycloak project, but the opensource Keycloak project has existed before RH SSO. And exists now that RH SSO product has been deprecated (retired? Idk what happened).
Red Hat does offer a "Red Hat build of Keycloak" now, and of course Keycloak would not exists in it's current form without Red Hat.
But saying that "Keycloak is a Red Hat product and therefore Red Hat and / or IBM should support it" would be, in my opinion, harmful for the whole opensource movement. If, by being engaged with opensource project, a company risks it's reputation then such company could decide against any engagement, or would engage only if it could keep control of the project / community around it.
I would even go as far as say that it never was; Red Hat had their own product called "Red Hat Single Sign On" that was, for some time, based on opensource Keycloak project, but the opensource Keycloak project has existed before RH SSO. And exists now that RH SSO product has been deprecated (retired? Idk what happened).
Red Hat does offer a "Red Hat build of Keycloak" now, and of course Keycloak would not exists in it's current form without Red Hat.
But saying that "Keycloak is a Red Hat product and therefore Red Hat and / or IBM should support it" would be, in my opinion, harmful for the whole opensource movement. If, by being engaged with opensource project, a company risks it's reputation then such company could decide against any engagement, or would engage only if it could keep control of the project / community around it.
RH SSO was the LTS build of keycloak with business support.
Keycloak doesn't publish hot fixes for previous major versions, and these major versions come out on a very tight release schedule / every few months. So if you didn't want to upgrade all the time, you'd have been forced to use rhsso. And now the red hat keycloak build.
https://github.com/keycloak/keycloak/discussions/25688
Keycloak doesn't publish hot fixes for previous major versions, and these major versions come out on a very tight release schedule / every few months. So if you didn't want to upgrade all the time, you'd have been forced to use rhsso. And now the red hat keycloak build.
https://github.com/keycloak/keycloak/discussions/25688
> So if you didn't want to upgrade all the time, you'd have been forced to use rhsso.
Or just not upgrade at all. Not the most wise strategy for security-focused software, but I'm sure many teams do that. Especially because keycloak often being heavily customized with plugins and themes, so upgrading this setup might actually be not trivial.
Or just not upgrade at all. Not the most wise strategy for security-focused software, but I'm sure many teams do that. Especially because keycloak often being heavily customized with plugins and themes, so upgrading this setup might actually be not trivial.
If there's a Red Hat build of Keycloak, and Red Hat products depend on Keycloak, then this vulnerability is present in all of those Red Hat products.
Not necessarily. Red Hat issues patches and backports to customers regularly and those don’t necessarily flow upstream right away (or sometimes ever).
Off-topic but I love this naming convention from Red Hat which I hope gets more traction across the industry. It absolutely detest wading through vendor marketing material to figure out which open source product is being used under the hood. With names like "Red Hat Build of Keycloak" and "Microsoft Build of OpenJDK" it's crystal clear.
I believe it works out better for the vendors as well because there are so many obstacles with evaluating anything that requires a license in an enterprise setting. If the technical person downloads and evaluates the underlying open source version some manager will insist on purchasing a support contract before going to production.
I believe it works out better for the vendors as well because there are so many obstacles with evaluating anything that requires a license in an enterprise setting. If the technical person downloads and evaluates the underlying open source version some manager will insist on purchasing a support contract before going to production.
Though Red Hat did a search and replace for RHSSO with "Red Hat Build of Keycloak" in their docs, and now they are extremely painful to read with Red Hat Build of Keycloak sometimes appearing three times in one sentence when "Keycloak" or some other shortened form would suffice.
Money doesn't guarantee anything, as seen by the recent issue with Okta. If you're using a centralized auth service and expecting no vulns or exploits, you're going to be severely disappointed. These are the juiciest targets and very complex pieces of software.
I don't see an issue with calling out this Keycloak response time either. It's not inherently negative, just stating facts.
I don't see an issue with calling out this Keycloak response time either. It's not inherently negative, just stating facts.
If you central auth - you have vulnerabilities
If you decentralize auth - you have vulnerabilities. It can lead to shadow credentials as well as credential and auth sprawl.
It is about de-risking your approach. Either approaches work until they don't.
It is about de-risking your approach. Either approaches work until they don't.
Keycloak is not written by some random person in the middle of nowhere who is shouldering the burdens of the world. It is security sensitive software that in part is funded by major open-source corporations like Red Hat, including full time engineers. What you're reading in this blog is literally standard fare in security research where a disclosure happens after some set period of time, regardless of when, or even if, the fix happened.
Fixing authentication bypasses is not "very high expectations", it's exactly what you would expect from this software. Get a grip on reality, please.
Fixing authentication bypasses is not "very high expectations", it's exactly what you would expect from this software. Get a grip on reality, please.
Is it still funded by Red Hat today?
Several developers and full-time employees, including the project lead, are still employed by Red Hat.
> What if instead of publicly blaming an OSS product, you try to get a support contract with some of the engineers behind it? If your company is too cheap for that, maybe a PR would have been nice?
Yeah, no. That's not how security research works.
If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed.
From the timeline:
> 28/03/2024 – First communication sent with all details and a proposed fix.
After that point, any additional help (including a pull request) is going above and beyond.
I run into this attitude you're exhibiting a lot. Where proprietary software has the legal threats, the open source community is plagued by patch entitlement.
Knowledge of a security issue in a project is, in and of itself, a valuable contribution. Expecting a PR devalues this work.
Yeah, no. That's not how security research works.
If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed.
From the timeline:
> 28/03/2024 – First communication sent with all details and a proposed fix.
After that point, any additional help (including a pull request) is going above and beyond.
I run into this attitude you're exhibiting a lot. Where proprietary software has the legal threats, the open source community is plagued by patch entitlement.
Knowledge of a security issue in a project is, in and of itself, a valuable contribution. Expecting a PR devalues this work.
> If I disclose a security issue to you, it doesn't matter if you're a multinational trillion dollar corporation or a hobbyist in Nebraska, the onus is on you to fix it. Not the security researcher. Their job is done once it's disclosed.
On the other hand, if I'm a hobbyist, I have 0 obligations to do or fix anything I've made open source. Patches are welcome ofcourse.
On the other hand, if I'm a hobbyist, I have 0 obligations to do or fix anything I've made open source. Patches are welcome ofcourse.
As long as you disclose that right-front on your value statement, yeah, you don't have any other obligation.
Is there an open source license that doesn't?
It is right in the license.
That's not what these licenses have come to mean. They're a way to reduce the risk that you'll get sued,
but not any "I don't give a fuck" statement.
You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme, if you're developing security related OSS software? That'd be more clear.
Maybe the WTFPL actually a little bit indicates that the developers maybe don't give a fuck, though: https://en.wikipedia.org/wiki/WTFPL ?
but not any "I don't give a fuck" statement.
You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme, if you're developing security related OSS software? That'd be more clear.
Maybe the WTFPL actually a little bit indicates that the developers maybe don't give a fuck, though: https://en.wikipedia.org/wiki/WTFPL ?
That sounds a little like having your cake and eating it too. 'Giving a fuck' is not really a boolean value but more of a broad spectrum.
Of course, anyone who writes any software cared a little bit about it at one point, or they wouldn't have written it. But warranty is about whether they care enough to cater specifically to you when you have a problem in the future.
Maybe many of these projects do care enough to give general updates to the community as a whole on a best effort basis, but that's a lower level of assurance and more voluntary than what you'd get in a legal warranty.
Of course, anyone who writes any software cared a little bit about it at one point, or they wouldn't have written it. But warranty is about whether they care enough to cater specifically to you when you have a problem in the future.
Maybe many of these projects do care enough to give general updates to the community as a whole on a best effort basis, but that's a lower level of assurance and more voluntary than what you'd get in a legal warranty.
>You could add "I don't care about fixing security vulnerabilities" somewhere in the beginning of the readme
I care about fixing security vulnerabilities in my OS projects, but I care more about my sanity, my family, getting enough money to survive, and a few other things. Unless you pay me I don't care about your problems with my free (as in a beer) software.
And that's a good thing btw - I tried to ask for donations once, got the equivalent of a few cups of coffee per month, and... burned out almost immediately. I started to feel responsible for that project, staying up late to fix reported minor bugs, and it turns out watching Github issues 365 days a year for a few dollars monthly is not a great business strategy.
I care about fixing security vulnerabilities in my OS projects, but I care more about my sanity, my family, getting enough money to survive, and a few other things. Unless you pay me I don't care about your problems with my free (as in a beer) software.
And that's a good thing btw - I tried to ask for donations once, got the equivalent of a few cups of coffee per month, and... burned out almost immediately. I started to feel responsible for that project, staying up late to fix reported minor bugs, and it turns out watching Github issues 365 days a year for a few dollars monthly is not a great business strategy.
This is not a one-person project ran by someone in their spare time, posted online for fun.
They are going out of their way to advertise so that people use their security-critical software in security-critical applications, and then they neglect the security.
While they aren't under any legal obligation, it's (in my worldview at least) pretty damn unethical.
All they would have to do to not be unethical is make it clear that this software should not be used in any security-critical application because it is not properly/frequently maintained. Put that in a header on the website.
They are going out of their way to advertise so that people use their security-critical software in security-critical applications, and then they neglect the security.
While they aren't under any legal obligation, it's (in my worldview at least) pretty damn unethical.
All they would have to do to not be unethical is make it clear that this software should not be used in any security-critical application because it is not properly/frequently maintained. Put that in a header on the website.
The license is not your value statement.
Nobody has an obligation to even do that outside of a contractual relationship, though it would be polite.
[deleted]
And you also shouldn't expect anyone to use your software. Which of course is up to you.
>I have 0 obligations to do or fix anything I've made open source.
While technically true, this seems pretty scummy when you're advertising security software for real people and companies to use as their identity management.
Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software.
Instead, it seems like they are trying very hard to be taken seriously as an identity management product.
While technically true, this seems pretty scummy when you're advertising security software for real people and companies to use as their identity management.
Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software.
Instead, it seems like they are trying very hard to be taken seriously as an identity management product.
> Nowhere on the Keycloak home page does it say "just a hobby project" or anything that would remotely indicate that it is not a serious project and that you shouldn't use the software.
https://github.com/keycloak/keycloak/blob/main/LICENSE.txt#L...
Indeed
https://github.com/keycloak/keycloak/blob/main/LICENSE.txt#L...
Indeed
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.Point 7 buried in the license document of the github repository is very much not https://www.keycloak.org/
Is this the first time you heard of open source licenses or something? This is standard boilerplate, and it's hilarious to think you get to ask for more from a project you're not even contributing to.
I'm not asking for more. I'm saying I think it is scummy to do the bare minimum when you're advertising yourself as a critical piece of security software and encouraging the use of the software in real security-critical applications.
They are literally explicitly stating that the software does not claim to be fit for purpose.
You can’t have it both ways.
You can’t have it both ways.
They are advertising on their website, extremely prominently, that they are fit for your all of identity management needs.
Are they allowed to put a single paragraph in their license file that runs counter to all of their other marketing, advertising, and communication efforts? For sure!
Is it shitty to do that? I think so. Just be upfront, it's not hard. If your software isn't fit for security-critical applications, don't pretend it is.
Are they allowed to put a single paragraph in their license file that runs counter to all of their other marketing, advertising, and communication efforts? For sure!
Is it shitty to do that? I think so. Just be upfront, it's not hard. If your software isn't fit for security-critical applications, don't pretend it is.
I suppose it's best if you never use any open source software ever again because they all do that. Like I said, it's standard boilerplate and it's absurd to think you get to wish for more from an open source project that you aren't contributing to.
Of course this boilerplate is necessary else you get people like yourself demanding unreasonable things.
Of course this boilerplate is necessary else you get people like yourself demanding unreasonable things.
I'm not demanding anything, please stop reading my comments in the most uncharitable way you possibly can.
I'm not sure what has you in super-defense mode, but just as they are allowed to misrepresent themselves on their website, I'm allowed to think that it's shitty to do so. However, as I've said already (a few times, actually), they are more than free to continue doing so (and I'm more than free to keep saying it's shitty).
>[...] because they all do that.
No, they don't all do that.
I'm not sure what has you in super-defense mode, but just as they are allowed to misrepresent themselves on their website, I'm allowed to think that it's shitty to do so. However, as I've said already (a few times, actually), they are more than free to continue doing so (and I'm more than free to keep saying it's shitty).
>[...] because they all do that.
No, they don't all do that.
Customers have been refunded in full.
Red hat consumers have been refunded? Where?
As per the terms here: https://www.keycloak.org/pricing
The point is that red hat also sells keycloak and develops it. I agree that most users don't pay, but your point is a bit weird considering that some people do actually pay/paid for its development and still do not get a refund
So what gives you a right to download and use the software in the first place? The copyright law forbids that by default. What permission other than the license do you have?
I'm not sure what point you are trying to make but thankfully, given that they obviously can't be trusted to maintain security-critical software (despite what they imply on their website and marketing material), I haven't downloaded or used it or recommended it anywhere while consulting.
You really feel that anything that is not directly on the home page does not matter? A link to a separate document explicitly named as containing the conditions of license, warranty and such should not count?
Seems like an absurd view to me.
For all that I think RedHat is not a poor hobbyist and morally at fault. It's just a different matter altogether. The terms under which the software is provided are clearly spelled and in public view. You're just inventing a reason to disregard them.
Seems like an absurd view to me.
For all that I think RedHat is not a poor hobbyist and morally at fault. It's just a different matter altogether. The terms under which the software is provided are clearly spelled and in public view. You're just inventing a reason to disregard them.
>You really feel that anything that is not directly on the home page does not matter?
No, that's not what I said.
When it comes to software like this (one of the most important components of your security architecture), hiding the fact that you wont fix vulnerabilities unless you feel like it halfway down in your legalese-filled license is unethical.
I think it's absurd that people are defending this position. We're not talking about a weather app made by Joe Somebody for a weekend project.
No, that's not what I said.
When it comes to software like this (one of the most important components of your security architecture), hiding the fact that you wont fix vulnerabilities unless you feel like it halfway down in your legalese-filled license is unethical.
I think it's absurd that people are defending this position. We're not talking about a weather app made by Joe Somebody for a weekend project.
The Linux kernel, probably one of the most critically important pieces of software nowadays, is licenced mainly under the GPL version 2.0[0], and other compatible licenses, and provides a section and 2 paragraphs on how there is no warranty for those who decide to use it.
"""
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
"""
No Linux kernel engineer is obliged to fix any bugs, even security vulnerabilities, if one decides to, but since there's so much at stake, kernel engineers will end up fixing at their own timeframes, as they see fit.
[0] https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
"""
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
"""
No Linux kernel engineer is obliged to fix any bugs, even security vulnerabilities, if one decides to, but since there's so much at stake, kernel engineers will end up fixing at their own timeframes, as they see fit.
[0] https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
My complaint was not about the license, it was about how the product represents itself.
Linux.org is a much different website than keycloak.org in the way they represent themselves, how they communicate the product, etc.
Linux.org is a much different website than keycloak.org in the way they represent themselves, how they communicate the product, etc.
> Point 7 buried in the license document of the github repository is very much not https://www.keycloak.org/
Not a single word in this comment refers to "software like this (one of the most important components of your security architecture)". I guess you realized the absurdity of your position and moved the goalposts to something else.
Not a single word in this comment refers to "software like this (one of the most important components of your security architecture)". I guess you realized the absurdity of your position and moved the goalposts to something else.
What?
Can you explain where you think I set goalposts, and how you think I moved them? Because I am not following.
Can you explain where you think I set goalposts, and how you think I moved them? Because I am not following.
Then you should never work on software with security implications, or if you do you should keep it to yourself. I’m a terrible party host, so I don’t host parties. I help other people do so when I can.
There's no obligation for a hobbyist to fix the stuff they publish online. If they're selling the result, then sure, you can argue there's reasonable consideration, but just because a security researcher has made a contribution (and a valuable one) it doesn't compel any further contribution from the original author. Now, the lack of action does probably remove some of the credibility of the project as one that should be used in any security context (bit of a problem for something intended to be used as authentication).
> There's no obligation for a hobbyist to fix the stuff they publish online.
Correct, but I didn't say there was. The onus being on them to fix it is predicated on anyone having such an obligation at all. If anyone has an obligation, it's always the vendor, not the researcher.
But keep in mind this situation involves an IBM-funded open source project under the Red Hat product line. The hobbyist remark is tangential to the story.
Correct, but I didn't say there was. The onus being on them to fix it is predicated on anyone having such an obligation at all. If anyone has an obligation, it's always the vendor, not the researcher.
But keep in mind this situation involves an IBM-funded open source project under the Red Hat product line. The hobbyist remark is tangential to the story.
> There's no obligation for a hobbyist to fix the stuff they publish online.
I may be wrong but this might not the case anymore in 2025 (not sure about the timeline) in the European Union because of the new cybersecurity acts.
I may be wrong but this might not the case anymore in 2025 (not sure about the timeline) in the European Union because of the new cybersecurity acts.
There's carve-outs in that for open source hobbyists ("not associated with commercial activity"). This was originally vaguely worded but they've now made it a lot less ambiguous, the only open source it covers is that which is being developed by a company which is also making money directly from it.
(And in the case that a company takes that code and uses it in a product, they are responsible to fix any security vulnerabilities but also to report it to the author)
(And in the case that a company takes that code and uses it in a product, they are responsible to fix any security vulnerabilities but also to report it to the author)
I don't have a business presence in the EU, so I rarely care about that for my own projects. (Insofar as I do care, it's limited to "let's not make GDPR compliance logically impossible when designing cryptographic features").
[deleted]
Identity, authn and authn are hard. A failure in the code, logic or at the seams messes up everything that it tries to protect. There are a few big commercial players trying to take the market with their "social login", and a few smaller (open-source) players trying to compete and survive, walking a fine line between open-source and open-core.
I feel this is one avenue where a few open-source players should get some solid funding and support from both the organisations and governments that use their software so we don't end up with unmaintained bug-riddled code and have to login with Google or Facebook everywhere.
A lot of the government agencies I work with use open-source IdP software (because they have to privacy- and policy-wise), so some healthy funding model should be possible for people with the skill and interest.
I feel this is one avenue where a few open-source players should get some solid funding and support from both the organisations and governments that use their software so we don't end up with unmaintained bug-riddled code and have to login with Google or Facebook everywhere.
A lot of the government agencies I work with use open-source IdP software (because they have to privacy- and policy-wise), so some healthy funding model should be possible for people with the skill and interest.
I maintain a reasonably good table of the open source options here: https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...
It's one thing if your domain is hard, and another if you can't be bothered to fix a core problem in your service for ten months. Why would I trust you with my security if that's how long you leave vulnerabilities open after knowing about them?
> Identity, authn and authn are hard
They are technically straightforward problems. The challenge is usually political; who owns the identity, who manages the identity, privacy concerns of users, etc.
Authz can get crazy, there's a lot of over-engineered solutions there because there's basically no hard boundary between authz and general business logic.
But identity and authn are relatively straightforward, technically, and we ought to have a better FOSS solution than just Keycloak.
They are technically straightforward problems. The challenge is usually political; who owns the identity, who manages the identity, privacy concerns of users, etc.
Authz can get crazy, there's a lot of over-engineered solutions there because there's basically no hard boundary between authz and general business logic.
But identity and authn are relatively straightforward, technically, and we ought to have a better FOSS solution than just Keycloak.
> Identity, authn and authn are hard.
It would be great if you or somebody else could complete the idea of hardness with a comparison. Am I wrong if I say that this kind of auth systems require formal methods to check them? I don't think that a 10-month timeline is linked to the hard problem.
It would be great if you or somebody else could complete the idea of hardness with a comparison. Am I wrong if I say that this kind of auth systems require formal methods to check them? I don't think that a 10-month timeline is linked to the hard problem.
Are there good alternatives in 2024 to Keycloak + FreeIPA for k8s-native environments?
I have a comparison table here: https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...
Maybe Zitadel. But be aware their hosted paid plans are very expensive (they have a very original way to count daily active users). It can be self hosted on k8s, but I'm not sure how secure and mature it really is.
Hey Zitadel co-founder here.
Would you mind sharing your thoughts on our pricing? We certainly love to improve this. Its not our intent to have a smoke and mirrors pricing ;-)
On the subject of maturity and security. Many known enterprises trust Zitadel for their identity needs, especially the self-hosted version, which can be used for free. I think what makes Zitadel a great package in regard of security is that our community actively provides vulnerability disclosures to the project which we track in public.
Let us know what we can improve to show that we take security and stability serious!
Would you mind sharing your thoughts on our pricing? We certainly love to improve this. Its not our intent to have a smoke and mirrors pricing ;-)
On the subject of maturity and security. Many known enterprises trust Zitadel for their identity needs, especially the self-hosted version, which can be used for free. I think what makes Zitadel a great package in regard of security is that our community actively provides vulnerability disclosures to the project which we track in public.
Let us know what we can improve to show that we take security and stability serious!
Thoughts about pricing:
- the step up from free to paid is huge, and already needed if you have 4-5 users that log in every day
- your definition of "daily active user" is a bit tricky, as one user who logs in every day is counted as 31 users. The most common metric I know is monthly active users (users that log in at least once a month)
- the step up from free to paid is huge, and already needed if you have 4-5 users that log in every day
- your definition of "daily active user" is a bit tricky, as one user who logs in every day is counted as 31 users. The most common metric I know is monthly active users (users that log in at least once a month)
Great input, thank you!
So, if we would increase the free amount and the included in the pro tier it would a little alleviate this pain?
On the definition, we wanted to use DAU because with this we can have on metric to price consumers, business customers and service accounts. To us it was weird to pay for a MAU when a consumer only logs in once a month. Coming back to my reply above... would a "bigger" number of included DAU solve this?
So, if we would increase the free amount and the included in the pro tier it would a little alleviate this pain?
On the definition, we wanted to use DAU because with this we can have on metric to price consumers, business customers and service accounts. To us it was weird to pay for a MAU when a consumer only logs in once a month. Coming back to my reply above... would a "bigger" number of included DAU solve this?
I think it's your business decision how much quota you want to give away for free and how much you charge for each DAU.
But the current free plan has a few issues (I would even call them traps):
It has a monthly DAU and API request limit. If this limit is exhausted Zitadel will essentially shut down the service until the end of the month, unless you switch to the Pro plan, or just accept getting locked out until the end of the month.
The DAU restriction can be safeguarded by only onboarding 3 users, then the DAU quota will never be exhausted.
The API limit is even more tricky, if your users heavily use the console or log in very often it is out of your control.
This makes the Zitadel free plan practically just a demo version (1 admin user, 1 test account, 1 service account). In my case I nearly hit the quota already after 5 days of developing a product, just me, developing alone. I ended up switching to auth0, because I was not very invested in Zitadel yet.
But the current free plan has a few issues (I would even call them traps):
It has a monthly DAU and API request limit. If this limit is exhausted Zitadel will essentially shut down the service until the end of the month, unless you switch to the Pro plan, or just accept getting locked out until the end of the month.
The DAU restriction can be safeguarded by only onboarding 3 users, then the DAU quota will never be exhausted.
The API limit is even more tricky, if your users heavily use the console or log in very often it is out of your control.
This makes the Zitadel free plan practically just a demo version (1 admin user, 1 test account, 1 service account). In my case I nearly hit the quota already after 5 days of developing a product, just me, developing alone. I ended up switching to auth0, because I was not very invested in Zitadel yet.
I know it’s our decision, but I wanted to get a sense of how our pricing looks to people from a less biased perspective. Thanks for taking the time to share your thoughts!
I’ll take your points for a spin internally. We’ve already had some ideas that address some of your concerns, especially around the quotas.
I’ll take your points for a spin internally. We’ve already had some ideas that address some of your concerns, especially around the quotas.
I set up Zitadel Cloud for the services at home, just for a few basic services (professionally I'm mostly using AAD and Keycloak).
Already with one user per family member we are coming dangerously close to the quotas, it's my fault, I didn't take the time to check the terms and conditions. But I honestly did not expect the free plan to be that restrictive. I just stopped at "100 users" and thought: "well, that should be enough". That's why I'm warning everyone about this fact.
Already with one user per family member we are coming dangerously close to the quotas, it's my fault, I didn't take the time to check the terms and conditions. But I honestly did not expect the free plan to be that restrictive. I just stopped at "100 users" and thought: "well, that should be enough". That's why I'm warning everyone about this fact.
I see, no worries btw. we do not take an insult in you talking about this. On the contrary you raise a valid point which we need to improve.
Not the parent, but DAUs make a lot of sense when you have lots of external collaborators than seldomly login. That way you don't pay a full month license for somebody that logged in twice or once in that period, I rather log them in manually :-)
About the pricing, I haven't made the calculations in your product, but in other products I sometimes miss a middle ground between free and pro like a "hobby" or "mini" tier. maybe I have a small product, an SMB, or a personal thing thing that needs a service, and I don't want to be a "freeloader" on the free plan, but the pro is too much.
There are services I've used that I know I'll stop using once I grow out of the free plan, because it's so expensive.
About the pricing, I haven't made the calculations in your product, but in other products I sometimes miss a middle ground between free and pro like a "hobby" or "mini" tier. maybe I have a small product, an SMB, or a personal thing thing that needs a service, and I don't want to be a "freeloader" on the free plan, but the pro is too much.
There are services I've used that I know I'll stop using once I grow out of the free plan, because it's so expensive.
Noted, so something between a free plan and the $100 pro would fit your needs.
Like a $25ish developer tier I guess, right?
Like a $25ish developer tier I guess, right?
I guess this would be a good start, it would allow instances for smaller companies.
Another thing would be to mix daily active users and monthly active users. For example in the ratio 1:10 (100 DAUs or 10 MAUs). Just cap the DAU counter for a user at 10 logins per month.
It's really hard to predict how often users are going to log in. So if you have a company with 50 people, you know 50 MAUs are enough. But will 500 DAUs be enough? You just don't know that in advance. The DAUs can also grow a lot even if MAUs stay the same, if your product becomes better and is used more often in the company. Really hard to tell the customer at a later stage that Zitadel is now more expensive, because people log in more often. The DAU/API limit is also an incentive to cache authentication/2FA longer and compromise on security.
Maybe remove a few enterprise features for the cheaper plans like SAML or restrict branding. But please keep passwordless/2FA, for me those features were the main reason to try Zitadel, that's one of the features where Zitadel shines over auth0.
Another thing would be to mix daily active users and monthly active users. For example in the ratio 1:10 (100 DAUs or 10 MAUs). Just cap the DAU counter for a user at 10 logins per month.
It's really hard to predict how often users are going to log in. So if you have a company with 50 people, you know 50 MAUs are enough. But will 500 DAUs be enough? You just don't know that in advance. The DAUs can also grow a lot even if MAUs stay the same, if your product becomes better and is used more often in the company. Really hard to tell the customer at a later stage that Zitadel is now more expensive, because people log in more often. The DAU/API limit is also an incentive to cache authentication/2FA longer and compromise on security.
Maybe remove a few enterprise features for the cheaper plans like SAML or restrict branding. But please keep passwordless/2FA, for me those features were the main reason to try Zitadel, that's one of the features where Zitadel shines over auth0.
Dex + FreeIPA (or whatever backend you want to use) ?
Although 2FA is pending merge: https://github.com/dexidp/dex/pull/3712
Although 2FA is pending merge: https://github.com/dexidp/dex/pull/3712
Dex is very good if you have some other auth in place, but the local user store is quite bare-bones, and not all providers are equally good.
On the other hand it is very light on resources, so if you need it anywhere you can add it to you app/deployment and be happy.
On the other hand it is very light on resources, so if you need it anywhere you can add it to you app/deployment and be happy.
I think most of the other commenters trying to suggest that RH is arms-length on Keycloak are missing that most of the core contributors work for RedHat.
> I am a strong proponent of open source. However, I believe that those who develop important projects should carefully consider the impact that their work can have. I think that for a centralized authentication system, a bypass of the two-factor authentication should be solved or at least mitigated in a timely manner: 10 months is a lot of time to fix a core feature of a security product.
What does the author propose as the solution here? Simply saying "you should be careful" isn't a solution. If you proposed a fix, where was the PR? Why is there no further discussion of what the holdups were?
My guess here, not being privy to internal communications: The RedHat folks were probably worried that a simple change like increasing the required access to add another 2FA would break some other functionality, or cause logical loopholes for situations where a user loses access to their 2nd factors. The result was that they were exceedingly careful/slow to get to testing and validation. Doesn't make it right. This guess comes from what I observed in my previous time at IBM -- I saw a lot of the company's open source contributions hung up in similar ways.
> I am a strong proponent of open source. However, I believe that those who develop important projects should carefully consider the impact that their work can have. I think that for a centralized authentication system, a bypass of the two-factor authentication should be solved or at least mitigated in a timely manner: 10 months is a lot of time to fix a core feature of a security product.
What does the author propose as the solution here? Simply saying "you should be careful" isn't a solution. If you proposed a fix, where was the PR? Why is there no further discussion of what the holdups were?
My guess here, not being privy to internal communications: The RedHat folks were probably worried that a simple change like increasing the required access to add another 2FA would break some other functionality, or cause logical loopholes for situations where a user loses access to their 2nd factors. The result was that they were exceedingly careful/slow to get to testing and validation. Doesn't make it right. This guess comes from what I observed in my previous time at IBM -- I saw a lot of the company's open source contributions hung up in similar ways.
The author seems to be suggesting that if you don't have time to fix even basic security bugs in a security project, you may want to consider archiving it and making sure people know your project is unmaintained?! I kind of agree with that because lots of businesses may be impacted by this kind of bug, and if they knew the project was no longer maintained effectively, they might have considered migrating elsewhere.
Anybody worth their salt at RedHat has been 86’d or sunsetted with a golden parachute after the IBM acquisition.
10 months for IBM and subsidiaries is actually much better than average, with all things considered.
10 months for IBM and subsidiaries is actually much better than average, with all things considered.
Some developers write needless low level codes to intimidate other developers, which makes Keycloak difficult to maintain.
hooli_gan(2)
Having very high expectations when using the software without contributing anything else than public shaming on something that clearly state in the license: "Licensor provides the Work ... WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND" shouldn't be ok, this is quite literally how you make open source developer to burn out