3 ms·

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

by floren 2y ago

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.

seszett 2y ago
> 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.
jiggawatts 2y ago
Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. 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!)
- 7bit 2y ago
  > Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.
  - jiggawatts 2y ago
    To be fair, SAML 1.0 was much worse than SAML 2.0 at interoperability, but there are still "profiles" in 2.0: https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf https://docs.oasis-open.org/security/saml/v2.0/saml-profiles... Even within the same profile, I've seen some major incompatibilities. For example, some Microsoft products interpret XML signing ever so slightly differently to many other libraries, breaking the protocol. (From what I could tell, MS was interpreting the standard correctly, others weren't, they were just testing against each other.) The biggest gripe I have about SAML is that it's one of "those" committee-designed standards that has an inner-platform effect of using it's own custom extensibility model on top of the eXtensible Markup Language (XML). It's like the bad database schemas that have one table with three or four columns holding all data because the developers couldn't be bothered to learn SQL. So instead of just this: <claims> <name>John Smith</name> <email>john.smith@test.com</email> <claims> You have this monstrosity: <saml:AttributeStatement> <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname- format:basic"> <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> I was just troubleshooting SAML issues yesterday, and the library used for that is about 750 KB of compiled bytecode. The source must be over 2 MB, not including also heavyweight dependencies like XML, XML Schema, and XML Signing. For something as trivial as "send me a token with some attributes and a signature" it's way, waaaaay overcooked.

by floren 2y ago

seszett 2y ago

> 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.

jiggawatts 2y ago

Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. 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!)

7bit 2y ago
> Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.
- jiggawatts 2y ago
  To be fair, SAML 1.0 was much worse than SAML 2.0 at interoperability, but there are still "profiles" in 2.0: https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf https://docs.oasis-open.org/security/saml/v2.0/saml-profiles... Even within the same profile, I've seen some major incompatibilities. For example, some Microsoft products interpret XML signing ever so slightly differently to many other libraries, breaking the protocol. (From what I could tell, MS was interpreting the standard correctly, others weren't, they were just testing against each other.) The biggest gripe I have about SAML is that it's one of "those" committee-designed standards that has an inner-platform effect of using it's own custom extensibility model on top of the eXtensible Markup Language (XML). It's like the bad database schemas that have one table with three or four columns holding all data because the developers couldn't be bothered to learn SQL. So instead of just this: <claims> <name>John Smith</name> <email>john.smith@test.com</email> <claims> You have this monstrosity: <saml:AttributeStatement> <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname- format:basic"> <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> I was just troubleshooting SAML issues yesterday, and the library used for that is about 750 KB of compiled bytecode. The source must be over 2 MB, not including also heavyweight dependencies like XML, XML Schema, and XML Signing. For something as trivial as "send me a token with some attributes and a signature" it's way, waaaaay overcooked.