Why isn't SAML SSO mandated (either literally or my convention)?
Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :)
I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care.
If many small / price sensitive companies really wanted SAML SSO from their vendors -- if there were really meaningful demand -- I imagine we'd see more pricing plans with SAML SSO bundled into entry level tiers.
As for mandates, this is a challenging ethical question. I don't think it's necessarily obvious in all cases that some institution should impose safety regulations upon us.
There's clearly some set of risks we accept, and some set of risks we don't accept. And we all draw the line in different places.
This is pretty obviously true. Not many of us worry about objects randomly falling off buildings. We don't all wear helmets all the time. It's certainly a risk, but do we really care?
I think the revealed preference from many software buyers is basically ... no, they don't care about having the security benefits of SSO.
I favor regulation on this, even though it's probably not necessary in every case, simply because I don't see any other way to break this equilibrium.
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I specifically meant that the previous commenter made me think of mandates.
I run a company that makes SAML SSO software. I've thought quite extensively about SAML SSO. See:
https://news.ycombinator.com/item?id=41036982
Addendum: I have a very strongly vested interest in more people using SSO. I literally spend my time trying to convince developers to set it up!
This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
>>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power.
And this is a fatally flawed analogy that renders it useless. The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Neither of these quotes support this position.
> The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer.
As to this - is there any actual empirical evidence that missing SSO meaningfully weakens security for small businesses, which are the ones that would actually care about forking over the extra for the enterprise tier? That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage. I find it unlikely that missing SSO matters that much from them, and I'd like to see empirical evidence otherwise.
Also, there's nothing wrong for charging different amounts for different levels of security, assuming that that cost translates into actual effort (which it does for SSO). Normal people pay small amounts of money for physical door locks that are woefully insecure - the proposition that lock manufacturers should make their industrial and home locks cost the same would be pretty ludicrous.
Appeal to authority. Meaningless.
All I was pointing out with those links is that literally Googling the term "SSO tax" and clicking the first link at least hints at some of the reasoning behind people making an issue of this. The fact that TFA doesn't address any of the actual concerns people have in any meaningful way makes it of incredibly limited usefulness in the overall discussion.
> The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Then charge for the support. The issue is that the only way to purchase a core security feature is bundled in with other features that the user doesn't necessarily want or need, very often at several multiples of the price for the features they do want.
>That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage.
This is working from the faulty assumption that potential customers only exist in a binary between the nebulous "enterprise" and "small business with barely any IT competency."
I live in the enterprise healthcare world. It's routine for us to consider software purchases at the departmental level to fill a specific need for a particular team. We have hard requirements for SSO. Some of it's driven by internal policy, some of it's driven by auditors increasingly demanding MFA everywhere.
I have personally killed deals over this exact issue on a more routine basis than I'd like. Department head thinks cost is going to be Y. Cost is actually 5-10Y because the only way to purchase SSO support is via an "enterprise" bundle with additional features they don't need and an inflated minimum seat-count buy. We'd happily pay some middle ground for SSO support, but the option to buy it doesn't exist.
The issue is not charging for things that have support costs; it's forcing a customer into drastically higher pricing tiers under the assumption that running SSO is a signal that a potential customer has a super sophisticated environment and bottomless pockets. That was the world of 15 years ago, sure, but it's not today.
The reality is we live in a world where there are increasingly strict security requirements in many industries and any business paying, e.g., $6/user/month for Microsoft 365 has SSO available as an option.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts. The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.
In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.
These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.
This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.
SAML isn't exactly the best choice here. It's very SOAP-y; that's like being in 2005 and mandating everyone use SOAP+RPC for interopability.
I used OIDC for my internal sites to integrate with our corporate SSO provider. Why would I need to use saml instead?
I wouldn't celebrate taking those cars away from people.
As far as the older cars without those features allowing them to age out has almost entirely worked.