1. "You either work with what we use" - so whatever organization you represent isn't capable of evaluating and shifting to more secure technologies?
2. "it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with" - you think companies that care about security should not care about integrating with flawed protocols?
A potential customer making bad choices does not obligate a business to make bad choices for their business.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
2. Having to yell at the SaaS vendor for routing the identity connection between two or three other identity providers in different various clouds because, you know "modern stuff". (A vendor I am working with has not less than five different accounts to access various parts of their infrastructure, none of which are connected at all. I assume people there listened to "switch to OIDC" nonsense, completed half the job, and now have OIDC sites and SAML sites forever.)
3. Discovering the SaaS vendor knows how Entra works, how Okta works, and how Google auth works, and having no idea how SAML works. Or OIDC or anything else for that matter.
4. Eventually finding an engineer far enough from the sales and implementation teams who can answer how the product actually works. :D This point is reached after a lot of yelling.
If I’m paying for at least one Senior to build and support this awful enterprise authentication pattern, I’m looking at around 200k per year in total cost - you damn well bet I’m billing you for it!
Indeed it does not. If you feel that strongly that you are willing to lose out on that customer, that's your right. But that does not mean the foregone customer is unreasonable for expecting you to work with their constraints in order to get their business.
Makes sense for GP locally, I guess, but globally we’re all worse off when nobody is motivated to break free from the path of least resistance.
Pretty much everything supports SAML. If you decide not to support one of the standard protocols for SSO, you'll lose out on customers. Your tool has to bring in a lot of benefit (and have no competition) to warrant upending a company's entire auth system for.
If you are a vendor, you should have SAML support unless you are early (and can only support 1 standard), or you are highly opinionated.
If you are a consumer instead, you will only be using one standard, so you HAVE to chose 1 and not the others.
Saml is just not reasonable in our modern security environment.
https://www.war.gov/News/News-Stories/Article/Article/428899... (Microsoft has solely discontinued this practice for the DoD tier. Commercial, GCC, and GCC High are still impacted because foreign labor is cheaper than the risk to your security.)