zlacker

[return to "Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source"]
1. whartu+69[view] [source] 2024-07-30 16:59:38
>>ucario+(OP)
I can only wish you good luck. I mean it, best of luck to you all.

We wrote our own IdP back in the day. It was a cool project, Single Sign On, Single Sign OUT, User provisioning, just all sorts of stuff.

And it worked! It's amazing when it works, it's just like magic. You giggle when it works.

We did all sorts of integrations. To random Service Providers, integrating with other IdPs, etc. Some were really cool. Great functionality.

But I simply float this one caveat.

It was never "painless". Ever. It was always pulling teeth.

The dark truth is you can have the best IdP in the world, but everyone on the other side of the conversation is a black box. You get a lot of payloads simply shipped into the void, never to be seen again, consumed for some unknown reason.

Add to that the very often the people you're integrating with have no concept of SAML, its workflows, its payloads, etc., much less the capabilities of their own stack in regards to SAML. So you get to train them (and learn about their system) at the same time.

We never had real problems with signing and formatting and such that folks worry about. It was mostly just diagnosing black boxes more than anything, the endless black hole of cert management, etc.

So, good luck! I hope it works for you! It's a neat space to play.

◧◩
2. deatha+Jp[view] [source] 2024-07-30 18:22:33
>>whartu+69
> Add to that the very often the people you're integrating with have no concept of SAML, its workflows, its payloads, etc., much less the capabilities of their own stack in regards to SAML. So you get to train them (and learn about their system) at the same time.

This is true of a great many protocols, unfortunately. I've seen this with IPSec, HL7v2, … CSV.

IPSec was perhaps the most … scarring. Always sort of feeling your stomach turn to acid as you wonder to yourself "will we be able to integrate with the other end?" when you're trying to work with "network engineers" who cannot establish a TCP connection to test if the VPN tunnel is alive. And yeah, it's learn their system as fast as humanly possible to then determine if their setup is correct, and to hunt where the inevitable integration problems lie. (…in the firewall. It was always a firewall, somewhere.) Why other systems feel the need to take the standard terms and reinvent new words for them is beyond me to this day. "Enterprise" junk is particularly guilty of it. Most of the learning is just building a mental Rosetta stone of what does the other end's "appliance" call this term or that term.

[go to top]