Why focus on SAML rather than OIDC2?
OIDC2 is the better protocol, don't get me wrong. But lots of companies run on SAML, and it's the thing customers explicitly ask for.
Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
21–30 of 101 posts
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#22This looks very cool! Having implemented SAML before, it was definitely a pain and your tooling looks painless! That said, the pricing worries me a bit. This is a tool we'd have to build on top of . Which means that if it disappears later because you went out of business (or just changed your pricing in some way that hosed us), we'd have a whole big, unexpected engineering project to rewrite our SSO. And given that y…
I totally understand your concern. It's very valid, and we hear it a lot. I may not successfully convince you of the commercial logic here, but we are making a calculated bet that a generous free offering serves our long-term interests. We're betting that this product will establish our credibility with developers and result in efficient distribution in the future. It's a pretty common commercial open source playbook…
> It's a pretty common commercial open source playbook not to monetize in the early days.
Right, but what has become common, if successful at cornering market share, is then changing the license to something open-source-ish and charging money for what used to be free. Sometimes a lot of money.
Many swore they'd never do it. Many probably even meant it at first.
So, it's a concern for sure.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#23Earlier quoted context omitted.
I totally understand your concern. It's very valid, and we hear it a lot. I may not successfully convince you of the commercial logic here, but we are making a calculated bet that a generous free offering serves our long-term interests. We're betting that this product will establish our credibility with developers and result in efficient distribution in the future. It's a pretty common commercial open source playbook…
> It's a pretty common commercial open source playbook not to monetize in the early days. Right, but what has become common, if successful at cornering market share, is then changing the license to something open-source-ish and charging money for what used to be free. Sometimes a lot of money. Many swore they'd never do it. Many probably even meant it at first. So, it's a concern for sure.
So then fork it and continue like that.
At least you have the option as opposed to some proprietary solution
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#24I've always heard YC startups are supposed to immediately generate revenue (heard this from many YC founders). How do you immediately monetize a new FOSS project?
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#25I've always heard YC startups are supposed to immediately generate revenue (heard this from many YC founders). How do you immediately monetize a new FOSS project?
In nearly all cases, I think companies should charge money for products.
I even wrote a blog post about this years ago that was popular on Hacker News: https://cranberryblog.substack.com/p/a-simple-argument-for-i...
Sometimes you have to defy best practices :)
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#26Why saml instead of OIDC?
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#27These days, I feel like this biggest obstacle with SAML is integrating with SaaS products. I've been in many situations where it requires back and forth emails to a support team. I've been handed a literal 204 page PDF on integrating with one vendor's SSO setup (the entire document was literally just for their SSO integration, nothing else). Attribute mappings are still a mess. It's wild how poor the experience still is.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#28I 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. Grea…
Saying
> And it worked! It's amazing when it works, it's just like magic. You giggle when it works.
And then this
> It was never "painless". Ever. It was always pulling teeth.
Even with a caveat in between, is misleading. I get you’re probably trying to generate revenue, and more power to you. I’d re-work that phrasing next time.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#29I 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. Grea…
> 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.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#30These days, I feel like this biggest obstacle with SAML is integrating with SaaS products. I've been in many situations where it requires back and forth emails to a support team. I've been handed a literal 204 page PDF on integrating with one vendor's SSO setup (the entire document was literally just for their SSO integration, nothing else). Attribute mappings are still a mess. It's wild how poor the experience still…
OKTA does a pretty great job, if you want to spend $2X,XXX per year