9 ms·

Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source

317 points by ucarion 2y ago

Hey everyone, I'm Ulysse, CTO at SSOReady (https://github.com/ssoready/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 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 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!)

danenania 2y ago
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 2y ago
  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 2y ago
    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.
    - Terretta 2y ago
      Agree OIDC (applicable in more use cases than people probably think) means neither side has to worry about SAML + SCIM. That's a win. Longer comment elsewhere in thread.
ensemblehq 2y ago
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?
- noleary 2y ago
  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-common-identity-providers/entra-formerly-azure-ad https://ssoready.com/docs/idp-configuration/guides-for-commo... Does that get you what you need?
  - ensemblehq 2y ago
    Incredible. Yes perfect. Thanks Ned!
  - e12e 2y ago
    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 2y ago
  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 https://workos.com/startups
  - Terretta 2y ago
oliverx0 2y ago
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!
- noleary 2y ago
  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.
  - Bencheng 2y ago
    > The long-term ambition here is that we build a company resembling Auth0, but open source and more developer-friendly. I have been working on this for a few years at github.com/authgear, and last few weeks were busy rolling out SAML support for a few Enterprise customers want it by Sep… Magically feels connected here :)
  - candiddevmike 2y ago
    Lots of YC LLM pivots lately...
  - SoftTalker 2y ago
    Sounds a lot like Spolsky's "commoditize your complements"
  - kjok 2y ago
    > 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?
fishtoaster 2y ago
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. :)
- noleary 2y ago
  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 2y ago
    > 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.
whartung 2y ago
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 2y ago
  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.
  - kzs0 2y ago
    You’re responding to a comment not the op? The commenter isn’t trying to make money just sharing an experience
- deathanatos 2y ago
  > 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.
candiddevmike 2y ago
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 https://github.com/SAML-Toolkits is popular, well maintained, and fully featured. Why use yours?
- ucarion 2y ago
  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 2y ago
    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.
    - noleary 2y ago
      You might turn out to be right! Only time will tell.
jrozner 2y ago
Why focus on SAML rather than OIDC2?
- NoxiousPluK 2y ago
  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 2y ago
  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 2y ago
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?
- noleary 2y ago
  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-investing-in https://cranberryblog.substack.com/p/a-simple-argument-for-i... Sometimes you have to defy best practices :)
motoboi 2y ago
Why saml instead of OIDC?
- havefunbesafe 2y ago
  In my experience, SAML seems to be a more universally used option.
  - mightybalthazar 2y ago
    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.
  - tptacek 2y ago
    SAML is the older protocol. It would be a design smell to see a new RP using it exclusively (people still implement SAML because enterprise customers have SAML IdPs).
bilalq 2y ago
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 2y ago
  OKTA does a pretty great job, if you want to spend $2X,XXX per year
  - bilalq 2y ago
    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.
    - rvnx 2y ago
      Supabase Auth ? https://supabase.com/docs/guides/auth/enterprise-sso/auth-sso-saml https://supabase.com/docs/guides/auth/enterprise-sso/auth-ss... Seems reasonably easy to use and a good platform to build a SaaS
- ucarion 2y ago
  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-service-configuration-for-your-customers https://ssoready.com/docs/idp-configuration/enabling-self-se...
astrashe2 2y ago
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.
- Terretta 2y ago
  > Making authentication and SSO more painless Arguably, OAUTH2 + OIDC does this. Firms like Atlassian have understood this: http://id.atlassian.com http://id.atlassian.com
neilv 2y ago
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 2y ago
  > 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 2y ago
    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_changes https://en.wikipedia.org/wiki/Elasticsearch#Licensing_change...
eastbound 2y ago
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 2y ago
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 2y ago
This is a huge pain point for many businesses. You're solving a real problem. Kudos!
mightybalthazar 2y ago
What happens if my enterprise custies need support because they can't log in and I need support? GitHub Issue? email?
- ucarion 2y ago
  My personal phone number and email is in the sidebar of app.ssoready.com for this exact reason.
  - ceejayoz 2y ago
    That's kind of you, but highly unlikely to be scalable.
    - ctrlGsysop 2y ago
      That’s ok at this point. They’re purposefully doing certain things that don’t scale.
