4 ms·

From a security engineering perspective I think strong authentication should be table stakes, and the proliferation of WebAuthn is a good starting point. For mo

by sebk 4y ago

From a security engineering perspective I think strong authentication should be table stakes, and the proliferation of WebAuthn is a good starting point. For most enterprise companies it also likely makes sense from a risk management perspective. Single sign-on, however, is a convenience feature, not necesarily a security feature. And as such, I think it's acceptable for it to be an add on subscription. This is especially true when the application in question offers strong authentication with no opt outs, which doesn't seem to be the case with Tuple -- I don't see a way to set a second factor, and the app happily let me register with 'password1234' as my password. Given their lack of strong authentication, I agree with SSO being part of the base subscription, for their own sake more than their customers'. I'd like to see them improve, revamp, or remove their direct login feature altogether.

konha 4y ago
> Single sign-on, however, is a convenience feature, not necesarily a security feature. What about removing access from tens of saas after a user left the company? Without SSO / centralized user management this gets skipped all the time.
- sebk 4y ago
  Relying on severing SSO access for this purpose is not enough. Those SaaS can be running processes that don't require an online user, or could support non-SSO API keys, or could still be taking up license seats. SSO in general is not a substitute for the full identity management lifecycle, protocols like SCIM are. I also believe these fall squarely in the convenience arena, but I also know that convenience and security are not orthogonal.
  - hnlmorg 4y ago
    The context of this discussion isn’t about using Google or Facebook style SSO, it’s about SaaS supporting enterprise identity providers.
  - haswell 4y ago
    Agree that SSO isn’t enough by itself. Every app should have a full user lifecycle which involves more than just “Set user to inactive”. But SSO eliminates an entire set of problems and increases the chances that someone will actually bother to worry about the other lifecycle elements. The chances that IT will invest in proper fully custom lifecycle automations are low. The reality is that it’ll be turned into a runbook and someone will take these steps manually. SSO doesn’t magically solve that, but does let IT/Infosec focus on the lifecycle part. Also not universally true, but an app that doesn’t support SSO isn’t likely to support SCIM, and so now there’s a huge job ahead for the teams bringing a new tool into the org. Setting aside security for a moment, the other outcome is that an increasing number of companies just won’t consider software that doesn’t have this support. I realize the discussion is about SSO-as-a-premium-feature, but when you start charging extra for something that is increasingly seen as a requirement for getting in the door, it leaves a bad taste in customer’s mouths. Better to just price it in.
- dgb23 4y ago
  You can do that without SSO/SAML/whatever? As GP said this is not a security feature. It doesn't solve any of the security issues mentioned and it does not guarantee that the other side is implementing it correctly.
  - hnlmorg 4y ago
    You can but it’s more work to build and results in infrastructure that has more places where things can go wrong. SSO is the standard (and, in my opinion, “correct”) way to manage identities across otherwise unconnected systems.
haswell 4y ago
> Single sign-on, however, is a convenience feature, not necesarily a security feature. I can’t fully agree with this, at least in an enterprise setting. In an enterprise setting that has already standardized on <SSO solution>, any product that doesn’t support SSO will require a one-off set of processes for: - Onboarding - Password reset / recovery - Offboarding - Profile syncing Each of these introduces yet another potential avenue for compromise, and at best, introduces more complexity into the environment - both for the IT team managing it, and for end-users. SCIM helps, but a product that doesn’t support SSO probably isn’t going to support SCIM. Even if the app provides strong authentication with no opt-outs, there is now additional burden on end-users to be aware of potential app-specific phishing expeditions. IT cannot continue to say “the only real password recovery email looks like xyz”. There is now more burden on IT to ensure every non-SSO app has proper offboarding. Every non-SSO app is a misconfiguration away from being an attack vector for disgruntled former employees. You may be right that SSO is primarily about convenience, but convenience isn’t just about the end-user and their login experience. Convenience can also be a security feature, if it means that the app can automatically benefit from some base level of security policy with little effort. Convenience becomes a security feature when the lack of that convenience leads to an equivalent lack of security - directly or indirectly - and this is often the case with apps that have no SSO support. Apps that lack this support also tend to lack other advanced security settings that would be needed to make up for the lack of SSO. (Former auth PM for a big SaaS, so my bias leans towards SSO-first, but this is what I saw when working with many large customers).
- konha 4y ago
  > Former auth PM for a big SaaS What’s your advice for small B2B startups looking into providing SSO for their customers? Start with something like Keycloak and set things up manually for each customer? Is it even realistic to provide this in an automated / self-serve fashion with limited resources allocated to this?
  - catsonthestreet 4y ago
    We created PropelAuth specifically for B2B startups. A lot of our competitors focus on individual users but we offer Organizations or Groups as a concept - meaning user invitations to an organization, roles scoped to that organization, etc. We're also completely self-service: https://docs.propelauth.com/ https://docs.propelauth.com/
