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!)
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.
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.
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.
Deleted Comment
SPF, DMARC, DKIM is setup correctly. Domain name A/AAA/TXT/MX records all setup and propagated throughout the world. Mail server tested with external tools like mail-tester.com
…
But there is a whole new world of “other mail servers” now. Some mail servers are okay. Delivery works fine. Some mail servers have odd policies and implement strict block lists and maintain their own rep of each domain/sender.
> 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.
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. :)
[1]: https://sso.tax/
How do you expect people to bootstrap an infra SaaS? I just don’t see how you can seriously attempt something like an Auth0 competitor startup without any money. I mean it’s nice to not take VC money but you are going to be broke for a long long time - and you still have the same failure rate as with VC.
So you need to be super masochistic to work for nothing for years with a 99% of everything will evaporate at any point - and at the same time somehow convince companies to build on your stack - not only build on it but make it the gatekeeper and front door of everything. I can tell you that you will have an extremely hard time to get any customers for this, regardless of how great the tech is.
Maybe you don’t need it at seed stage - but unless you are fantastically rich already you need some investment to get beyond seed stage IMHO.
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.
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.
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?)
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?
SOC2 is only theatre if you (a) you already have good practice, and (b) can demonstrate that you have good practice. If your practice isn't good enough (like the whole notion of security controls is a foreign concept), and sure there's a lot of boilerplate to work through -- but the whole point of a SOC2 Type 2 report is that you only have to demonstrate once to the auditor, rather than to each customer each time.
Having to get internal security sign-off for a non-audited SaaS vendor -- really, life's just too short for that most of the time, and if there's choice of two more or less equivalent providers we go with the certified one every time.
https://en.wikipedia.org/wiki/Elasticsearch#Licensing_change...
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...
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.
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!
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.
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 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 :)
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?
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
So, some questions:
1. First, do workplaces or SaaS app providers not need Android or iOS app support for in-house or client / customer facing apps?
Swift and Kotlin SDKs seem conspicuous by their absence.
https://workos.com/docs/sdks
2. Second, what about OIDC?
I'd argue the majority of business and business employees do not need "SSO", the majority of benefits they think they'd get are met by OIDC ("Sign in with..." buttons) for users with the firm's controlled email address @ firm domain as the login username. A plurality of big firms seem covered just by "Sign in with Microsoft", and "Sign in with Google" to pick up startups or individuals, followed by GitHub for devs or Apple for retail wallet share.
In our shoes, we'd far rather support clients through OIDC than SSO.
3. Third, Google has this covered if a startup bets on it, while Microsoft and AWS are a confusing melange of some 20 years of backwards compatibility, making bridging from devices into their Microsoft Entra or AWS IAM worlds hard to understand even if fully supported.
At the same time, many businesses with real budgets are "required" by senior management to stay within those ecosystems.
This calls for a frictionless experience and abstraction on top that uses the native mechanisms under the hood so the rest of the CSP ecosystem understands the users' identities, roles, and attributes, enabling CSP native security to protect the CSPs other offerings.
Have you considered being the experience on top of AWS's Cognito for example, letting you drive it and then IAM RBAC for their various systems, effectively offloading "securing" of the mechanisms to the CSP, while handling the complexity that only those who've learned those mechanisms can master?
For reasons, we want to bet our actual under-the-hood security controls on the CSP's security controls. For example, of all participants, they have the most to lose from a controls failure. And some, like AWS, bring a level of discipline to security controls nobody else seems willing to afford, such as through their "formal reasoning" or "provable security" work:
https://aws.amazon.com/security/provable-security/resources/
Concept:
Ever since you've launched, it's seemed to me that WorkOS might be the best envisioned suite to be the layer on top of CSP native security engines and security controls (directories, secrets, IAM, RBAC/ABAC, row level or cell level security, etc.).
We only have a few dozen employees, and as a startup are very sensitive to recurring costs, but are still heavily regulated. If thinking in developer-hours, we would cheerfully pay up front a quarter or two's worth of dev time (depending on in which market you measure value of dev time) for OOTB "integration" of such a layer on top of the native CSP mechanisms. This could include some nominal and proportional amount relative to, say, the recurring cost of Microsoft Teams (e.g., less than $4 a month) at the consumer end or relative to the delta between M365 and M365 E3/E5 Advanced Security on the enterprise end (if you look at what's included for +$10/month, you can see most per-seat security tools are overpriced:
https://www.microsoft.com/en-us/microsoft-365/enterprise-mob...
Given the amount of "stuff" already paid for in one of those plans, that's a lot of "stuff" you wouldn't have to do. Arguably, if you're the frictionless UI and configurator rather than providing the controls themselves, you're out of the "critical path" entirely, meaning easier contracts with businesses where the regulator wants regulated entities to negotiate for financial indemnification if the vendor fails.
TL;DR:
This isn't what you do, and probably shouldn't be, but maybe someone else will read this concept and think they should. We're not the only ones who would buy it!
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.
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.
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.