SAML-based Single Sign-On is an authentication strategy preferred by enterprise companies. An enterprise with thousands of employees faces unique challenges when it comes to providing access to SAAS user accounts, where allowing employees to register with email / password or their personal social accounts creates a massive amount of work to remove access as employees leave the company.
These firms hire an Identity Provider to centralize identity and access to applications for their employees. Identity Providers like Okta provide a single place where the enterprise IT admins can assign or revoke access to applications.
From an engineering perspective, SAML conceptually is very similar to OAuth, but whereas OAuth is class-based, SAML is instance based. When setting up a forem community, for example, if you want to offer Github OAuth sign in, you need to create an application on Github where you receive a Client ID and Secret to create a secure connection between your application and Github's OAuth servers. Then any Github user can sign in to your community.
For SAML on the other hand, you need to create a secure connection between your application and specific instances of Identity Providers. So if Acme Co signs up for your service and wants to sign in from their OneLogin instance, you perform a multistep process of configuring your application to talk to Acme Co's OneLogin. Then, if Bar Co comes along and also wants to use their OneLogin instance, you need to again configure your application to talk to Bar Co's OneLogin. You can't just setup "OneLogin SAML" and be done - every customer who wants to use SAML must be configured in your application, and your application must be configured in their Identity Provider.
I'm a maintainer and co-founder of Osso, an open source service to help developers add SAML SSO to their applications.
Osso makes it simple to onboard customers wishing to use SAML - we provide an Admin UI and bespoke end-user documentation for configuring your app in any of our supported IDPs.
Osso then provides an OAuth server to authenticate users into your application. So your application consumes Osso's OAuth server while Osso wraps a SAML login with normalized user profiles inside the OAuth 2.0 code grant flow. Osso handles all of the instance based SAML bits, persists the data needed to perform SAML authentication, and allows your application to interact with Osso as a class-based OAuth provider.
In order to provide an example of integrating Osso into a real-world Rails app, I thought it would be interesting to find an open source app like forem and integrate Osso. Going through this process also raised some issues in our omniauth gem, so it's been a useful exercise.
I have a PR here (not to forem, but just to our own repo to be able to show a diff) - https://github.com/enterprise-oss/forem/pull/1
I don't know if forem the company has any interest in supporting SAML SSO in paid plans (Discourse, like many SAAS companies, offers SAML in their Enterprise plan), but if so we'd be happy to chat, or feel free to use the PR we created and deploy your own Osso instance - would just appreciate a shout and a testimonial if things get that far!
I figure this can also help folks in the community who are perhaps self-hosting an internal community at a big co where SAML would be useful.