Over the years, I’ve repeatedly heard things like:

“SSO is a complicated beast”

“Implementing SSO requires so much manual effort with each customer”

So when we started getting a trickle of users asking for SSO in Typesense Cloud, I put it off for the longest time, dreading the painful implementation.

We soon reached a critical mass of potential users asking for SSO and a few even saying it’s a show-stopper.

Oh well.

So off I went to learn all about SSO, half expecting to be forced to signup for some paid auth provider and sadly having to pass on the costs of SSO to users & embarassingly end up on the SSO wall of shame.

The Learning Curve

Based on the initial set of users’ asks, I decided to experiment with Microsoft Azure AD (now called Entra) and Okta - signed up for a sandbox dev account and went through the SSO setup process to learn what the end-user experience would look like.

The first thing I noticed is that they both use SAML (Security Assertion Markup Language) as the SSO protocol, yet they use slightly different terminology to refer to the same concepts. It took me a couple of days of reading to understand what all the different terms meant.

We use Ruby on Rails for Typesense Cloud’s web console, along with Devise and OmniAuth for authentication. Thankfully, I found a SAML strategy gem for OmniAuth. However, the gem seems to have been written with the assumption that you’re integrating an internal tool with your own SSO platform.

What we needed was the “platform-ized” version of that - the ability for users to dynamically integrate our platform with any SAML-based SSO identity provider, at application runtime.

This was the most complicated part of the whole endeavor. Took about a week (Week 2) of going down the wrong path with a quick prototype, but that was very enlightening.

Then it just clicked - all the pieces finally came together and made sense.

By the end of week 3, I had a working version of SAML-based SSO login for Typesense Cloud with my sandbox accounts.

Week 4 & 5 involved building the UI to make it self-service for users.

Week 6 involved writing detailed docs.

The Doubt

“Why are so many folks complaining about SSO’s implementation complexity?”

Around week 5, I started to question if I’m missing something big in the implementation, which would have otherwise blown up the complexity.

So I started looking up other open source products that have implemented SAML-based auth. I found GitLab’s Rails codebase and verified that really this is all that’s needed.

I told myself that may be once we launched the feature, we might get flooded with one-off support requests to do something custom for each user. And may be that’s what I’m missing.

“We’ll soon find out… I guess.”

The Launch

We launched SSO quietly without making a big splash, and just let users set it up themselves following our docs.

More surprise and disbelief.

Users started using the feature themselves, and the vast majority of users have been able to integrate Typesense Cloud with their SSO platform, without any additional guidance.

We’ve only had a few users who have reached out to support asking for what values to plug from their SSO platform into Typesense Cloud (since those platforms referred to the same SAML concepts slightly differently). As we encountered each nuance, we documented it religiously for future users.

And our most recent SSO user had this to say:

Our team setting up SSO said the docs are AMAZING

Music to my ears!

The Conclusion

It feels like I’ve come out of a reality-distortion field when it comes SSO, after hearing years of FUD around this topic. Many companies even claim that the complexity and ongoing support costs are the reason they charge an arm and a leg for SSO.

I’m here to call BS on this.

I’ve now learnt from personal experience that implementing SAML-based SSO is not that hard. You can build the integration in a way that makes it self-service for users without additional support overhead.

Charging extra for SSO now feels like charging extra for storing passwords hashed and salted in the DB - both are table stakes for security, and shouldn’t cost extra.

Now, to be fair, may be supporting multiple SSO protocols like Shibboleth, OIDC, etc in addition to SAML is more complex… I’m yet to find out.

But hey, there’s always a gem for that.

That’s the nice thing about using a web framework with a mature ecosystem like Rails. You can stand on the shoulders of giants and write an article like this about how easy everything is!