Hacker News new | ask | show | jobs
by sbauch 1961 days ago
Hey HN! We're Sam, Sam, and Michael, the founders of Osso (https://ossoapp.com/)

Osso is open-source software for integrating SAML SSO with any web application. It provides an Admin UI to onboard your customers, generates custom documentation to configure your app in a customer's Identity Provider (IDP), handles SAML authentication against IDPs and provides your app normalized JSON profiles as part of an OAuth 2.0 code grant authorization flow.

We started working on Osso together as a way to keep in touch and distract ourselves from, well, *gestures broadly at everything*. We chose to work on something that each of us came up against during our careers: supporting SAML SSO. Between the three of us, we've built internal tools where SAML was required by IT and struggled to sell SaaS products that didn't offer SAML SSO to enterprises who required it. We've also been users of various IDPs, limiting us from accessing the apps we wanted at work when they only included SAML SSO on the way-too-expensive Enterprise plan.

Every successful SaaS company builds SAML SSO eventually but it's never a top priority and nobody takes time to really understand it. If your customers want SAML, it's a great problem to have but chances are there are thousands of other things on your list. Most teams end up kicking it down the road, which can lead to lost sales opportunities. Companies end up piecing something together that kind of works but creates technical debt or support burden, or they spend thousands of dollars on Auth0 or AWS Cognito, but still lack customer docs or a streamlined flow for SAML onboarding.

So we're trying to simplify things for SaaS companies to make SAML SSO a more accessible option. We took existing open-source software and added the last 10% to make integrating a scalable, sellable, and serviceable SAML SSO solution as easy as possible. All the code is available on Github for you to run on your own, but we also offer a SaaS solution where we'll manage an Osso instance for you.

Osso:

• Treats SAML like OAuth - connect your app to an Osso instance via OAuth, and Osso will handle the SAML authentication and return normalized JSON profiles

• Enables first class support for Azure Active Directory, Okta, OneLogin, Ping, Google, and Salesforce, yet works with any IDP that supports SAML 2.0

• Features an Admin UI for customer support / success teams to onboard and support customers

• Provides a convenient interface for technical teams to create and roll OAuth clients and their secrets

• Generates custom PDFs for step-by-step onboarding for each of your customers

If you're interested in learning more, start here:

— Our docs [https://ossoapp.com/docs/quick-start]

— Github repos [https://github.com/enterprise-oss]

— Quick video walk-through of Osso [https://youtu.be/Jps3eeZGOr0]

— Demo instance [https://demo.ossoapp.com]

The back end is a few modular Ruby/Rack apps including a GraphQL API and an OAuth 2.0 server, while the front end is a React app written in Typescript. We use a modular and package driven approach, allowing you to customize your Osso instance with theming or middleware, or pick and choose parts of the stack to use, while getting critical updates through our Ruby gems and npm packages. We offer client libraries for Ruby (omniauth-osso) and NodeJS (passport-osso), and are working on React components you can use to interact with your Osso instance, like a login component and a widget to allow your customers to configure SAML themselves.

We really appreciate the HN community and the discussion that takes place here, so we hope you'll provide honest feedback on Osso. What's missing? What should we do differently? Anything you'd take away? We look forward to reading and responding to your comments, but if you want to speak with us directly you can also email us at hello@ossoapp.com.

Thank you! Sam, Sam, and Michael

2 comments

Looking at your license, it looks like it limits production use to "internal business purposes" and does not allow providing "access to the Licensed Work to a third party." To me that reads that this is not at all usable as open source for a production SaaS app serving external customers, only for internal intranet apps. I don't think it's appropriate to advertise this as "Open-source" with such a restrictive license.
So the intent of the license is to prevent copy-cats from using Osso's source to run a competing business. We certainly intend for you to be able to authenticate external customers in a SAAS app. IANAL but the license text hsa been vetted by an attorney.

Is our intent with the license enough for you to consider it appropriate for us to call this open source?

Absolutely not, contract law cares most about what is written in the actual contract, not what you say you intended by it. There is no way I can risk using this in a commercial SaaS app given the license as written. In comparison, Sentry's BSL license (which you mentioned in another comment) does not have the same flaw. I can use open source Sentry to monitor my commercial SaaS app no problem based on how their license is written.
I didn't mean for you to take my comment as a guarantee, but if you're more than curious I'd have your counsel read the license, as we are under the impression the use you describe is well within the rights granted by the current license. Put another way, do you consider Sentry "open source"?
Armin from Sentry here: obviously biased but the term I like the most to describe BSL as used by Sentry is: eventually Open Source.

The BSL upgrades automatically to Apache 2, so the only thing that it does is establishing a time window where there are some restrictions on the code.

A theoretical version is one where you just only release code with a large delay under the Apache 2 license and keep the rest closed source. That's also still technically open source but I would argue that's not a particular good version.

> Basically (can't reply to your other reply)

That is so good. How are the contributions managed from community ? is there a CLA that they need to agree. Couldn't find that in repo.

So if understood correctly, sentry entire source code is open source and can be used to monitor my backend/saas etc.

It is only a business cant build a competing service using it ?

I don't want to get into a philosophical debate about what is "open source," but I have no issues with how Sentry advertises and documents their licensing or in how their custom terms are actually written.
Fair enough. I stand by our interpretation of the current license though - the usage you describe is fair use, but let us know if your attorney disagrees as we'd definitely want to fix that.
> Companies end up piecing something together that kind of works but creates technical debt or support burden, or they spend thousands of dollars on Auth0 or AWS Cognito

I built something out with Cognito for my current team. I don't like it much, but we're definitely not spending thousands of dollars on it. Have you heard horror stories about its pricing?

From the AWS pricing page (https://aws.amazon.com/cognito/pricing/), you get 50 MAUs with SAML free and then it's $0.015 per user. We haven't had any issues with this - yet.

I do think your solution sounds nicer, but I'm really not sure looking at your pricing that it's cheaper.

Thanks so much for the kind words!

The pricing here is definitely more applicable to Auth0 :)

But for us, charging per user makes predicting the cost of your SAML provider difficult, and everyone seems to do this. We charge per customer account instead - if one of your customers has 50 MAUs it wont cost you more than a customer that has 10. And you won't need to pay us more is your software is a daily driver vs. something thats used lee frequently.

Ah great point, I wasn't thinking about how many users a single customer could potentially have. I'll definitely bring this up if we do end up onboarding more customers using SAML, Cognito is definitely not ideal for admins/documentation.