[HN Gopher] SSO should be table stakes
___________________________________________________________________
SSO should be table stakes
Author : charlieirish
Score : 100 points
Date : 2022-06-20 14:34 UTC (8 hours ago)
(HTM) web link (tuple.app)
(TXT) w3m dump (tuple.app)
| utdiscant wrote:
| I disagree. There are entire companies built around making it
| simpler to implement and manage SSO (like https://workos.com/
| which we use) - it is time consuming to support. Enterprise
| pricing will always be about finding some way to gate enterprise
| users into a more expensive plans.
|
| Let's take Tuple as an example. You put "Active user pricing"
| into Enterprise plan. Why is that not "table stakes"? It does not
| involve complex tech, and not charging inactive users seems like
| a fair thing to offer all your customers?
|
| This blog post feels like a "beef marketing" play out of
| Basecamp's marketing book.
| corrral wrote:
| Decent place to ask I guess: what's the state-of-the-art for
| self-hosted SSO providers for a company that does a lot of self-
| hosting of open-source solutions? Like, if you're _not_ relying
| on 3rd-party support for this, aren 't using a cloud provider's
| proprietary solutions, et c., how do you do it in 2022?
| mooreds wrote:
| Disclosure: I work for FusionAuth.
|
| It isn't clear to me if you are only looking for _open-source_
| solutions. If so, keycloak is your best bet. I 've run into a
| smattering of others (Gluu, Ory, supertokens) but Keycloak is
| full featured and packagable as a container.
|
| If you are okay with "free as in beer" solutions, FusionAuth
| has a community edition you can download[0]. There are a few
| limitations, primarily around support and advanced features[1],
| but no limits on number of SSO (SAML, OIDC) connections[2].
|
| The license FAQ has more details[3].
|
| 0: https://fusionauth.io/download
|
| 1: https://fusionauth.io/pricing
|
| 2:
| https://fusionauth.io/docs/v1/tech/reference/limitations#wha...
|
| 3: https://fusionauth.io/license-faq#3
| scrollaway wrote:
| You can self-host keycloak. It's ... curiously not _that_ hard,
| though the documentation is a jungle.
| Aeolun wrote:
| Hosting it is simple, setting it up is a nightmare (though
| marginally easier than PingFederate, which is truly
| monstrous)
| softfalcon wrote:
| Correct me if I'm wrong, but isn't this why Apple, Microsoft, and
| Google are all pushing for WebAuthN/FIDO login schemes?
|
| https://fidoalliance.org/fido2-2/fido2-web-authentication-we...
|
| Apple just talked about how they're supporting FIDO with the new
| MacOS and iOS.
| advisedwang wrote:
| Not really, webauthn/fido and SSO are orthogonal (you an have
| one without the other, and you can have both).
|
| FIDO was originally about ending phishing. With SMS or TOTP, if
| you give the SMS/TOTP code to a phishing site it can forward it
| to log in. FIDO is bound to a specific site, making it non-
| forwardable. Security no longer relies on users correctly
| identifying that they're on a invalid site.
|
| Perhaps you are talking about the more recent push for
| passwordless FIDO [1]? Indeed the security argument for this is
| a lot more murky, and the cross-device portability tied to your
| browser-sync vendor looks a lot like Single Sign On.
|
| However it's still not the same as SSO. SSO provides a single
| identity, but FIDO passwordless just shares a login credential,
| not the identity. You can log into two different sites with
| FIDO passwordless with different email addresses, with no way
| for the sites to know you are the same person. There's no
| "organization" that has the power to revoke your login (I mean
| perhaps Google can, but not your employer/school/whatever like
| in SSO).
|
| [1] https://fidoalliance.org/apple-google-and-microsoft-
| commit-t...
| judge2020 wrote:
| > (I mean perhaps Google can, but not your
| employer/school/whatever like in SSO).
|
| In general yes, it'll be possible if Chrome/Android ends up
| supporting passkeys and then Google suspends your
| Chrome/Android syncing service. It'll still be good to have
| two passkeys on each service, but just on two different
| ecosystems, which still reduces the burden of needing to
| enroll every new device on every new service.
| sebk wrote:
| 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 wrote:
| > 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.
| dgb23 wrote:
| 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 wrote:
| 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.
| sebk wrote:
| 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 wrote:
| The context of this discussion isn't about using Google or
| Facebook style SSO, it's about SaaS supporting enterprise
| identity providers.
| haswell wrote:
| 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.
| AtNightWeCode wrote:
| Offboarding simply does not work at companies that lacks SSO or
| equivalent tech.
| haswell wrote:
| > _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).
| sebk wrote:
| I don't disagree, but fundamentally, you're talking about
| burden for IT operators. The opposite of burden is
| convenience, and that's fine to be charged for, in my book.
| An app implementing strong authentication might not offer a
| phishable password reset email, but rather have your password
| reset by an operator out of band, which is again, a burden.
|
| I mention this in a sibling comment, but I think lumping SSO
| with lifecycle management for offboarding and profile syncinc
| is an example of convenience in lieu of security. You might
| be making an argument for SSO _and_ SCIM to be part of base
| subscription for enterprise software, and I wonder where does
| the line get drawn for what's tables takes. Are approval
| workflows required? What about anomaly detection? These
| features are not off the shelf commodities -- SSO might be
| closer to it, but SCIM and the other definitely aren't -- and
| making them table stakes raises the barrier to entry for
| every SaaS. Or, from a consumer perspective, if I'm a small
| operation that doesn't need that convenience, I'd rather not
| subsidize other customers that do when I get the base
| subscription.
|
| _> Former auth PM for a big SaaS_
|
| Then there's a good chance we've worked together :)
| haswell wrote:
| > _The opposite of burden is convenience, and that 's fine
| to be charged for, in my book._
|
| If we zoom out a bit more, the entire product is about
| convenience. The customer pays for the product because they
| have a problem/burden that justifies the purchase of a
| product. But customers usually buy a product for the things
| that are unique about it. SSO is not one of those things
| and is trending towards commoditization. The fact that it
| affords additional convenience doesn't necessarily mean
| customers are willing to pay for that.
|
| SCIM is a bit more interesting, because it provides an
| abstraction layer over the things that _are_ unique about a
| product. SCIM is also probably overkill for products with
| sufficiently simple offboarding needs.
|
| > _You might be making an argument for SSO _and_ SCIM to be
| part of base subscription for enterprise software, and I
| wonder where does the line get drawn for what 's tables
| takes_
|
| SCIM hasn't reached the level of adoption (and customer
| expectation) that traditional forms of SSO have, and as a
| result I don't think it's in the table stakes conversation
| at this point. I think this will change over time if SCIM
| sees widespread adoption.
|
| From a customer perspective, a product without SSO can be a
| non-starter. A product without SCIM just means some
| additional integration/automation will be needed, or at
| worst, a manual process will be implemented around
| offboarding.
|
| > _Then there 's a good chance we've worked together :)_
|
| This particular world is definitely a small one, so maybe!
| ;)
| Aeolun wrote:
| Having now used SSO, I don't think I ever want to go back to
| managing permissions separately for every individual user.
|
| At the same time, I can't pay $2000 extra for every service
| just to be able to use SSO. News like this is very welcome.
| konha wrote:
| > 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?
| rsstack wrote:
| Okta, WorkOS, etc. offer easy (<1 week of work)
| implementation of fully self-service SSO. WorkOS pricing is
| very predictable and easy to offload to the customer, Okta
| are cheaper for larger numbers of customers.
| haswell wrote:
| I agree with the sibling comment re: Okta, WorkOS, etc. I
| was going to mention that products like Auth0 (now part of
| Okta) have some great options for this. I'm a couple years
| out of the space now, but I'm sure new products in the same
| category are emerging.
|
| Products like this focus on "Auth as a Service", and they
| handle the heavy lifting while providing simple integration
| points for your product.
| caloique wrote:
| infamia wrote:
| How about implementing OAuth2 and then restricting account
| creation per domain/per tenant? For example, if your only
| two customers owns foo.com and bar.com, then restrict
| account creation to those two domains (assuming they're in
| one tenant together). There are lots of mature OAuth2
| libraries, but the selection for SAML, ADFS, etc isn't
| nearly as good. You'll get the benefit of not storing
| passwords on your server and complying with whatever two-
| factor requirements the customer has, while avoiding the
| complexities of SAML, ADFS, etc. I'm curious if anyone has
| tried this approach and if so, did your customers's
| security departments sign off?
| haswell wrote:
| OAuth handles authorization.
|
| SAML/OIDC handle authentication.
|
| OAuth is only part of the story and is not an alternative
| to SAML/OIDC.
| infamia wrote:
| Thank you for the reminder! Based on my (very) limited
| knowledge, OAuth2 can still be used for so-called
| "pseudo-authentication" [1]. I'm not saying it is as good
| as SAML/OIDC, but those technologies are a major pain to
| implement and support for a small team. Pseudo-
| authentication seems like a good "bang for the buck"
| tradeoff. A more refined version of my question might be,
| "Is pseudo-authentication good enough to get past most
| security teams until you can scale up to SAML/OIDC?" I'm
| sure it likely isn't good enough for highly regulated
| industries (or Fortune 100 companies) that have
| prescriptive compliance regulations, but maybe it is good
| enough to get going in less rigid circumstances?
|
| [1] https://developer.okta.com/blog/2017/06/21/what-the-
| heck-is-...
| haswell wrote:
| This post [0] provides a pretty good overview of the
| issues/pitfalls.
|
| But setting aside the inherent security issues, I think
| we're also talking about an orthogonal use case.
|
| In the enterprise, customers use SSO to federate
| identity. Usually via a self-managed identity provider.
| Pseudo-auth with OAuth can work if the Identity Provider
| and the Application Server are one and the same, or if
| the Identity Provider is a ubiquitous service like
| Google/Facebook. In the latter case, this is the "Social
| Auth" we see on sites all over the web.
|
| But in an enterprise setting, the security team isn't
| going to allow users to authenticate as their google
| identity.
|
| So what about the app/ID server being one and the same?
| In this case, we're back to square one.
|
| I build an App A, that provides a local user database. If
| I now add an OAuth server to facilitate pseudo-auth, the
| only thing I've accomplished is I've made it possible for
| client apps to hold tokens instead of the user's
| credentials. But that user's credentials are still local
| to the app, and not connected to the user's enterprise
| identity.
|
| So while pseudo-auth with OAuth _may_ be better than say,
| Basic Auth for 1st party clients, this doesn 't help when
| the goal is to log in using the user's _existing_
| identity that lives outside of the app.
|
| The reason "Login with Facebook/Google/Twitter/etc." work
| with very low friction is the ubiquity of those services.
| If I want to "Login with Haswell's Social Site" (or more
| realistically "<Org's> Identity Provider"), I'm SOL
| unless those sites support a standards-based auth flow
| (or provides extension points that allow me to implement
| my own.
|
| - [0] http://www.thread-safe.com/2012/01/problem-with-
| oauth-for-au...
| infamia wrote:
| Thanks for the very helpful, detailed reply. I think I've
| uncovered where my mental disconnect is. The industry I'm
| focused on often uses Google Workspaces as their
| enterprise SSO provider. I guess I had assumed that
| Microsoft offered something similar that could be used
| for pseudo-authentication, but I see that's frequently
| not the case. Thanks again!
| baq wrote:
| there's a middle ground between SSO and in-application user
| profiles - LDAP - though the state of support for it is
| usually abysmal: community open source projects don't support
| it because nobody cares enough and enterprise open source
| free tier products don't support it because it's an
| enterprise feature, so it's in the 'contact us' price bucket.
| it's probably worth it for the security alone, but what a
| PITA...
| Aeolun wrote:
| SSO may be about 100x harder than LDAP. I dunno, I thought
| it was this nasty enterprisey thing, and then I found that
| it's _actually_ super lightweight.
| haswell wrote:
| LDAP is in the "SSO family", but definitely brings with it
| a lot of challenges. Chief among those is binding over the
| open Internet if you're a cloud app. It's surprising just
| how many orgs are running unencrypted LDAP, which makes
| those environments unfit for authenticating apps outside of
| the company network.
|
| I'm not sure if I would classify LDAP as a middle ground
| though (rather, it's another tool in the toolbox) - it may
| be more challenging to implement as a software startup, and
| is often not viable depending on the customer environment.
|
| Not where I'd invest development capacity in 2022.
| cratermoon wrote:
| I agree with the premise of the article, but I would not focus
| solely on SAML. Support Oauth and OIDC, if for no other reason
| than easier GDPR compliance.
| api wrote:
| As usually implemented it gives "root on the entire universe" to
| large tech companies, mainly Google and Microsoft for most sites
| and apps.
| dj_mc_merlin wrote:
| The fact that they use the "SSO Wall of Shame" (https://sso.tax/)
| as a way to sell you on the idea is funny and counterintuitive.
| nsxwolf wrote:
| Man, I hate hate hate seeing the SSO portal 30 times a day,
| reaching for my phone to answer the popup every time. Which
| sometimes gets eaten by "Focus Mode" on my iPhone, or randomly
| goes to my watch and I have to look at both.
|
| Wasn't the dream to log in once in the morning, and have your SSO
| token be valid for all systems all day? Is anyone out there
| successfully putting the "Single" in "Single Sign On"?
| ironmagma wrote:
| On top of that, it's called "two" factor authentication, not
| "phone" factor authentication. Why can I not simply use another
| computer or YubiKey to sign in, it has to be a phone? So
| annoying.
| marcosdumay wrote:
| Shouldn't need another computer either. The extra security is
| having that one computer you use all the time participating
| on the login. If it's the one you are using, there is no
| reason at all to require another.
| jiveturkey wrote:
| Yes, plenty of places do this successfully. You either have
| some very aggressive cookie blocking or your IT has it setup
| this way in some misguided strict way.
| Aeolun wrote:
| I'm fairly certain this works great for all systems that allow
| big bad enterprise to control what you do (Windows and IE, but
| Chrome is getting there too). Using FF on a Mac apparently
| makes it really hard to do automatic sign-on.
| mooreds wrote:
| It's a configuration option, so it is in control of your IT
| staff. I'm not sure if there are security risks/compliance
| requirements specifying such a short SSO session duration (20
| min?), but may be worth asking.
|
| > Wasn't the dream to log in once in the morning, and have your
| SSO token be valid for all systems all day? Is anyone out there
| successfully putting the "Single" in "Single Sign On"?
|
| I work for an identity provider that many of our clients use
| for SSO between applications, and it is absolutely possible to
| configure our solution to require 1 sign-in per day.
| dexwiz wrote:
| I have used a few SSO providers and never had this. I usually
| log into the portal once and then everything else resolve via
| redirects without interaction the rest of the day. Maybe I have
| to click confirm. This sounds like bad configuration on your
| ITs side of things.
| [deleted]
| bedatadriven wrote:
| I'm not sure about the apps you're using, but our SaaS app
| sends users to Azure AD for example to authenticate via OpenID
| Connect and in 90% of the cases they are instantly directed
| back because they are already logged in.
| mc32 wrote:
| It depends, some apps might be configured to require auth
| before taking you to the app. It may depend on compliance, or
| some company policy. Or if there is an SLO app that
| invalidates login sessions.
| coldacid wrote:
| Very likely it's your SSO vendor or IT department to blame for
| this (and in the latter case, probably due to policies they
| have to enforce but they aren't allowed to control).
| funstuff007 wrote:
| > I recommend you create an enterprise tier, put SSO in it, and
| charge 2-5x your normal pricing
|
| Good luck with that. We have enterprise clients who want SSO, and
| if we won't implement it, they will--I guess through some sort of
| browser automation. In short, you price hike has to be less than
| their marginal cost of turning on their browser automation
| switch.
| jiveturkey wrote:
| Provisioning is more important, not the SSO per se. If your
| enterprise clients are willing and able to do some kind of
| relatively hokey workaround, they are not really enterprise. At
| enterprise scale (let's call that 2500+ employees), this isn't
| feasible. Even at 1000 it's pretty borderline.
|
| That said it depends on the criticality of the service you are
| providing. If customer data is involved, enterprise will fork
| over the dollars. If not, then yes you need to price it
| correctly or in practical terms include it as a freebie for the
| other "indispensable" features that they are really going for.
| mkl95 wrote:
| At my previous gig I observed a few worrying things that were not
| fixed with security training:
|
| - People still stored passwords on Slack channels, emails,
| Confluence, etc.
|
| - People still used simple passwords such as "password".
|
| - Literally nobody who wasn't already using a password manager
| started to use one.
|
| In my opinion SSO, 2FA, etc. are absolutely needed at many places
| where people can't be trusted with following basic advice and
| training.
| powerslacker wrote:
| SSO/2FA should be required. It's less burdensome on the end
| users than expecting training to fix their bad behavior.
| ironmagma wrote:
| If that's true, why even bother with the training?
| powerslacker wrote:
| I wouldn't.
| coredog64 wrote:
| Counterpoint: Poorly configured SSO devolves to "sign-on every
| single time", which will then put you back in that same
| situation.
| ShakataGaNai wrote:
| 100% true. Poorly configured anything puts you into a
| terrible situation. If you setup a firewall and do a DENY ALL
| or ALLOW ALL blindly, you're going to have a bad time.
|
| But IN GENERAL, properly configured SSO (heck, the defaults
| for most of the SSO providers) makes for a better user
| experience while increasing security.
| hnlmorg wrote:
| It doesn't put you in the same situation. You're still more
| secure than the former situation while also being
| unnecessarily more annoying to your users.
|
| Plus I don't think anyone on here is recommending
| infrastructure should be _poorly_ configured. ;)
| jrochkind1 wrote:
| > Literally nobody who wasn't already using a password manager
| started to use one
|
| I assume you offered one that was easy to use and supported and
| any cost paid for by the employer?
| cj wrote:
| We offer Dashlane (fully paid). Adoption doesn't occur
| organically, without badgering folks.
| rubixdude wrote:
| I wonder if the author discussed this with his support team? The
| reason my company charges for SSO is then increased support cost.
|
| If everyone used Okta, no problem. But then you get an Enterpise
| customer who's using their own home grown SSO solution an we get
| to spend weeks debugging login issues.
| r00k wrote:
| I sit next to our support "team" pretty frequently :)
|
| We've had a couple painful SSO integrations (when they were
| home-grown, as you correctly point out), but we've pretty much
| got the rough edges sanded down now. I don't think we've had a
| tough one in a while.
|
| It helped to publish some short docs on it:
| https://tuple.app/sso_setup
| ShakataGaNai wrote:
| Most sites have a preset for the major identity providers,
| Okta, Microsoft, OneLogin, etc. The ones who want to be nice
| will also have a generic "SAML" option allowing connections to
| just about anything - but that's when the home grown solution
| pain shows up.
|
| But you can support just 5ish SAML IDP's and get a large
| majority of the market and have effectively no ongoing support
| issues because its really well known (and well documented) how
| to set them up.
| jacobsenscott wrote:
| SSO is a disaster and needs a lot of support, no matter how good
| your SSO implementation is. I think that's why a lot of companies
| charge for it. We don't charge extra for it, but the reality is
| it ups our support burden.
| randomuxx wrote:
| SSO is horrible. AMA
| tptacek wrote:
| I'm repeating myself here and apologize for it, but I think it's
| worth keeping this on your mind in these discussions:
|
| https://news.ycombinator.com/item?id=29892664
|
| The SSO tax is obnoxious and it's obvious why everyone hates it,
| especially security professionals. But it has nothing to do with
| the cost of providing SSO features, and everything to do with
| market segmentation: by raising prices for large organizations
| (who reliably signal themselves by requiring SSO), you can cut or
| eliminate prices for small organizations. People who demand SSO
| are, essentially, flying business class, and paying for the back
| of the plane.
| bradgessler wrote:
| If I could upvote this 1000 times I would.
|
| The process of enterprises procuring SaaS products has
| incentives that defy the common senses of a hacker.
|
| For example, if you priced the exact same product at $200 vs
| $20,000 ACV, most enterprises wouldn't consider the $200 price-
| point because they would have a really hard time justifying the
| cost of their security & procurement team's time.
|
| SAML SSO mostly exists on a plans page as an excuse for why the
| enterprise product costs 10-100x more than the base product.
|
| As a founder, you'll feel some guilt about that initially, but
| it goes away after you've explained for the one-thousandth time
| that the question, "What anti-virus software is installed on
| your organizations Windows workstations" on the vendors
| security questionnaire is irrelevant because you run your
| company on a fleet of macOS and Linux workstations. They'll
| ignore you and move on to the next question, "what firewall
| configurations do you run on your physical office's network".
| froggertoaster wrote:
| Completely agree with your take.
| throwaway490583 wrote:
| I used to like watching Tuple, but the founder of Tuple has, in
| my opinion, become increasingly obsessed with money and what him
| and Tuple are able to do with it. From how he bragged about and
| marketed his $200k Stripe Capital loan ("in this economy?!"), to
| talking about overpaying engineers "because we can", to saying
| $25/mo is a rounding error for individuals (re: ngrok's pricing
| change). I'm not a fan of this behavior, and this blog post
| echoes the same: he has money and wants everybody to know it.
| It's a bad look, at least to me (fellow founder here using a
| throwaway). The majority of us are going to stick to using SSO as
| a way to charge enterprise customers more.
| froggertoaster wrote:
| I'm seeing some posts reference https://sso.tax/ - as a SaaS
| product manager, it should be a great reference for you as it's
| basically a showcasing of successful SaaS products that properly
| segment markets.
| r00k wrote:
| Hi folks! Author here. Big fan of this topic, and happy to answer
| any questions you might have about it.
|
| Also, the shameless self-promoter in me is required to let you
| know that we're hiring a Lead Web Developer:
| https://tuple.app/jobs/web-developer.
|
| If our stance on the topic of SSO/security vs. profit appeals to
| you, please consider checking us out!
| ayewo wrote:
| Hi Ben!
|
| Slightly off-topic: If you really want folks to click through
| to your job ad, you can't go wrong if you mention that the
| salary range is ~$150k - $200k :-)
| ezekg wrote:
| Also changing the job description to software engineer, not
| web developer, may help. Quite a few colleagues wouldn't want
| to downgrade their title. :)
| mooreds wrote:
| Thanks for putting the salary range in the webdev role! (I
| asked you to do so on Twitter :) ).
|
| My question for you: do you think there are any other big,
| generic points of segmentation for SaaS consumers like SSO is?
| A few jump to mind:
|
| * uptime SLAs (you mentioned this)
|
| * data export/retention
|
| * ???
|
| I'm on record as saying that I think SSO will migrate down the
| value chain just like HTTPS did:
| https://twitter.com/mooreds/status/1481300034448760842 but am
| curious what will replace it.
| godman_8 wrote:
| I mean at $35/user month it better include SSO. That's insanely
| expensive for the limited scope of this service. I'd rather buy
| Jetbrains at $32.45/mo (after annual and 3 years of membership)
| and get a full suite of IDEs including remote pair programming
| that's compatible on macOS, Windows, and Linux.
| mffap wrote:
| https://sso.tax/ a lot of companies put SSO behind a paywall. Not
| a fan of making users pay for basic security features.
| jrockway wrote:
| It cuts both ways. While SSO is a basic security feature (and
| improves usability and reduces support burden), it also makes
| account sharing more difficult. Users on the low end plan
| definitely like account sharing; create a google group as the
| email, put the password in the shared vault, now the thing is
| $5/month instead of $30k a year.
| r00fus wrote:
| Which is why a lot of services (ie, commercial APIs) rely on
| # of hits/uses as a measure.
| jrockway wrote:
| You have to be a really useful service to price things this
| way. "Per user per month" means that people that don't use
| your software are still paying for it, which I guess is the
| best kind of user -- not adding any database rows, not
| burning any CPU, and not opening any support tickets. Good
| work if you can get it!
|
| Use-based pricing is my favorite pricing method, but your
| product has to be useful if you want to charge based on
| use. Most people don't have the guts to do it, because the
| "per user per month" is such an easy way to get money. If
| you go for use-based pricing, you have to make sure people
| actually use your thing, which is hard work!
| lmkg wrote:
| I think I read somewhere that many companies use "needs SSO" as
| a proxy for "is Enterprise customer and can pay Enterprise
| rates."
| speedgoose wrote:
| Which is wrong and a waste of time for both sides.
| Spivak wrote:
| I mean the alternative is the fat wallet tax. Is your
| company more than 20 employees or do you have more than 1M
| revenue, here's a 500% price increase.
|
| If you're at the point where employees x services is too
| big to do manually and then congrats you graduated to the
| "actually paying for the service tier."
|
| There's no real way to skin, "the only real money is by
| charging many dollars to large enterprises and if we can't
| easily price discriminate the thing we're dropping is the
| subsidized free/startup tier.
| hn_throwaway_99 wrote:
| No, it's not. SSO is basically a feature that should be
| used with _all_ companies size > 1 (and even with size =
| 1, but not as critical there). It simply should _not_ be
| considered an "enterprise" feature anymore - it should
| be considered a basic, lowest-level product requirement.
|
| There are plenty of other features that can be worth
| paying more for. Just look at GitHub Enterprise. The fact
| that the only way there is to get SSO is to pay 4.5x more
| is insane. But, as a GH Enterprise customer myself, there
| are plenty of other features (separate environments, more
| Action minutes, advanced code scanning options, etc.)
| that make GH Enterprise worth it.
| Spivak wrote:
| You know we're not disagreeing right? Is it
| simultaneously true SSO should be used by everyone at all
| company sides _and_ that small companies will absolutely
| take an 80% discount to not have it while large orgs will
| pay full price.
|
| The features of GH enterprise you listed are nice-to-
| haves, above a certain org size SSO is required.
| hn_throwaway_99 wrote:
| > that small companies will absolutely take an 80%
| discount to not have it while large orgs will pay full
| price
|
| I think we are disagreeing, because the point is that
| small orgs absolutely should _not_ have to compromise on
| this basic security feature, and the end result is a less
| secure internet that is a detriment to everyone.
| speedgoose wrote:
| Having more than 20 employees or 1M revenues isn't going
| to make an expensive product more attractive. I have been
| quoted twice this year at prices where hiring competent
| people would be a lot cheaper than purchasing the SSO
| option.
|
| But I understand the need to milk the badly managed
| companies.
| Spivak wrote:
| On the buying side we always used to joke that we could
| hire someone who's entire job would be updating peoples
| passwords for less than they were charging and still have
| 30hrs/wk of an engineer. Sadly no one volunteers to be
| the password bitch.
| speedgoose wrote:
| You could always pick one randomly and you will soon get
| a script to automate everything.
| nohuck13 wrote:
| Wrong as in unethical or wrong as in untrue?
| sdflhasjd wrote:
| Wrong as in there are non-enterprise customers that need
| SSO
| nohuck13 wrote:
| The fact that a few people without deep pockets need SSO
| doesn't invalidate the whole enterprise.
|
| If we accept that service providers are going to price
| discriminate, then we accept that they are going to price
| discriminate on _some_ imperfect heuristic.
|
| It seems to me that you have to argue
|
| (A) Businesses should not price discriminate
|
| Or
|
| (B) price discrimination based on marginal features is
| okay but this particular feature (needing SSO) isn't very
| predictive
|
| Or
|
| (C) This particular feature might be predictive, but
| security is too important to be part of a willingness-to-
| pay heuristic, so it's unethical to use this particular
| feature in this way.
|
| C seems like the argument a lot of people here are
| obliquely making.
| killjoywashere wrote:
| My SO is the owner-operator of an SCorp currently
| adjusting the business to hire W-2 #1. As the consulting
| CIO I'm doing everything I can to keep it on 1 SSO.
| mbesto wrote:
| Counterpoint - SaaS software pricing is hilariously
| underpriced at the current levels for the value it
| typically brings, that even SMBs should be paying the
| "enterprise rate" or at least some bump in price.
|
| I do think hiding SSO behind "call us" is a pain however.
| sdflhasjd wrote:
| Personally, I think even the cheaper plans are overpriced
| some of the time, considering real resource usage and
| comparing against software licenses in the past.
|
| I do wonder how much of that money goes into subsidising
| the free tiers and paying (comparatively) enormous wages
| of developers to add features I don't really want.
| mbesto wrote:
| > how much of that money goes into subsidising the free
| tiers
|
| I've seen probably ~10 companies financials that do this.
| It's ALL OVER THE PLACE. The reality is that the free
| doesn't two things: tests those new features on guinea
| pigs and lets you upsell to someone who has given you
| permission to do so.
|
| There's no free lunch.
| AtNightWeCode wrote:
| I think what people despise most about it is that SSO is
| sold as an enterprise feature. That would be ok if it was
| sold separately. But often SSO comes bundled with a lot
| of overpriced garbage in some enterprise agreement.
| Github is a prime example of this.
| mbesto wrote:
| > But often SSO comes bundled with a lot of overpriced
| garbage in some enterprise agreement.
|
| Fair. But wouldn't the opposite also hold true? The
| purchasers who say "what..I got pay $10/user/month extra
| for _JUST_ SSO? "
| AtNightWeCode wrote:
| An SSO provider costs a couple of dollars. To integrate
| one is less than 100 lines of code. That is not 10$.
| mbesto wrote:
| You're looking at that from a cost perspective. Pricing
| should be based on _value_.
|
| > To integrate one is less than 100 lines of code.
|
| Ugh not this again...
| AtNightWeCode wrote:
| This pretty much only works in the US. In the rest of the
| world companies expect to get a fair price. Hence the
| term, American prizes.
| justin_oaks wrote:
| Agreed. In the company I work for, I'll often set up SSO
| even if there will only be 3 people who ever use the
| service.
| josephcsible wrote:
| Ah, I hadn't thought of this: open core reduces security.
| f38zf5vdt wrote:
| As much as people wish that they can get SSO for free, I don't
| think it's realistic for many companies. There are a lot of
| different SSO standards out there, and even among the most
| common type (SAML2) there are many different SP and IDP
| implementations that you have to interface with to make SSO
| work properly. Then there are issues around attribute syncing,
| patching XML vulnerabilities on your implementation (which seem
| to occur regularly), dealing with customers updating or
| patching their own implementations, homebake obscurities in
| implementations for things like NameID and attribute, and
| myriad other complications.
|
| At minimum I think it's reasonable to charge for SSO onboarding
| and maintenance on as as-needed basis.
| atonse wrote:
| Not really anymore. There are many places that do self
| service SSO after charging you for it.
|
| The best happy medium I've found is allowing "sign in with
| google" for free and true SAML paid.
| throw0101a wrote:
| As a sysadmin, I simply want on-prem software to be able to take
| the username entered, create an LDAP DN, and try to do a simple
| _LDAP BIND_ attempt against the server:port of my choice.
|
| And I don't want to have to create a service account for the
| software to do things like searches: try to do the bind, and let
| the person in if it works. Anything else must be optional (all
| the world is not AD).
| imglorp wrote:
| What is the expectation for on-prem software which uses OAUTH
| SSO?
|
| OAUTH requires a redirect URI [1] which presents challenges for
| vendors wanting to sell on-prem, because it demands the
| customer to set up DNS as well as TLS certificates obviously.
| This is an ongoing challenge for us because not all shops are
| wild about vendors dictating these requirements.
|
| I'm very curious what other prem vendors do in this case, and
| what's the prem IT team's typical best case scenario here?
|
| 1. https://www.oauth.com/oauth2-servers/redirect-uris/
| throw0101a wrote:
| > _What is the expectation for on-prem software which uses
| OAUTH SSO?_
|
| And what am I supposed to send the request to if I'm running
| OpenLDAP or Samba4 for accounts? If I'm running AD then
| there's a good chance I have Azure/cloud AD, so that's a
| possibility, but that could still take official IT approval.
|
| How many 'shadow IT' operations will want to run some
| software but can't 'official' access to account system. How
| much effort would it be to go through official IT channels to
| get something inside of an organization? Will every team that
| wants to use the software be willing to go through a possibly
| Kafkaesque process? If they can just deploy a JAR or
| container and fiddle with some YAML to point to and LDAP
| server would that reduce friction? Do you think they'd want
| to deal with stand-alone in-app accounts versus leveraging
| their existing credentials? (And perhaps only deal with in-
| app groups.)
|
| If a vendor wants implement something _in addition to_ LDAP
| BIND they 're welcome to, but the possibility of getting a
| simply yes/no decision for access using existing credentials
| gets rid of a lot of friction (and would make the auditors
| happy as well probably).
| imglorp wrote:
| These are all exactly the right questions and challenges we
| are encountering, and we have no good answers. In all
| cases, customer IT would prefer vendors did not give them
| more work and risk.
|
| We could support LDAP instead of OAUTH, yes, but for the
| shops that want us to speak TLS and DNS, they still have
| some hassle.
| throw0101a wrote:
| Just to be clear: I'm asking for LDAP to be one possible
| choice. If an installation wants to use LDAP BIND they
| can use that, or if the want to use SAML they could use
| that, or OATH. But _not at the same time_ : you get to
| choose one.
|
| Django Authentication system for example has a User
| object that allows different backends to feed into it:
|
| * https://django-auth-ldap.readthedocs.io/
|
| * https://django-oauth-toolkit.readthedocs.io/
|
| * https://stackoverflow.com/questions/22668434/saml-with-
| djang...
| imglorp wrote:
| Thanks for clarifying!
| flappyeagle wrote:
| This is a straw man argument. Blog posts like this leave a bad
| taste in my mouth because of how transparently misleading they
| are.
|
| Almost every SaaS business I've run into allows you to SSO with
| providers like Google, Office365, Slack, and other common sources
| of identity.
|
| If your company is paying for SAML through Okta, you can afford
| enterprise pricing.
|
| The way I know is Okta's UX is horrible and only enterprise scale
| companies would inflict that upon their employees.
| ShakataGaNai wrote:
| > If your company is paying for SAML through Okta, you can
| afford enterprise pricing.
|
| Okta's list price starts about $7/user/mo -
| https://www.okta.com/pricing/ - That's not a huge sum. And in
| this increasing hybrid world, not uncommon for companies to be
| less than 25 employees and buying into SSO. Okta's also
| probably the most expensive of the major dedicated players in
| that space (like Ping, OneLogin, etc).
|
| Now lets look at some end systems:
|
| * https://slack.com/pricing -- Almost doubles in price to get
| SAML. $5.83 /user/mo increase.
|
| * https://zoom.us/pricing -- $50/user/year increase
| (~$4.14/user/mo)
|
| * https://www.atlassian.com/software/access/pricing --
| $4/user/mo
|
| A lot of other systems don't even publish their prices, like
| Smartsheet. But just two of those systems alone are more than
| the cost of Okta. And hardly any companies have only "2 or 3"
| systems to SAML.
|
| So as a business you can get a SSO provider for reasonable
| cost, but end up paying many multiples more than the cost of
| the provider...to the services to get support. Is each
| individual service breaking the bank? No. But are they a
| problem for IT staffs to get budget cumulatively? Very much so.
| flappyeagle wrote:
| I didn't say you can pay for enterprise pricing because okta
| is expensive monetarily. I said it's because oktas UX is
| terrible and only enterprise companies would force that on
| their employees.
| judge2020 wrote:
| https://sso.tax/
| flappyeagle wrote:
| This website is... plain wrong? The first company listed is
| Airtable, which offers google SSO on their _free_ tier.
| n4jm4 wrote:
| Reuse the session across applications. Min 24 hour expiration.
| The more times the user is forced to reauth, the higher the
| chances of a keylogger or over the shoulder attack successfully
| retrieving passwords. Also, more time is spent relogging into
| apps rather than getting things done.
___________________________________________________________________
(page generated 2022-06-20 23:01 UTC)