This car with no seat belts, no airbags, and no ABS is just price discrimination! Strangely, no one seems interested in celebrating the implied discount for not having safety.
Wasn't it true that for a long time that cheaper cars were just less safe than more expensive cars?
An admittedly wandering defense of the SSO tax
71–80 of 99 posts
Re: An admittedly wandering defense of the SSO tax
#72Earlier quoted context omitted.
I'm in the healthcare world. SSO is a hard requirement for us. There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop.…
Curious: Are SaaS sales unrepentant on pricing in these cases? I would think with a bit of spice on your side in procurement you could probably negotiate enterprise for a small premium over the middle tier. Knowing enough software sales people when given the choice between “Teams + $5/user/head” and “no sale at all” suddenly options open up. But maybe the people I know don’t support too much SSO stuff…
Either way, it's a surefire way for a potential vendor to automatically get lower priority from me as a potential buyer. Needing to haggle over what is, for us, a baseline security feature starts things off on the wrong foot.
Re: An admittedly wandering defense of the SSO tax
#73Earlier quoted context omitted.
I can identify basically three criticisms of my argument in your post. (1) That I assume companies never have market power. (2) That I suppose "market power" implies monopoly (3) That my example was cherry-picked. 1. I did no such thing. I explicitly acknowledged market power several times. 2. Again, not correct. I explicitly mentioned oligopoly (assuming that 'imperfect competition' wouldn't land). 3. Of course it w…
> I did no such thing. I explicitly acknowledged market power several times. Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier. > That I suppose "market power"…
"Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.
Any company that is tying to recoup the costs of building those features will charge the customers that use those features. The existence of a price differential between the 2 editions does not tell you whether they are overcharging.
Re: An admittedly wandering defense of the SSO tax
#74Earlier quoted context omitted.
> I did no such thing. I explicitly acknowledged market power several times. Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier. > That I suppose "market power"…
Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier. "Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging. Any compa…
"Price discrimination" is charging a higher price to one set of customers than another. The premise is that they're really getting the same thing but one of them has to pay more in exchange for either nothing or for something whose incremental underlying cost is far less than the incremental price increase, because the company devised a way to artificially segment the market.
If your argument is that the extra feature would actually cost that much even in a highly competitive market because it costs that much more to provide it, what you're really arguing is that they're not engaged in price discrimination.
Re: An admittedly wandering defense of the SSO tax
#75As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrating they were to deal with. People wouldn't follow the instructions. Microsoft/Google moved something in their portal and we didn't know so instructions were useless. Microsoft/Google would be having issues and we got tickets because they were still working un…
Yes! We don't charge for SSO, but thankfully we've only had our largest customers ask for it -- and every time it required significant back-and-forth to get it set up. Basically every time somebody comes in with a new IdP, I have to go stand up my own instance so I can figure out what weird combination of options will make it work, because I'm convinced nobody actually understands SAML.
That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time.
Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well.
I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
Re: An admittedly wandering defense of the SSO tax
#76Re: An admittedly wandering defense of the SSO tax
#77I was responsible for IT in a hypergrowth scale-up and I don’t like this article, it misrepresents the problem. The problem is, when you are big enough to set up SSO like Okta, you have to upgrade nearly all of your subscriptions in a short time to make use of it, suddenly resulting in a huge increase in the budget. So, let’s say the business goes from X to 2X in revenue and from X to almost 2X in staff (let’s assume…
Let’s not forget that the whole reason your company needs to upgrade all its subscriptions for SSO is so it can get a soc2 and offer its own high-priced enterprise plan (which is probably gated by SSO).
Re: An admittedly wandering defense of the SSO tax
#78This car with no seat belts, no airbags, and no ABS is just price discrimination! Strangely, no one seems interested in celebrating the implied discount for not having safety.
Re: An admittedly wandering defense of the SSO tax
#79As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrating they were to deal with. People wouldn't follow the instructions. Microsoft/Google moved something in their portal and we didn't know so instructions were useless. Microsoft/Google would be having issues and we got tickets because they were still working un…
Re: An admittedly wandering defense of the SSO tax
#80As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrating they were to deal with. People wouldn't follow the instructions. Microsoft/Google moved something in their portal and we didn't know so instructions were useless. Microsoft/Google would be having issues and we got tickets because they were still working un…
Yes! We don't charge for SSO, but thankfully we've only had our largest customers ask for it -- and every time it required significant back-and-forth to get it set up. Basically every time somebody comes in with a new IdP, I have to go stand up my own instance so I can figure out what weird combination of options will make it work, because I'm convinced nobody actually understands SAML.
PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock.
(Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)