hckrnws

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.

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

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.

Yeah, I’ve done this too. On the one hand, it’s crazy annoying. On the other hand, at least they _had_ a docker image I could use.

HL7v2, the protocol of "we just put all the data in this one random field".

Delimited with ^, |, ~ and &, which is sure to never create issues.

As a base64’d pdf

It's amazing how normalized this is, I was baffled many years ago and I have just accepted it at this point.

So it’s like managing your own e-mail server.

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.

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.

You’re responding to a comment not the op? The commenter isn’t trying to make money just sharing an experience

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

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"

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/

Ya with the last decade of experience I'm never building on top of a vc backed open source project. These things are mutually exclusive IMO. I'm not saying you can't build a solid business around open source. I mean red hat did it, but that is the model you have to go for. Not VC money at seed stage.

Out of curiosity, who else did it besides RedHat ( who are building Linux distros AFAIK ) ?

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.

Laravel and that whole ecosystem is another great example. Open source is slow and a grass roots movement. That's what I mean, when people think it is venture scale, they are either being dishonest to the investors or to the users. Because one day the ethos of open source has to be broken to make the real money. Better to make it a paid product from day 1 instead of playing this game.

One of my favorite bad examples of this is Supabase. They played into the whole open source Firebase bandwagon and while their code is available, the ethos of open source is completely lost, so much so that even now local development and self hosting is a pain.

In terms of good examples, Andrew Sherman who does Drizzle ORM is a good example of this. Here is one of his tweets talking about not taking VC money: https://x.com/andrii_sherman/status/1775954643022971044

> I quit my job to start working on Drizzle full-time. It's still not VC-backed(and will never be!), and we are still doing everything thanks to our great sponsors and our first successful B2B integrations.

So it can work but honestly the best open source projects start off when you are getting paid a salary and you work on the project because you are passionate and love working on it.

> How do you expect people to bootstrap an infra SaaS?

Presumably ilrwbwrkhv is thinking of the fate of ElasticSearch, MongoDB, Redis, CockroachDB, Confluent, TimescaleDB, Terraform, HashiCorp Vault, Docker Desktop and suchlike.

The VCs want a return for all the money they've invested, and it's difficult to monetise a free product.

One way to avoid letting down your community is to have your product be a closed-source paid product from day 1. Another is to get the backing of a huge multinational with endless ad revenue. Another is to run a super lean one-man operation, or get a day job and make free software your hobby. Another is to teeter on the edge of bankruptcy and hope one of your users just acquires your entire company.

Or you can just disappoint your community - SAML's only used by faceless megacorporations anyway, it's not like you'd be letting down real people.

None of these are great options IMHO - but that's why I don't have a VC-funded infrastructure startup myself :)

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.

> It's a pretty common commercial open source playbook not to monetize in the early days.

Right, but what has become common, if successful at cornering market share, is then changing the license to something open-source-ish and charging money for what used to be free. Sometimes a lot of money.

Many swore they'd never do it. Many probably even meant it at first.

So, it's a concern for sure.

So then fork it and continue like that. At least you have the option as opposed to some proprietary solution

Sure, that's an option.

Also an option, when choosing what to use right at the startt, is being careful about using an open source solution from a for-profit startup, and evaluating all your other options, taking into account that it may not remain open source, and if it doesn't, what place it has in your business, how hard it would be to switch then, etc.

Right, the overhead of setting up SAML on your own is _a lot_ and things like this usually come with a Wal-Mart’s worth of foot guns. Even so, I’d be much more keen to spend the time up front diving into it and working on an in-house solution, rather than find myself and my team up a creek with a broken auth solution and several sprints worth of work to fix it, that’s also going to push other work out because logic is critical.

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?)

> 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?

> SOC2 stuff (which we all know is largely theater)

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.

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

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.

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.

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

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.

Sounds horrible, why would you use Shibboleth in $currentyear if you could just use OIDC?

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.

