| ▲ | ocdtrekkie 4 hours ago |
| Eh, if you don't have SAML support, I can find a product that does. Not a problem. \o/ (Or to be more clear, it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with. You either work with what we use or you are not viable as a product for our need. It's kinda simple. I would expect someone whose authentication was OIDC-based to be similarly dismissive if you told them you only would do SAML.) |
|
| ▲ | jeltz 3 hours ago | parent | next [-] |
| That mindset is indicative of security theatre to me. But as security theatre is common in entrprise IT that does not surprise me. |
| |
| ▲ | foltik an hour ago | parent | next [-] | | > I'm an IT consultant working for a private company 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. | |
| ▲ | jeroenhd 2 hours ago | parent | prev [-] | | Security is part of the story (beats keep track of different usernames+passwords for every tool), but convenience is also a major factor. 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. |
|
|
| ▲ | eximius 3 hours ago | parent | prev | next [-] |
| This is only a reasonable stance at the very surface level. 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. |
| |
| ▲ | beachy 3 hours ago | parent | next [-] | | It seems fair to me. 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. | | |
| ▲ | ocdtrekkie 3 hours ago | parent [-] | | As a SaaS customer, interacting with SaaS vendors tends to entail: 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. | | |
| ▲ | antonymoose 3 hours ago | parent [-] | | > 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.) 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! | | |
|
| |
| ▲ | bigstrat2003 3 hours ago | parent | prev [-] | | > A potential customer making bad choices does not obligate a business to make bad choices for their business. 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. |
|
|
| ▲ | iamjake648 3 hours ago | parent | prev | next [-] |
| Realistically, what modern IdP supports SAML but not OIDC though? To me, it seems like more of a case of 'I know and am comfortable with SAML, why learn something new?'. |
|
| ▲ | clhodapp 3 hours ago | parent | prev | next [-] |
| Honestly, it's an addressable market versus development cost question... How many clients will you lose if you support OIDC but not SAML? Does the delta justify carrying a SAML implementation? If so, do it. But the post is still correct that SAML is a fractal of bad design either way. And it's good to say this openly, and to run this calculus each time you are considering a new SAML implementation. |
|
| ▲ | badgersnake 3 hours ago | parent | prev | next [-] |
| We took that exact stance, and it’s largely been a success. Most people asking for SAML can actually do OIDC and are happy to do so. |
|
| ▲ | TZubiri 2 hours ago | parent | prev | next [-] |
| It's a matter of perspective yes. 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. |
|
| ▲ | tomjen3 3 hours ago | parent | prev [-] |
| You use Entra. Entra can do jwt’s. Saml is just not reasonable in our modern security environment. |
| |
