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.)
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.
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.
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.
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.
> 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!
The total cost to employee a Senior Software Engineer, and I mean a real one, not some kid with three years experience, including benefits, taxes, etc. easily gets up to 200K in a normal city at a non-FAANG job.
Im sorry if your UK salaries are much smaller, but I’m not P Diddy taking anyone’s piss out here m8!
Not denying that, but if its a full time job for that person to monitor the keycloak machines for a typical SaaS vendor then something's wrong at mill cobber (may have used that wrongly as not English)
> 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.
Entra is just allowing the Chinese government in your environment. Why bother with authentication at all?
<a href="https://www.war.gov/News/News-Stories/Article/Article/4288992/pentagon-halts-chinese-coders-affecting-dod-cloud-systems/" rel="nofollow">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.)
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.
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?'.
Everything can stack onto everything else, sure. Most people's SAML IdPs are... synced from their LDAP. =) But in particular SAML provides an SSO experience where signing in once in the browser will allow you to go to various integrated sites and apps without signing in again. That flow is not dissimilar from OIDC but it is separate. So I can have 10 apps with SAML and 1 with OIDC, and the OIDC one is gonna be an odd duck.
And a key aspect that modern setups often forget: Every single different UI your users see makes them easier to phish. One of the reasons Entra is so easily phishable is Microsoft uses like 500 different domains for their cloud platform, so the one in the mix they don't actually own isn't obvious to the average user.
If a company said "you must support DES," I would expect that their cybersecurity insurance provider would start asking them some questions, and if they became indignant that no one would do so, I would expect them to be publicly mocked.
There is one valid excuse for why you must have support for an outdated protocol: embedded / air-gapped systems. For anything else, just admit that you don't want to make the change. That's a business decision, nothing else.
> 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 think HN would do really well if we took this in the more general sense (any product).
If the customer is asking really hard for something, maybe you should just take their money and move on. Forcing 100% of your customers to adopt or endure weird technological ideologies is not a path to happiness.
If SAML is taking you so much effort to implement that its complicating your sales & development process, you are either using the wrong tools or the wrong developers. It should not be this difficult if you make a genuine effort.
I am often reminded of this particular meme template when it comes to HN and the customer: <a href="https://knowyourmeme.com/memes/baton-roue" rel="nofollow">https://knowyourmeme.com/memes/baton-roue
Oh boy. There were (and are) hordes of enterprises requiring us to support SAML and were quite amazed to know Entra and all big auth providers perfectly support OIDC.
ocdtrekkie · · focus · HN ↗
(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 · · focus · HN ↗
jeroenhd · · focus · HN ↗
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.
foltik · · focus · HN ↗
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.
eximius · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
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 · · focus · HN ↗
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!
beachy · · focus · HN ↗
antonymoose · · focus · HN ↗
beachy · · focus · HN ↗
antonymoose · · focus · HN ↗
Im sorry if your UK salaries are much smaller, but I’m not P Diddy taking anyone’s piss out here m8!
beachy · · focus · HN ↗
bigstrat2003 · · focus · HN ↗
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.
tomjen3 · · focus · HN ↗
Saml is just not reasonable in our modern security environment.
ocdtrekkie · · focus · HN ↗
<a href="https://www.war.gov/News/News-Stories/Article/Article/4288992/pentagon-halts-chinese-coders-affecting-dod-cloud-systems/" rel="nofollow">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.)
clhodapp · · focus · HN ↗
iamjake648 · · focus · HN ↗
ocdtrekkie · · focus · HN ↗
And a key aspect that modern setups often forget: Every single different UI your users see makes them easier to phish. One of the reasons Entra is so easily phishable is Microsoft uses like 500 different domains for their cloud platform, so the one in the mix they don't actually own isn't obvious to the average user.
badgersnake · · focus · HN ↗
TZubiri · · focus · HN ↗
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.
sgarland · · focus · HN ↗
There is one valid excuse for why you must have support for an outdated protocol: embedded / air-gapped systems. For anything else, just admit that you don't want to make the change. That's a business decision, nothing else.
ocdtrekkie · · focus · HN ↗
bob1029 · · focus · HN ↗
I think HN would do really well if we took this in the more general sense (any product).
If the customer is asking really hard for something, maybe you should just take their money and move on. Forcing 100% of your customers to adopt or endure weird technological ideologies is not a path to happiness.
If SAML is taking you so much effort to implement that its complicating your sales & development process, you are either using the wrong tools or the wrong developers. It should not be this difficult if you make a genuine effort.
I am often reminded of this particular meme template when it comes to HN and the customer: <a href="https://knowyourmeme.com/memes/baton-roue" rel="nofollow">https://knowyourmeme.com/memes/baton-roue
bvrmn · · focus · HN ↗