PaulMest 2y ago
Congrats on the launch! How does this compare to BoxyHQ's SAML Jackson [1]? [1]: https://github.com/boxyhq/jackson https://github.com/boxyhq/jackson
- noleary 2y ago
  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.
  - crngefest 2y ago
    Would you mind elaborating a bit why you don’t think SAML-over-OAuth is a fits-all solution? To me it sounds like eating your cake (SAML) and having it too (not having to use SAML)
bks 2y ago
Is this a competitor to workos.com ? (we use them to connect customers to our apps)
- noleary 2y ago
  Yes. LMK any thoughts on how we compare. Eager to see where we can improve.
- bks 2y ago
  Sorry just read this in your repo "You can think of us as an open source alternative to products like Auth0 or WorkOS."
77soccer 2y ago
Best of luck seems interesting
your-username 2y ago
[flagged]
hamasho 2y ago
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 2y ago
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 2y ago
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/202308/msg00004.html https://lists.oasis-open.org/archives/security-services/2023...
- rvnx 2y ago
  Even the website certificate has expired apparently. net::ERR_CERT_DATE_INVALID Subject: lists.oasis-open.org Issuer: Sectigo RSA Domain Validation Secure Server CA Expires on: Jul 8, 2024 Current date: Jul 31, 2024
rvnx 2y ago
For info, the documentation for the project https://ssoready.com/docs https://ssoready.com/docs seems down: 502 ERROR The request could not be satisfied. CloudFront wasn't able to connect to the origin. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation. Generated by cloudfront (CloudFront) cf. http://www.site-shot.com/Lu-cUE7TEe-S-wJCrBEAAg http://www.site-shot.com/Lu-cUE7TEe-S-wJCrBEAAg or https://archive.is/wip/FhNfD https://archive.is/wip/FhNfD Otherwise the project looks really well done and by nice people.
- noleary 2y ago
  Thank you for letting us know! Are you still unable to use https://ssoready.com/docs https://ssoready.com/docs?
  - rvnx 2y ago
    All good now
madduci 2y ago
It sounds great. Any chance to get this ported to other major programming languages (Java, C++, Go, Rust, C#)?
- ucarion 2y ago
  The interface between your app and SSOReady is entirely over an HTTP API. We codegen SDKs for that HTTP API for Python and TypeScript, and will add more, but in the meantime the docs show you the curl you'd need to port: https://ssoready.com/docs/api-reference/saml/redeem-saml-access-code https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...
dqh 2y ago
Thank you for this, it’s sorely needed. One thing I didn’t see mention of is group membership. Is this / will this be part of the core offering? Being able to map IDP group membership to permissions within your SaaS is powerful, and in my experience highly desired by clients.
- ucarion 2y ago
  Yeah, we have this -- if you check out the docs for the endpoint where you accept a SAML login[1], there's an `attributes` (map<string, string>) that SSOReady returns to you. That contains the contents of the relevant SAML assertion's AttributeStatement. So if you're familiar with Okta's parlance, both "Attribute Statements" and "Group Attribute Statements" are returned to you in `attributes`. [1]: https://ssoready.com/docs/api-reference/saml/redeem-saml-access-code https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...
  - dqh 2y ago
    Magnificent, thank you!
manishsharan 2y ago
This may be offtopic but I am looking for SSO integration advise for integrating with multiple IdPs. I am building a SaaS application and wants to allow customers from different companies , each with their on IdP to be able to SSO into my application , which is a multi-tenant SaaS offering.
downsplat 2y ago
That's very interesting, at $WORK we recently added SAML support in a similar use case, as a SaaS SP integrating with the customer's IdP. At the time we looked at various open source implementations, and ended up using OneLogin's PHP library. We wanted a headless library, so we could store the SAML metadata in our main DB and implement the public endpoints on top of it. It did take a few days of googling and trying, but it wasn't really that complicated. Our core implementation adds up to just some 500 lines of PHP, most which is just glue code to fetch metadata from the db, put it in the format the library expects, and then do the basic thing of sending the user to the IdP, getting the response back, checking it, and mapping a couple of attribute names. The advantage of this approach is that we were able to made it self service for our users. User logs in as admin, goes to "SAML settings", inputs their metadata, clicks a button to test, and if it's good, clicks another to activate. We did get a few support requests from people who didn't know their own systems very well, but otherwise it's working smoothly.

317 points by ucarion 2y ago

danenania 2y ago

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 2y ago
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 2y ago
  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.
  - Terretta 2y ago
    Agree OIDC (applicable in more use cases than people probably think) means neither side has to worry about SAML + SCIM. That's a win. Longer comment elsewhere in thread.

ensemblehq 2y ago

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?

noleary 2y ago
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-common-identity-providers/entra-formerly-azure-ad https://ssoready.com/docs/idp-configuration/guides-for-commo... Does that get you what you need?
- ensemblehq 2y ago
  Incredible. Yes perfect. Thanks Ned!
- e12e 2y ago
  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 2y ago
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 https://workos.com/startups
- Terretta 2y ago

oliverx0 2y ago

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!

noleary 2y ago
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.
- Bencheng 2y ago
  > The long-term ambition here is that we build a company resembling Auth0, but open source and more developer-friendly. I have been working on this for a few years at github.com/authgear, and last few weeks were busy rolling out SAML support for a few Enterprise customers want it by Sep… Magically feels connected here :)
