[HN Gopher] Launch HN: SSOReady (YC W24) - Making SAML SSO painl...
___________________________________________________________________
Launch HN: SSOReady (YC W24) - Making SAML SSO painless and open
source
Hey everyone, I'm Ulysse, CTO at SSOReady
(https://github.com/ssoready/ssoready). SSOReady is an open-source
(MIT) service that lets you implement SAML single sign-on without
ever touching SAML yourself. You just need to implement two API
endpoints: one to initiate SAML logins and another to receive
incoming SAML messages. And then you're pretty much done. Here's
me setting up SAML single sign-on in under a minute:
(https://www.youtube.com/watch?v=_HVtFkW8xCI). You can use our
service with whatever tech stack or programming language you
prefer. Earlier in my career, I worked on SAML authentication at
Segment. I've been pretty obsessed with SAML since then. In the
depths of the COVID pandemic, I even wrote an implementation of
SAML in Go to entertain myself (https://github.com/ucarion/saml).
Over the years, I've gotten really itchy to build better SAML
tooling. There just aren't a lot of great options out there. Almost
no one seems interested in making SAML easy for developers. Almost
no one seems interested in writing clear documentation. We're
hoping to change that with SSOReady. We've open-sourced our
codebase on an MIT license. You can do pretty much whatever you
want with the code. Fork us. Self-host us. We've also made the
product entirely free. Why free and open source? We're focused
solitarily on becoming developers' first choice for SAML SSO. If it
makes developers' lives easier, it works for us. We expect to
monetize in the future by building extra features that serve large
companies with complex needs. We don't see any point to being
secretive or squeezing dollars out of small companies. I'd be
thrilled if you gave the product a try, and I'd be really grateful
for any feedback on your experience. If you have any questions or
concerns, my cofounder Ned and I will stay active on this thread
throughout the day. You can also reach us directly at
founders@ssoready.com. (We really mean this! We want to hear from
you!)
Author : ucarion
Score : 184 points
Date : 2024-07-30 16:19 UTC (6 hours ago)
| ensemblehq wrote:
| Hi Ulysse, this is incredibly timely as we are looking at a more
| cost-effective alternative to WorkOS as we're building our
| enterprise data validation portal. Will give it a go and see how
| we make out - do you have any immediate instructions on
| integrating with Entra ID? Is it literally just the API endpoint
| that's needed?
| ned_at_codomain wrote:
| Hey! I'm Ned, the other cofounder at SSOReady.
|
| Yes, absolutely. The code you'll write will cover all IDPs. The
| variation from one IDP to another gets addressed in the
| configuration settings for each of your customers.
|
| For example, I put some documentation together specifically for
| Entra not too long ago here: https://ssoready.com/docs/idp-
| configuration/guides-for-commo...
|
| Does that get you what you need?
| ensemblehq wrote:
| Incredible. Yes perfect. Thanks Ned!
| e12e wrote:
| Neat! When i was wearing an Entra (AzureAD) admin hat, i
| would've really loved to get five-six lines of PowerShell
| that did the needed steps - rather than having to navigate
| the web UI labyrinth.
| grinich wrote:
| Hey there - I'm the founder of WorkOS :wave:
|
| We have automatic volume discounts for pay-as-you-go users, and
| even lower prices on annual plans or custom contracts. We also
| have free credits for early-stage companies. Feel free to send
| me a note if you'd like to chat: mg@workos.com
|
| Today hundreds of companies use WorkOS, including a ton of
| startups you probably know: https://workos.com/startups
| danenania wrote:
| This looks great! Any plans to add SCIM? SAML is good but one of
| the main reasons larger customers want SSO in my experience is to
| automate deprovisioning--they want one-click access removal from
| all apps when an employee leaves the company. And for that you
| need SCIM.
|
| If you had SAML plus SCIM (or even just a small subset of SCIM) I
| think it could be a no-brainer. Other services that offer it are
| closed-source and absurdly expensive, and DIY is a big pain.
| ucarion wrote:
| Yeah SCIM is coming up. Auto-deprovisioning and stuff related
| to seat management are the big motivators I've seen.
|
| Honestly IETF did a pretty good job with SCIM itself. It's not
| wacky in the way SAML is at all. In my experience the hardest
| part about integrating SCIM is setting up all the IDP-specific
| configuration around it. Like with SAML, it's a situation where
| Okta, Microsoft, OneLogin all have totally different terms for
| the exact same thing.
|
| One thing I'm pretty excited about is that our SCIM support
| will also include a button where you can generate a setup link
| that you give to your customer. From that setup link they can
| self-serve configure their SAML+SCIM configuration.
|
| We have that working for SAML right now, and it's nice because
| it means you don't need to write IDP-specific documentation
| walking customers through each product's weird terminology and
| quirky UI.
| e12e wrote:
| Is OIDC2 also comming? While simpler - a similar "self-help"
| workflow that helped with all big three SAML, SCIM and OIDC2
| - with self-hosting would be marvelous.
| oliverx0 wrote:
| This 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!
| ned_at_codomain wrote:
| 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* pertains to the SAML product that
| we offer now, but we'll also roll out other products.
|
| The long-term ambition here is that we build a company
| resembling Auth0, but open source and more developer-friendly.
| candiddevmike wrote:
| Lots of YC LLM pivots lately...
| SoftTalker wrote:
| Sounds a lot like Spolsky's "commoditize your complements"
| kjok wrote:
| > 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?
| ned_at_codomain wrote:
| 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.
| fishtoaster wrote:
| This 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 you're giving a hosted product away for free, it
| seems pretty likely that you _will_ either eventually go out of
| business or change your pricing.
|
| I know it sounds silly, but as someone who'll probably have to
| add SSO to my current project in the next 6-12 months, I'd be a
| lot more comfortable betting on you if you had a sustainable-
| sounding paid tier other than "free for now" and "idk email us."
| It'd certainly make it easier to pitch to the rest of my team. :)
| ned_at_codomain wrote:
| 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
| not to monetize in the early days.
|
| Thankfully, some subset of venture capitalists will happily
| underwrite companies with popular commercial open source
| products.
|
| Please bear in mind that we're an early stage company. We will
| build more depth into the existing product, and we'll offer new
| products over time. We will charge for those new features / new
| products. It may take years to earn meaningful revenue, let
| alone generate cash flow, and we're fine with that.
| jrochkind1 wrote:
| > 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.
| crngefest wrote:
| So then fork it and continue like that. At least you have
| the option as opposed to some proprietary solution
| jrochkind1 wrote:
| 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.
| asmor wrote:
| The SSO tax[1] already exists. It sucks: Gating security
| features, best practices and automation when someone is already
| your customer is terrible. But it's the status quo, and in that
| status quo people that need SAML in their company probably
| should pay at least half as much as they pay for this single
| feature in a single one of their SaaS apps.
|
| [1]: https://sso.tax/
| mightybalthazar wrote:
| 100%. One thing I'd add since SAML is the gateway to your
| application, I don't like the idea of expecting premium support
| for a free product if I don't want to buy things this company
| does charge for later on. Don't forget one option is "call the
| founder"
| whartung wrote:
| 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.
| dgfitz wrote:
| 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.
| deathanatos wrote:
| > _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.
| doubled112 wrote:
| SAML and IPsec both make my eye twitch, and I too have
| struggled where the person on the other end has no idea.
|
| One of my favourites was the time I was trying to figure out
| a SAML integration with a client, and before the person on
| the client's "SSO team" could figure it out, I installed a
| demo of their SSO solution, integrated with my own dev AD,
| and found the checkbox.
|
| Yay enterprise! The Q in enterprise is for quality.
| bearjaws wrote:
| HL7v2, the protocol of "we just put all the data in this one
| random field".
| fhub wrote:
| As a base64'd pdf
| trhway wrote:
| > it's just like magic. You giggle when it works.
|
| From frontend and middleware to the backend DB user identity
| travels as SAML, on the DB switch to Kerberos - s4u2 self on
| that user identity - and get proxy ticket to the data
| virtualization server where get another Kerberos s4u2 proxy to
| the login server which gives you a x509 certificate to login to
| the required data source which is then accessed by the DB
| through that virtualization server under that original frontend
| user identity.
| candiddevmike wrote:
| Why would folks use this instead of an existing library for their
| language de jour?
|
| You have a python SDK, but something like
| https://github.com/SAML-Toolkits is popular, well maintained, and
| fully featured. Why use yours?
| ucarion wrote:
| Most folks will read that README and conclude SAML isn't going
| to happen for them today.
|
| Take any language's biggest SAML implementation, and it's the
| same story of a library with some epic README covering dozens
| of public methods you may or may not need to use. People can't
| make heads or tails of this stuff.
|
| Clarity and simplicity are the precursors to security. I'm
| pretty obsessed with making SAML clear and simple for folks.
| candiddevmike wrote:
| Cynically, why not open a PR to improve the README...
|
| I think you'll have better luck on the consulting side with
| this idea than the product side. There are so many SAML
| implementations running the gamut from plug and play like
| Auth0 to DIY toolboxes that I don't think "simpler" is a good
| enough value add here.
| ned_at_codomain wrote:
| You might turn out to be right! Only time will tell.
| jrozner wrote:
| Why focus on SAML rather than OIDC2?
| NoxiousPluK wrote:
| I was wondering the same. In my corner of IT, everyone is
| ditching SAML as 'outdated' over OIDC2 (usually against Azure).
| It's pretty painless in comparison and seems to require less
| maintenance - even tho I know the SAML2 spec well.
| ucarion wrote:
| 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.
| henning wrote:
| I'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?
| ned_at_codomain wrote:
| 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 :)
| motoboi wrote:
| Why saml instead of OIDC?
| havefunbesafe wrote:
| In my experience, SAML seems to be a more universally used
| option.
| mightybalthazar wrote:
| Your app isn't ready to support 'enterprise' until you can do
| both - you'll need to use this product + roll your own OIDC
| or find another service like this for OIDC. Customers will
| expect you to be agnostic and bring whichever they prefer.
| bilalq wrote:
| These 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.
| havefunbesafe wrote:
| OKTA does a pretty great job, if you want to spend $2X,XXX per
| year
| bilalq wrote:
| 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.
| ucarion wrote:
| 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...
| mwcampbell wrote:
| Wow. My company previously did an SSO implementation for our
| SaaS where we ran Shibboleth SP behind Apache just for SSO,
| with a little Python web app using mod_wsgi to call back to
| the main web app after SSO was completed. But for the
| customers that we've onboarded to SSO so far, we had to
| contract with a SAML expert to work with the customer to set
| it up. This self-service setup might be enough to make it
| worth our while to migrate to SSOReady.
| SkyPuncher wrote:
| SSO support took up well over 50% of our engineering teams
| customer support time.
|
| One of the biggest challenges is our users tended to need to
| pull in a different department, that actually owned the SSO
| system. They had little incentive to hustle to get things to
| work, so there's tickets would often drag on for ages.
|
| We'd loom bad because we'd need certain information from our
| customer.
| astrashe2 wrote:
| I'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.
| neilv wrote:
| Kudos 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?)
| ucarion wrote:
| > 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?
|
| Yeah, this is super important. No short answer here, it's just
| about doing the work and getting it right.
|
| We're working with Oneleet for our SOC2 stuff (which we all
| know is largely theater) but also pretty thorough pentesting. I
| can email you their findings.
|
| The reality is we're one of those companies that need to get
| this stuff right.
|
| > 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?
|
| Our plan is to work out agreements on a case-by-case basis.
| It'd depend on exactly what you need. We take guarantees pretty
| seriously, so we're careful about what we promise.
|
| We're not a services business. We don't want to make money off
| of "premium support". There is a modest price tag if you want
| an SLA.
|
| > (Will a cloud provider pick up those customers using your
| software?)
|
| Would you mind rephrasing?
| neilv wrote:
| Thanks. Regarding "Will a cloud provider pick up those
| customers using your software?", I was wondering whether
| there might be a situation in which there was a category of
| service customers you'd like to have, but that a cloud
| provider hosts your software without you otherwise involved.
|
| https://en.wikipedia.org/wiki/Elasticsearch#Licensing_change.
| ..
| ucarion wrote:
| I think the reality is that the category of software we're
| open-sourcing isn't very big. We're gonna make our money
| doing other things, not all of which will be open-source.
| eastbound wrote:
| Well 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.
| mikeocool wrote:
| Nice -- 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.
| paulclark wrote:
| This is a huge pain point for many businesses. You're solving a
| real problem. Kudos!
| mightybalthazar wrote:
| What happens if my enterprise custies need support because they
| can't log in and I need support? GitHub Issue? email?
| ucarion wrote:
| My personal phone number and email is in the sidebar of
| app.ssoready.com for this exact reason.
| ceejayoz wrote:
| That's kind of you, but highly unlikely to be scalable.
| PaulMest wrote:
| Congrats on the launch! How does this compare to BoxyHQ's SAML
| Jackson [1]?
|
| [1]: https://github.com/boxyhq/jackson
| ned_at_codomain wrote:
| We think BoxyHQ does a nice job.
|
| We prefer our approach for basically two reasons:
|
| 1. BoxyHQ wants you to do SAML-over-OAuth. We support this --
| especially for NextAuth compatibility. But we don't think it's
| always helpful.
|
| 2. We think our service is easier to use. We most commonly hear
| complaints from users/customers about complexity, so we try
| really hard to make SAML obvious and simple. Ultimately, it's
| up to you whether we meet that bar.
| bks wrote:
| Is this a competitor to workos.com ? (we use them to connect
| customers to our apps)
| ned_at_codomain wrote:
| Yes. LMK any thoughts on how we compare. Eager to see where we
| can improve.
| bks wrote:
| Sorry just read this in your repo "You can think of us as an
| open source alternative to products like Auth0 or WorkOS."
| 77soccer wrote:
| Best of luck seems interesting
| hamasho wrote:
| I once had to implement an authentication feature for a Chrome
| extension through Cognito with Google Workspace accounts via
| OAuth2 or MS accounts via SAML as IdPs. That made me want to die.
| Just understanding what I want to do or have to do was
| unbelievably hard, and probably I still don't understand what I
| did honestly.
| xenophonf wrote:
| SSOReady doesn't appear to support multilateral identity
| federation, which makes this DOA as far as I'm concerned.
|
| I don't see how a proprietary authentication proxy atop a partial
| implementation of a SAML service provider addresses problems with
| enterprise SSO, which I'll wholeheartedly agree is just too
| goddamn hard.
|
| The open source community doesn't need yet another open core
| project, for that matter.
| mooreds wrote:
| Congrats on launching! SAML is going to be around forever (even
| though the stadnard is no longer being updated[0]) so it's good
| for folks to have more options.
|
| 0: https://lists.oasis-open.org/archives/security-
| services/2023...
___________________________________________________________________
(page generated 2024-07-30 23:00 UTC)