OKTA does a pretty great job, if you want to spend $2X,XXX per year

I'm referring to the opposite side of the problem. Even if you use Okta, if you want to integrate with company XYZ using SSO, no amount of Okta spend will save you.

Supabase Auth ? https://supabase.com/docs/guides/auth/enterprise-sso/auth-ss...

Seems reasonably easy to use and a good platform to build a SaaS

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!

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.

> We wanted to build data cleaning software with LLMs, before we realized no one really cared about messy data.

This sounds like a good problem to solve with LLMs, and honestly I'm a bit surprised to hear that nobody cared about data being of poor quality. Care to elaborate a little bit?

I should have been a little more careful in my phrasing. Certainly some number of people care about data quality. The motivation for the project came from my own personal experience -- it was a product that I really wanted.

Our positioning (e.g. principal use cases, target verticals, target persona) and timing were totally wrong. We tried to run top-down sales against relatively important data (e.g. sales forecasts). People often expressed an attitudinal interest in the product, but it was very hard to motivate people actually to use the product seriously. Category creation and behavior change are really hard.

If I were trying to sell an LLM data cleaning product now, I'd focus on more technical buyers, someone more like a data engineer than a strong spreadsheet worker. And I'd try to drive bottoms-up, low ACV adoption first.

Doing the post-mortem justice would probably require a long blog post.

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

Sounds a lot like Spolsky's "commoditize your complements"

Lots of YC LLM pivots lately...

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?

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?

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.

Incredible. Yes perfect. Thanks Ned!

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

WorkOS is incredible, and we've admired it from afar since launch. We'd like to use it, but aren't sure about the roadmap or applicability for SaaS “app” provider needs that otherwise seem like a perfect match.

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!

This is a really thoughtful comment -- thanks for sharing.

Will read through this again and think more carefully about it later today.

Good questions! My answers (with footnote links):

> 1. Do workplaces or SaaS app providers not need Android or iOS app support

All identity providers are 3rd-party systems that authenticate a user via a web experience. They don’t have a direct way to submit credentials. e.g. In Okta SAML auth, your app redirects the user to a hosted Okta UI which verifies their identity and then redirects back to your app.

WorkOS supports this on mobile via webviews and custom URL schemes, so the redirect back can be `yourapp://callback` etc. This is simple enough to build that developers haven’t asked us for a custom Swift/Kotlin SDK. However, it’s still a good point you raise and we should add better docs. Will make a note.

> 2. What about OIDC?

WorkOS supports SSO via OIDC including Okta OIDC. In practice we have found OIDC much less common than SAML despite it being an improved protocol with fewer sharp edges. I’m not sure why this is other than legacy enterprise IT vendors being slow to change. Perhaps OIDC is 2x better but not 10x better.

There are lots of cool ideas to improve the world of SAML+SCIM including FastFed [1] but unfortunately they are stuck in a proposal/prototype state and have not yet overcome the coordination headwind of multiple vendors simultaneously launching support. I hope it happens someday!

> 3. Have you considered being the experience on top of AWS's Cognito…

It’s an interesting idea to build a better front-end to Cognito and similar platforms so developers can leverage underlying CSPs. In a sense this is what we’ve done with WorkOS SSO [2], which abstracts all the hairy bits of SAML behind a simple OAuth API. We’ve done the same thing with SCIM [3] by integrating all the various directory systems into a single API with modern semantics and predictable responses. WorkOS is like “Stripe for enterprise features.”

What I’ve personally seen is the innovation cycle for Cognito is glacially slow. As an example, at AWS Re:Invent last year there were zero sessions on Cognito and I couldn’t find a single PM to talk about the product. Perhaps Amazon will eventually ship something but today Cognito is clearly not a priority for them.

So instead we built WorkOS. We started with SSO and SCIM and then launched the Admin Portal [4] which makes IT configuration — otherwise a headache inducing process — an easy self-serve wizard. This design has been successful enough that we’ve attracted competition (and even some open source clones. ;)) Overall though I am glad to see more people working to improve the lives of developers building enterprise SaaS.