AtNightWeCode 4y ago
Offboarding simply does not work at companies that lacks SSO or equivalent tech.

by sebk 4y ago

konha 4y ago

> Single sign-on, however, is a convenience feature, not necesarily a security feature. What about removing access from tens of saas after a user left the company? Without SSO / centralized user management this gets skipped all the time.

sebk 4y ago
Relying on severing SSO access for this purpose is not enough. Those SaaS can be running processes that don't require an online user, or could support non-SSO API keys, or could still be taking up license seats. SSO in general is not a substitute for the full identity management lifecycle, protocols like SCIM are. I also believe these fall squarely in the convenience arena, but I also know that convenience and security are not orthogonal.
- hnlmorg 4y ago
  The context of this discussion isn’t about using Google or Facebook style SSO, it’s about SaaS supporting enterprise identity providers.
- haswell 4y ago
  Agree that SSO isn’t enough by itself. Every app should have a full user lifecycle which involves more than just “Set user to inactive”. But SSO eliminates an entire set of problems and increases the chances that someone will actually bother to worry about the other lifecycle elements. The chances that IT will invest in proper fully custom lifecycle automations are low. The reality is that it’ll be turned into a runbook and someone will take these steps manually. SSO doesn’t magically solve that, but does let IT/Infosec focus on the lifecycle part. Also not universally true, but an app that doesn’t support SSO isn’t likely to support SCIM, and so now there’s a huge job ahead for the teams bringing a new tool into the org. Setting aside security for a moment, the other outcome is that an increasing number of companies just won’t consider software that doesn’t have this support. I realize the discussion is about SSO-as-a-premium-feature, but when you start charging extra for something that is increasingly seen as a requirement for getting in the door, it leaves a bad taste in customer’s mouths. Better to just price it in.
dgb23 4y ago
You can do that without SSO/SAML/whatever? As GP said this is not a security feature. It doesn't solve any of the security issues mentioned and it does not guarantee that the other side is implementing it correctly.
- hnlmorg 4y ago
  You can but it’s more work to build and results in infrastructure that has more places where things can go wrong. SSO is the standard (and, in my opinion, “correct”) way to manage identities across otherwise unconnected systems.

haswell 4y ago

> Single sign-on, however, is a convenience feature, not necesarily a security feature. I can’t fully agree with this, at least in an enterprise setting. In an enterprise setting that has already standardized on <SSO solution>, any product that doesn’t support SSO will require a one-off set of processes for: - Onboarding - Password reset / recovery - Offboarding - Profile syncing Each of these introduces yet another potential avenue for compromise, and at best, introduces more complexity into the environment - both for the IT team managing it, and for end-users. SCIM helps, but a product that doesn’t support SSO probably isn’t going to support SCIM. Even if the app provides strong authentication with no opt-outs, there is now additional burden on end-users to be aware of potential app-specific phishing expeditions. IT cannot continue to say “the only real password recovery email looks like xyz”. There is now more burden on IT to ensure every non-SSO app has proper offboarding. Every non-SSO app is a misconfiguration away from being an attack vector for disgruntled former employees. You may be right that SSO is primarily about convenience, but convenience isn’t just about the end-user and their login experience. Convenience can also be a security feature, if it means that the app can automatically benefit from some base level of security policy with little effort. Convenience becomes a security feature when the lack of that convenience leads to an equivalent lack of security - directly or indirectly - and this is often the case with apps that have no SSO support. Apps that lack this support also tend to lack other advanced security settings that would be needed to make up for the lack of SSO. (Former auth PM for a big SaaS, so my bias leans towards SSO-first, but this is what I saw when working with many large customers).

konha 4y ago
> Former auth PM for a big SaaS What’s your advice for small B2B startups looking into providing SSO for their customers? Start with something like Keycloak and set things up manually for each customer? Is it even realistic to provide this in an automated / self-serve fashion with limited resources allocated to this?
- catsonthestreet 4y ago
  We created PropelAuth specifically for B2B startups. A lot of our competitors focus on individual users but we offer Organizations or Groups as a concept - meaning user invitations to an organization, roles scoped to that organization, etc. We're also completely self-service: https://docs.propelauth.com/ https://docs.propelauth.com/

AtNightWeCode 4y ago

Offboarding simply does not work at companies that lacks SSO or equivalent tech.