- candiddevmike 2y ago
  Lots of YC LLM pivots lately...
- SoftTalker 2y ago
  Sounds a lot like Spolsky's "commoditize your complements"
- kjok 2y ago
  > 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?

fishtoaster 2y ago

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

noleary 2y ago
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 2y ago
  > 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.

whartung 2y ago

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 2y ago
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.
- kzs0 2y ago
  You’re responding to a comment not the op? The commenter isn’t trying to make money just sharing an experience
deathanatos 2y ago
> 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.

candiddevmike 2y ago

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 https://github.com/SAML-Toolkits is popular, well maintained, and fully featured. Why use yours?

ucarion 2y ago
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 2y ago
  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.
  - noleary 2y ago
    You might turn out to be right! Only time will tell.

jrozner 2y ago

Why focus on SAML rather than OIDC2?

NoxiousPluK 2y ago
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 2y ago
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 2y ago

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?

noleary 2y ago
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-investing-in https://cranberryblog.substack.com/p/a-simple-argument-for-i... Sometimes you have to defy best practices :)

motoboi 2y ago

Why saml instead of OIDC?

havefunbesafe 2y ago
In my experience, SAML seems to be a more universally used option.
- mightybalthazar 2y ago
  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.
- tptacek 2y ago
  SAML is the older protocol. It would be a design smell to see a new RP using it exclusively (people still implement SAML because enterprise customers have SAML IdPs).

bilalq 2y ago

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 2y ago
OKTA does a pretty great job, if you want to spend $2X,XXX per year
- bilalq 2y ago
  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.
  - rvnx 2y ago
    Supabase Auth ? https://supabase.com/docs/guides/auth/enterprise-sso/auth-sso-saml https://supabase.com/docs/guides/auth/enterprise-sso/auth-ss... Seems reasonably easy to use and a good platform to build a SaaS
ucarion 2y ago
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-service-configuration-for-your-customers https://ssoready.com/docs/idp-configuration/enabling-self-se...

astrashe2 2y ago

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.

Terretta 2y ago
> Making authentication and SSO more painless Arguably, OAUTH2 + OIDC does this. Firms like Atlassian have understood this: http://id.atlassian.com http://id.atlassian.com

neilv 2y ago

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 2y ago
> 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 2y ago
  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_changes https://en.wikipedia.org/wiki/Elasticsearch#Licensing_change...

eastbound 2y ago

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 2y ago

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 2y ago

This is a huge pain point for many businesses. You're solving a real problem. Kudos!

mightybalthazar 2y ago

What happens if my enterprise custies need support because they can't log in and I need support? GitHub Issue? email?

ucarion 2y ago
My personal phone number and email is in the sidebar of app.ssoready.com for this exact reason.
- ceejayoz 2y ago
  That's kind of you, but highly unlikely to be scalable.
  - ctrlGsysop 2y ago
    That’s ok at this point. They’re purposefully doing certain things that don’t scale.

PaulMest 2y ago

Congrats on the launch! How does this compare to BoxyHQ's SAML Jackson [1]? [1]: https://github.com/boxyhq/jackson https://github.com/boxyhq/jackson

