8 ms·

An analysis of the Keycloak authentication system

189 points by udev4096 2y ago

mickael-kerjean 2y ago
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? 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
- some_furry 2y ago
  > 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.
  - noselasd 2y ago
    > 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.
    - deleted 2y ago
      [deleted]
    - ziddoap 2y ago
      >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.
      - flanked-evergl 2y ago
        > 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#L144-L175 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.
        ziddoap 2y ago
        Point 7 buried in the license document of the github repository is very much not https://www.keycloak.org/ https://www.keycloak.org/
        willcipriano 2y ago
        Customers have been refunded in full.
  - rcxdude 2y ago
    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).
    - some_furry 2y ago
      > 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.
    - prmoustache 2y ago
      > 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.
      - some_furry 2y ago
        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").
      - rcxdude 2y ago
        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)
- hypeatei 2y ago
  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.
  - debarshri 2y ago
    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.
- deleted 2y ago
  [deleted]
- tapoxi 2y ago
  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.
  - hiciu 2y ago
    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.
    - tapoxi 2y ago
      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.
      - TheNewsIsHere 2y ago
        Not necessarily. Red Hat issues patches and backports to customers regularly and those don’t necessarily flow upstream right away (or sometimes ever).
    - ffsm8 2y ago
      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 https://github.com/keycloak/keycloak/discussions/25688
- aseipp 2y ago
  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.
  - threatofrain 2y ago
    Is it still funded by Red Hat today?
    - aseipp 2y ago
      Several developers and full-time employees, including the project lead, are still employed by Red Hat.
- tgsovlerkhgsel 2y ago
  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.
  - hinkley 2y ago
    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.
    - from-nibly 2y ago
      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...
      - hinkley 2y ago
        No, they end up in the court of public opinion. <gestures around> And they make you lonely if you keep losing.
    - water-data-dude 2y ago
      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.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
  - 2y ago
- its-summertime 2y ago
  > 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.
  - hinkley 2y ago
    That was a very articulate and nice way of saying, “what if instead of using the tired old deflection you looked at the facts?”
ants_everywhere 2y ago
Are there good alternatives in 2024 to Keycloak + FreeIPA for k8s-native environments?
- tecleandor 2y ago
  Dex + FreeIPA (or whatever backend you want to use) ? Although 2FA is pending merge: https://github.com/dexidp/dex/pull/3712 https://github.com/dexidp/dex/pull/3712
  - folmar 2y ago
    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.
- andix 2y ago
  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.
  - ffo 2y ago
    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!
    - andix 2y ago
      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)
hooli_gan 2y ago
[flagged]
- tgsovlerkhgsel 2y ago
  That doesn't help you fix other vulnerabilities that may have been found and reported by others but not fixed. You alone will never find all of them.
- goku12 2y ago
  This is a digital security company reporting their findings, along with the fix. They did everything that could be expected of them. The real problem is how long RH took to address vulnerabilities. OSS isn't an excuse. There are other OSS projects with much less resources, that take security much more seriously. To make it worse, it isn't easy switch IdP software - even for OSS ones.
jillyboel 2y ago
[flagged]
wvh 2y ago
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.
- apitman 2y ago
  I maintain a reasonably good table of the open source options here: https://github.com/lastlogin-net/obligator?tab=readme-ov-file#comparison-is-the-thief-of-joy https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...
  - cinntaile 2y ago
    Assuming this is a rather complete list... It's interesting that most were written in Go.
    - rnewme 2y ago
      And how it has little dependencies
  - mjcohen 2y ago
    What is Vanity?
  - moribvndvs 2y ago
    Any insight on supertokens? https://supertokens.com/ https://supertokens.com/
- stavros 2y ago
BeefWellington 2y ago
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.
- brabel 2y ago
  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.
ei625 2y ago
Some developers write needless low level codes to intimidate other developers, which makes Keycloak difficult to maintain.
xyst 2y ago
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.

189 points by udev4096 2y ago

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

some_furry 2y ago
> 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.
- noselasd 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
  - ziddoap 2y ago
    >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.
    - flanked-evergl 2y ago
      > 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#L144-L175 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.
      - ziddoap 2y ago
        Point 7 buried in the license document of the github repository is very much not https://www.keycloak.org/ https://www.keycloak.org/
        willcipriano 2y ago
        Customers have been refunded in full.
- rcxdude 2y ago
  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).
  - some_furry 2y ago
    > 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.
  - prmoustache 2y ago
    > 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.
    - some_furry 2y ago
      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").
    - rcxdude 2y ago
      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)
hypeatei 2y ago
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.
- debarshri 2y ago
  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.
deleted 2y ago
[deleted]
tapoxi 2y ago
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.
- hiciu 2y ago
  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.
  - tapoxi 2y ago
    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.
    - TheNewsIsHere 2y ago
      Not necessarily. Red Hat issues patches and backports to customers regularly and those don’t necessarily flow upstream right away (or sometimes ever).
  - ffsm8 2y ago
    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 https://github.com/keycloak/keycloak/discussions/25688
aseipp 2y ago
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.
- threatofrain 2y ago
  Is it still funded by Red Hat today?
  - aseipp 2y ago
    Several developers and full-time employees, including the project lead, are still employed by Red Hat.
tgsovlerkhgsel 2y ago
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.
- hinkley 2y ago
  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.
  - from-nibly 2y ago
    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...
    - hinkley 2y ago
      No, they end up in the court of public opinion. <gestures around> And they make you lonely if you keep losing.
  - water-data-dude 2y ago
    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.html https://journal.neilgaiman.com/2009/05/entitlement-issues.ht...
- 2y ago
its-summertime 2y ago
> 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.
- hinkley 2y ago
  That was a very articulate and nice way of saying, “what if instead of using the tired old deflection you looked at the facts?”

ants_everywhere 2y ago

Are there good alternatives in 2024 to Keycloak + FreeIPA for k8s-native environments?

tecleandor 2y ago
Dex + FreeIPA (or whatever backend you want to use) ? Although 2FA is pending merge: https://github.com/dexidp/dex/pull/3712 https://github.com/dexidp/dex/pull/3712
- folmar 2y ago
  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.
andix 2y ago
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.
- ffo 2y ago
  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!
  - andix 2y ago
    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)

hooli_gan 2y ago

[flagged]

tgsovlerkhgsel 2y ago
That doesn't help you fix other vulnerabilities that may have been found and reported by others but not fixed. You alone will never find all of them.
goku12 2y ago
This is a digital security company reporting their findings, along with the fix. They did everything that could be expected of them. The real problem is how long RH took to address vulnerabilities. OSS isn't an excuse. There are other OSS projects with much less resources, that take security much more seriously. To make it worse, it isn't easy switch IdP software - even for OSS ones.

jillyboel 2y ago

[flagged]

wvh 2y ago

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.

apitman 2y ago
I maintain a reasonably good table of the open source options here: https://github.com/lastlogin-net/obligator?tab=readme-ov-file#comparison-is-the-thief-of-joy https://github.com/lastlogin-net/obligator?tab=readme-ov-fil...
- cinntaile 2y ago
  Assuming this is a rather complete list... It's interesting that most were written in Go.
  - rnewme 2y ago
    And how it has little dependencies
- mjcohen 2y ago
  What is Vanity?
- moribvndvs 2y ago
  Any insight on supertokens? https://supertokens.com/ https://supertokens.com/
stavros 2y ago

BeefWellington 2y ago

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.

brabel 2y ago
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.

ei625 2y ago

Some developers write needless low level codes to intimidate other developers, which makes Keycloak difficult to maintain.

xyst 2y ago

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.