In the last couple years, WorkOS have been expanding our product into other areas of the IAM stack. Last year we launched a fully-managed identity service called AuthKit [5] which includes powerful features like session management, impersonation, and RBAC. AuthKit is an alternative to Auth0 but it’s free up to 1,000,000 users.

A few months ago WorkOS acquired Warrant (YC S21) [6, 7] which provides a fine-grained authorization (FGA) service inspired by Google Zanzibar. This enables developers to model even the most complex data authorization with a single runtime. Warrant is open source and is an alternative to AWS Cedar, SpiceDB, and Oso, and other. But it has some differences, such as the “edge agent” which allows permission checks to be evaluated locally within your app. Super fast, no HTTP requests required. [8]

We also love open source. WorkOS builds Radix UI [9] which has something like 30M monthly downloads and powers the design systems for Linear, Vercel, and others. I even considered starting WorkOS as an open source platform. But what we heard from developers was that code was only part of the solution. They wanted a service that included ongoing support and dependable uptime. They want to just pay and make the “enterprise problem” go away. That’s what WorkOS does.

We’ve found smaller startups are also fine to pay for features like SAML and SCIM because they enable selling upmarket and unlocking enterprise revenue. Often startups will just pass on the WorkOS cost in their own enterprise contracts. Our pricing is usage-based, transparent, and easy to understand. And it doesn’t require clicking “Contact Us” and negotiating with a sales rep. [10]

Building a layer on top of other IAM/CSP systems initially sounds appealing, but ultimately I don’t believe it will let us achieve the goal of providing the best possible developer experience with the most robust features to users. To do this right we need to invest deeply in the technology primitives. We’ve raised $100m and today have hundreds of customers and millions in revenue so we’re well on track to solve this problem for everyone.

Hope this adds more color. Happy to answer other questions here or via email anytime. I’m mg@workos.com

[1] https://openid.net/wg/fastfed/

[2] https://workos.com/single-sign-on

[3] https://workos.com/directory-sync

[4] https://workos.com/admin-portal

[5] https://authkit.com

[6] http://warrant.dev

[7] https://workos.com/blog/workos-acquires-warrant

[8] https://github.com/warrant-dev/edge-agent

[9] http://radix-ui.com

[10] https://workos.com/pricing

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.

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.

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.

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.

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.

Congrats on the launch! How does this compare to BoxyHQ's SAML Jackson [1]?

[1]: https://github.com/boxyhq/jackson

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.

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)

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.

> Making authentication and SSO more painless

Arguably, OAUTH2 + OIDC does this. Firms like Atlassian have understood this:

http://id.atlassian.com

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.

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?

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

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.

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

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

For info, the documentation for the project 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 or https://archive.is/wip/FhNfD

Otherwise the project looks really well done and by nice people.

Thank you for letting us know!

Are you still unable to use https://ssoready.com/docs?

All good now

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.

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.

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

My personal phone number and email is in the sidebar of app.ssoready.com for this exact reason.

That's kind of you, but highly unlikely to be scalable.

That’s ok at this point. They’re purposefully doing certain things that don’t scale.

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.

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-acc...

Magnificent, thank you!

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?

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.

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.

You might turn out to be right! Only time will tell.

Why focus on SAML rather than OIDC2?

OIDC2 is the better protocol, don't get me wrong. But lots of companies run on SAML, and it's the thing customers explicitly ask for.

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.

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

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

Sorry just read this in your repo "You can think of us as an open source alternative to products like Auth0 or WorkOS."

Yes. LMK any thoughts on how we compare. Eager to see where we can improve.

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.

Best of luck seems interesting

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

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-acc...

Why saml instead of OIDC?

In my experience, SAML seems to be a more universally used option.

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.

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

[flagged]