4 ms·

Ah, the SSO tax. We only care about security if you pay us, even if you implement it yourself.

SushiHippie 3y ago
> Ah, the SSO tax For others that are not aware: https://sso.tax/ https://sso.tax/
Avamander 3y ago
Yeah, security features shouldn't be behind a paywall. I despise vendors that do it and do my best to avoid paying for products like that (and persuade my employer to do the same). You can say they have to make money somehow, but I don't care, not with this.
paulryanrogers 3y ago
SSO isn't fundamental to most "open core" projects' security. So excluding from core seems like a reasonable compromise. They have to make money somehow. And IME the SSO implementations can be fidly and bespoke, so worth charging a premium to support.
- Avamander 3y ago
  It is, because even without looking at the product I can be very certain they don't implement nearly as good 2FA as say Keycloak or other solutions like that out there. If anything, save some money and stop reimplementing all the login and account management functionality and let the OIDC (or worse, SAML) provider do it.
- kbolino 3y ago
  The problem is that login without SSO usually means even more fiddly and bespoke password and MFA implementations. Can I paste in the password field? What and how many characters are allowed? Is it fed into a properly salted KDF? Can the password be intercepted by common logging/monitoring tools? How do I reset my password? Are there MFA options other than either SMS or TOTP? Can I have multiple MFA options active simultaneously, in case I lose access to one? Does an attacker having access to my email bypass all the other security measures? etc. The support burden of doing that right has to be higher than that of doing SSO right. Of course, many won't prioritize hardening the open core security model until a large client suffers a breach, and a large client won't usually be using the open core anyway. However, I actually agree with you about SSO implementations being too fiddly and bespoke, and moreover even doing OAuth2/OIDC the right way is tricky. Many/most guides online focus on using auth tokens to talk to first-party or tightly integrated APIs. Whereas, when using an OIDC provider for SSO, you actually just want proof-of-identity. Do I get an auth token and then call an identity endpoint? If so, do they support PKCE in the code flow? Do I get an ID token and then validate it? If so, do they support nonces in the flow? Which algorithms will be used to sign the token, and where do I get the keys? Even the major social-login providers don't all agree on the answers to these questions.
IshKebab 3y ago
That's not why SSO is always in the enterprise version. It's not that the authors don't care about security, it's that only enterprises care about SSO. That makes it a really good feature to withhold in order to force enterprises to pay, without significantly affecting individuals who want to use it. (Standard HN disclaimer: when someone says "only this" or "everybody" or "nobody" in normal speech they don't mean literally nobody. You aren't proving me wrong by saying "ackshewally I use SSO and I'm not an enterprise".)
- dugite-code 3y ago
  > only enterprises care about SSO. Well that's just fundamentally not true any longer with OIDC. There are even simple OIDC auth plugins for reverse proxies now. It's what I consider a fairly basic feature in this day and age and it's a shame every time it's disregard as simply an enterprise feature You might have an argument with saml, because it's a right pain, but not OIDC
  - IshKebab 3y ago
    I don't really follow. If you're setting this up for a couple of people you can just manually add accounts. It's probably even easier than setting up OIDC or whatever. It's only when you get to enterprise level and IT departments want centralised accounts that it matters. They really need SSO. Frankly I think it's a pretty great status quo. Consider the alternative, which is that the software would either not exist or be closed source.
    - kuschku 3y ago
      If only enterprises need SSO, please tell me how I'd set up WebAuthn 2FA for these services without SSO. Also, please explain how I'd change my password across this project, miniflux, seafile, postfix, dovecot, radicale, quassel, synapse and more all at the same time without SSO (in case the password got leaked) So far, using keycloak and adding SSO support to these apps seems certainly like an easier option even for setups with 3-5 users such as my own.
gehen88 3y ago
SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly). Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.
- kuschku 3y ago
  For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access. Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary. I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them. I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them. I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place. The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.

> Ah, the SSO tax For others that are not aware: https://sso.tax/ https://sso.tax/

Yeah, security features shouldn't be behind a paywall. I despise vendors that do it and do my best to avoid paying for products like that (and persuade my employer to do the same). You can say they have to make money somehow, but I don't care, not with this.

paulryanrogers 3y ago

SSO isn't fundamental to most "open core" projects' security. So excluding from core seems like a reasonable compromise. They have to make money somehow. And IME the SSO implementations can be fidly and bespoke, so worth charging a premium to support.

