Why saml instead of OIDC?
In my experience, SAML seems to be a more universally used option.
Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
31–40 of 101 posts
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#32These 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
I'm referring to the opposite side of the problem. Even if you use Okta, if you want to integrate with company XYZ using SSO, no amount of Okta spend will save you.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#33I'm writing my first custom policy for MS's B2C identity provider, and it's a painful process.
Making authentication and SSO more painless will actually make the world a better place -- apps will become more secure, people will be less frustrated when they use them, etc., and people like me will have less stress in their lives.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#34These 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…
I've written one of these 204-page PDFs before (I think it was more like 20 pages though). The IDPs don't exactly make it easy on their customers to set this stuff up, and the burden ends up on the SP (i.e. you) to document to folks how to use their own IDP.
Incidentally we just shipped something for this. Rather than having to make a 204-page PDF, you can go into SSOReady, generate a setup URL, and give it to customers. Customers can visit that URL and they get a self-serve UI for configuring their SAML connection to your product.
https://ssoready.com/docs/idp-configuration/enabling-self-se...
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#35This looks great! I am curious about "We expect to monetize in the future by building extra features that serve large companies with complex needs". During the YC application process, was this enough to be accepted? I wonder how much emphasis they put in the business model in order to fund you. I wish you success!
Candidly, we were working on other projects when accepted to YC. We wanted to build data cleaning software with LLMs, before we realized no one really cared about messy data. Part of the reason we're comfortable with a generous free offering is the basic truth that helping SaaS companies support SAML logins ... just isn't an enormous market. We need to make money on other products anyway. *Monetizing extra features*…
> We wanted to build data cleaning software with LLMs, before we realized no one really cared about messy data.
This sounds like a good problem to solve with LLMs, and honestly I'm a bit surprised to hear that nobody cared about data being of poor quality. Care to elaborate a little bit?
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#36Earlier quoted context omitted.
> 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
Sure, that's an option.
Also an option, when choosing what to use right at the startt, is being careful about using an open source solution from a for-profit startup, and evaluating all your other options, taking into account that it may not remain open source, and if it doesn't, what place it has in your business, how hard it would be to switch then, etc.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#37Earlier quoted context omitted.
Candidly, we were working on other projects when accepted to YC. We wanted to build data cleaning software with LLMs, before we realized no one really cared about messy data. Part of the reason we're comfortable with a generous free offering is the basic truth that helping SaaS companies support SAML logins ... just isn't an enormous market. We need to make money on other products anyway. *Monetizing extra features*…
> We wanted to build data cleaning software with LLMs, before we realized no one really cared about messy data. This sounds like a good problem to solve with LLMs, and honestly I'm a bit surprised to hear that nobody cared about data being of poor quality. Care to elaborate a little bit?
I should have been a little more careful in my phrasing. Certainly some number of people care about data quality. The motivation for the project came from my own personal experience -- it was a product that I really wanted.
Our positioning (e.g. principal use cases, target verticals, target persona) and timing were totally wrong. We tried to run top-down sales against relatively important data (e.g. sales forecasts). People often expressed an attitudinal interest in the product, but it was very hard to motivate people actually to use the product seriously. Category creation and behavior change are really hard.
If I were trying to sell an LLM data cleaning product now, I'd focus on more technical buyers, someone more like a data engineer than a strong spreadsheet worker. And I'd try to drive bottoms-up, low ACV adoption first.
Doing the post-mortem justice would probably require a long blog post.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#38Kudos on releasing open source, and on launching an easy-to-use service.
Side thought: If this takes off as a popular quality implementation, an additional effect might might be that it's easier for vendors of other services to integrate with users of your software. Maybe there's some way you can profit from that savings or reduced sales friction. (I've had to implement several F500 SSO integrations from scratch, because they were doing bespoke/custom things, and even "SAML" doesn't necessarily interoperate, but software like yours might out of the box.)
Question: For the free hosted SSO, how well are you going to be able to secure that, so that your customers aren't compromised through you?
Question: Will the free tier SSO have uptime guarantees, since it'll be a single point of failure for all your customers? For startups that decide they'd like it hosted for them, but need an SLA, do you expect to be able to provide that at a price doable by startups? (Will a cloud provider pick up those customers using your software?)
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#39Well if they could do Apple MDM (=login on Macbooks), that would be awesome. I don’t get why it’s expensive, apart from taking money where there is.
Re: Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source
#40Nice — we implemented SSO integrations at my last company, and only did OIDC2 because SAML just seemed like a pain in the ass.
Not sure if this is still true, but for a while Okta would not allow you to use OIDC for SSO in an Okta integration that used SCIM — you had to use SAML for SSO. We basically worked around this by having two separate Okta integrations — one for SSO and one for SCIM. It was always a pain to explain this to our customer’s IT departments, but no one ever balked at it, so we never had to implement SAML.