noleary 2y ago
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.
- crngefest 2y ago
  Would you mind elaborating a bit why you don’t think SAML-over-OAuth is a fits-all solution? To me it sounds like eating your cake (SAML) and having it too (not having to use SAML)

bks 2y ago

Is this a competitor to workos.com ? (we use them to connect customers to our apps)

noleary 2y ago
Yes. LMK any thoughts on how we compare. Eager to see where we can improve.
bks 2y ago
Sorry just read this in your repo "You can think of us as an open source alternative to products like Auth0 or WorkOS."

77soccer 2y ago

Best of luck seems interesting

your-username 2y ago

[flagged]

hamasho 2y ago

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 2y ago

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 2y ago

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/202308/msg00004.html https://lists.oasis-open.org/archives/security-services/2023...

rvnx 2y ago
Even the website certificate has expired apparently. net::ERR_CERT_DATE_INVALID Subject: lists.oasis-open.org Issuer: Sectigo RSA Domain Validation Secure Server CA Expires on: Jul 8, 2024 Current date: Jul 31, 2024

rvnx 2y ago

For info, the documentation for the project https://ssoready.com/docs https://ssoready.com/docs seems down: 502 ERROR The request could not be satisfied. CloudFront wasn't able to connect to the origin. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation. Generated by cloudfront (CloudFront) cf. http://www.site-shot.com/Lu-cUE7TEe-S-wJCrBEAAg http://www.site-shot.com/Lu-cUE7TEe-S-wJCrBEAAg or https://archive.is/wip/FhNfD https://archive.is/wip/FhNfD Otherwise the project looks really well done and by nice people.

noleary 2y ago
Thank you for letting us know! Are you still unable to use https://ssoready.com/docs https://ssoready.com/docs?
- rvnx 2y ago
  All good now

madduci 2y ago

It sounds great. Any chance to get this ported to other major programming languages (Java, C++, Go, Rust, C#)?

ucarion 2y ago
The interface between your app and SSOReady is entirely over an HTTP API. We codegen SDKs for that HTTP API for Python and TypeScript, and will add more, but in the meantime the docs show you the curl you'd need to port: https://ssoready.com/docs/api-reference/saml/redeem-saml-access-code https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...

dqh 2y ago

Thank you for this, it’s sorely needed. One thing I didn’t see mention of is group membership. Is this / will this be part of the core offering? Being able to map IDP group membership to permissions within your SaaS is powerful, and in my experience highly desired by clients.

ucarion 2y ago
Yeah, we have this -- if you check out the docs for the endpoint where you accept a SAML login[1], there's an `attributes` (map<string, string>) that SSOReady returns to you. That contains the contents of the relevant SAML assertion's AttributeStatement. So if you're familiar with Okta's parlance, both "Attribute Statements" and "Group Attribute Statements" are returned to you in `attributes`. [1]: https://ssoready.com/docs/api-reference/saml/redeem-saml-access-code https://ssoready.com/docs/api-reference/saml/redeem-saml-acc...
- dqh 2y ago
  Magnificent, thank you!

manishsharan 2y ago

This may be offtopic but I am looking for SSO integration advise for integrating with multiple IdPs. I am building a SaaS application and wants to allow customers from different companies , each with their on IdP to be able to SSO into my application , which is a multi-tenant SaaS offering.

downsplat 2y ago

That's very interesting, at $WORK we recently added SAML support in a similar use case, as a SaaS SP integrating with the customer's IdP. At the time we looked at various open source implementations, and ended up using OneLogin's PHP library. We wanted a headless library, so we could store the SAML metadata in our main DB and implement the public endpoints on top of it. It did take a few days of googling and trying, but it wasn't really that complicated. Our core implementation adds up to just some 500 lines of PHP, most which is just glue code to fetch metadata from the db, put it in the format the library expects, and then do the basic thing of sending the user to the IdP, getting the response back, checking it, and mapping a couple of attribute names. The advantage of this approach is that we were able to made it self service for our users. User logs in as admin, goes to "SAML settings", inputs their metadata, clicks a button to test, and if it's good, clicks another to activate. We did get a few support requests from people who didn't know their own systems very well, but otherwise it's working smoothly.