Avamander 3y ago
It is, because even without looking at the product I can be very certain they don't implement nearly as good 2FA as say Keycloak or other solutions like that out there. If anything, save some money and stop reimplementing all the login and account management functionality and let the OIDC (or worse, SAML) provider do it.
kbolino 3y ago
The problem is that login without SSO usually means even more fiddly and bespoke password and MFA implementations. Can I paste in the password field? What and how many characters are allowed? Is it fed into a properly salted KDF? Can the password be intercepted by common logging/monitoring tools? How do I reset my password? Are there MFA options other than either SMS or TOTP? Can I have multiple MFA options active simultaneously, in case I lose access to one? Does an attacker having access to my email bypass all the other security measures? etc. The support burden of doing that right has to be higher than that of doing SSO right. Of course, many won't prioritize hardening the open core security model until a large client suffers a breach, and a large client won't usually be using the open core anyway. However, I actually agree with you about SSO implementations being too fiddly and bespoke, and moreover even doing OAuth2/OIDC the right way is tricky. Many/most guides online focus on using auth tokens to talk to first-party or tightly integrated APIs. Whereas, when using an OIDC provider for SSO, you actually just want proof-of-identity. Do I get an auth token and then call an identity endpoint? If so, do they support PKCE in the code flow? Do I get an ID token and then validate it? If so, do they support nonces in the flow? Which algorithms will be used to sign the token, and where do I get the keys? Even the major social-login providers don't all agree on the answers to these questions.

IshKebab 3y ago

That's not why SSO is always in the enterprise version. It's not that the authors don't care about security, it's that only enterprises care about SSO. That makes it a really good feature to withhold in order to force enterprises to pay, without significantly affecting individuals who want to use it. (Standard HN disclaimer: when someone says "only this" or "everybody" or "nobody" in normal speech they don't mean literally nobody. You aren't proving me wrong by saying "ackshewally I use SSO and I'm not an enterprise".)

dugite-code 3y ago
> only enterprises care about SSO. Well that's just fundamentally not true any longer with OIDC. There are even simple OIDC auth plugins for reverse proxies now. It's what I consider a fairly basic feature in this day and age and it's a shame every time it's disregard as simply an enterprise feature You might have an argument with saml, because it's a right pain, but not OIDC
- IshKebab 3y ago
  I don't really follow. If you're setting this up for a couple of people you can just manually add accounts. It's probably even easier than setting up OIDC or whatever. It's only when you get to enterprise level and IT departments want centralised accounts that it matters. They really need SSO. Frankly I think it's a pretty great status quo. Consider the alternative, which is that the software would either not exist or be closed source.
  - kuschku 3y ago
    If only enterprises need SSO, please tell me how I'd set up WebAuthn 2FA for these services without SSO. Also, please explain how I'd change my password across this project, miniflux, seafile, postfix, dovecot, radicale, quassel, synapse and more all at the same time without SSO (in case the password got leaked) So far, using keycloak and adding SSO support to these apps seems certainly like an easier option even for setups with 3-5 users such as my own.

gehen88 3y ago

SSO is not a requirement for secure software. It’s a requirement for enterprises because otherwise they have to manually keep track of everyone’s accounts everywhere, but that’s a management issue not a security issue (unless managed poorly). Admittedly for many SaaS and OSS offerings SSO is an enterprise-only feature while it doesn’t have to be, but it’s the best discriminator they have to separate cheaper plans from enterprise plans. The alternative is to charge more for all plans, but then you lose out to the competition that does play this enterprise tax game.

kuschku 3y ago
For software to have secure authZ/authN, it should have robust 2FA mechanisms including WebAuthn, properly integrate with access tokens, and support scoped third party access. Most software only offers simple username/password auth, or a paid SSO option as the only way to get 2FA working. And SSO makes it much easier to revoke access or change passwords if necessary. I'm running hundreds of services self-hosted just for myself and less than a handful of close friends. I'm using SSO for all of them. I had to patch SSO into countless services and I actively maintain forks with self-reimplemented enterprise features for almost half of them. I had to do similar changes to get S3 support, as I use the AGPL version of Minio as storage backend for everything so I only have to setup backups in a single place. The only reason one could try to argue that these are enterprise only features is if you assume personal users have no need for 2FA or backups.