Introducing Osso

👋 Hi!

For the past few months we've been hard at work building Osso, a free, open-source service for adding SAML-based Single Sign-On (SSO) to your application. It will allow your company to enable SSO integration in hours instead of days, freeing your team up to build the innovative features your customers really want.

What is Osso?

Osso is an open-source microservice for authenticating users against SAML-based Identity Providers and signing them into your application. It has a few key features:

• Treats SAML like OAuth

SAML is clunky, and you’re probably already using OAuth. Osso provides an OAuth server, an Admin UI for managing OAuth clients, and OAuth client libraries for Ruby and NodeJS. Let Osso worry about the ugly SAML bits and customer configuration while your team focuses on your core application.

• SAML Config wherever you want it

For every customer who demands SAML SSO, you’ll need to go through a multistep process of creating a secure handshake between Osso and the customer’s SAML provider. Get started quickly by configuring your customers’ SAML providers in the Osso Admin UI, or allow your customers to perform configuration themselves in your UI with hooks and white-label components from our React library.

• Docs for everyone

SAML is an open specification, but each Identity Provider uses specific terminology and offers their own workflows for adding a new application. Osso generates user-friendly, intuitive PDF documentation with the specific data each customer needs to configure your app in their provider, and provides thorough documentation for your team as they integrate and manage your Osso instance.

We've deployed a demo instance that you can click around in - demo.ossoapp.com

Why Osso?

Plenty of open source options already exist for adding SAML-based SSO to your application, so what additional value does Osso actually provide?

While existing OSS helps get you started with an SSO proof of concept, there’s a huge gap between a proof of concept and releasing SSO as a scalable feature that Sales knows how to sell, Customer Success knows how to onboard and troubleshoot, and Engineering knows how to debug. If you were to follow OneLogin’s Ruby SAML Authentication Examples , you might think you can add SAML integration in under an hour. But the truth is this proof of concept is wholly insufficient for building out a scalable SSO integration that supports multiple customers and multiple identity providers. An underbaked SAML integration will also create heavy sales and support burdens when a customer demands SSO.

Osso provides two main areas of functionality to help close this gap and reduce the burden on your sales and success teams: CRUD and Docs.

• CRUD

With Osso, our Identity Provider CRUD (create, read, update, destroy) helps you go from proof of concept to full-featured by allowing you to skip all of the boilerplate code needed to configure SAML identity providers for each enterprise customer. In a proof of concept, you might hard code some of the data needed to complete the authentication dance. As you start to scale the solution, you'll keep pulling on this thread, and soon realize that it's a bit bigger of a project involving some database tables, x509 certificate validation, and a UI to tie it all together. Start adding more identity providers and things get even more entangled.

Instead, let Osso worry about the banal CRUD - deploy your Osso instance, authenticate your team, and you've got a full-featured Admin UI where your team can easily manage your customer's SAML Identity Providers.

Since Osso requires that you send your users through an OAuth flow, Osso's Admin UI also includes a section for OAuth Client CRUD. If you've ever registered an OAuth client on Google or Facebook then this will be a familiar UI to you.

• Docs

Osso generates PDF documentation for each one of your customers, specific to their provider. In a proof of concept, documentation might not be something you consider, but each Identity Provider has a very specific process for adding a SAML app for a enterprises's employees. These are also enterprise companies themselves, and the UIs are as obtuse as you would expect.

We've taken great care in crafting straightforward and accurate documentation for each provider we support (Okta, Microsoft Azure ADFS, OneLogin and Google for now). When you onboard a new customer in Osso, we provide you the white-labeled documentation to send to your client in order to configure your app in their IDP.

In some ways we see this as the biggest value add - our open source docs should cut down on time to onboard and troubleshoot customers, and non-engineers may benefit from this the most.

How is Osso built?

Osso closes the gap between existing OSS and a scalable SSO solution by building off of the existing OSS.

Osso depends on some important open source projects in order to provide authentication functionality. OneLogin maintains ruby-saml, a ruby gem that "provides a means for managing authorization initialization and confirmation requests from identity providers." SAML is 15 year old open standard - we don't see any need to reinvent the wheel here, and this project is stable, well-tested and well-maintained.

Osso depends directly on omniauth-multi-provider which itself utilizes ruby-saml. Omniauth is a popular multiple-provider authentication system for Rack-based applications, and this provider gem wraps ruby-saml so it can be used in the familiar Omniauth authentication flow. omniauth-multi-provider is similarly well-tested, and we again saw no reason to reinvent this additional wheel.

Finally, Osso provides an OAuth Server. OAuth is another stable and open standard, albeit one that is more familiar to modern web developers. You send your users through Osso as part of an OAuth authorization flow - Osso handles the SAML part, and once authenticated against an IDP, sends the user back to your application, eventually allowing you to request a profile for the user using an access token. Osso depends on rack-oauth2 to provide a spec compliant OAuth server.

What's next?

Between now and a proper v1 release, here's what the Osso team will be focused on:

• More Providers

We plan to keep adding providers, and the bulk of this work is in creating our industry best documentation. We plan to add Google (SAML) ✅, OneLogin ✅, Ping, Gluu (yay OSS!), and others that the community asks for.

• Self-serve Paid Plans

We'll always be free and open source, but we'll also sell paid hosted plans for companies that wish to decrease the integration workload on the development team or would like to have the peace of mind that the Osso team can provide support if anything comes up. Our hosted plans will be a deployment of an Osso instance, and your data will not be mixed with other Osso customers'.

UPDATE: You can now sign up for Osso hosted plans.

• More OAuth Consumption Libraries

We're releasing omniauth-osso today for Ruby apps, and have started on a Passport strategy for NodeJS apps. We'd like to further explore consuming OAuth in other languages and offering libraries to make consuming your Osso instance easy in whatever langauge you write your backend.

Let's chat 🤙

We're really interested in having conversations with Engineering and Sales leaders who have maybe heard of SAML, or have it on their backlog, who might consider using Osso. We'd also be thrilled to chat with folks on the other side of this - anyone in IT or Infosec who administers their company's Identity Provider.

You can reach us at hello@enterpriseoss.dev