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.
SAML vs. OAuth
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.
Osso
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.
Osso + forem
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.
Top comments (2)
This is a great thought. We have discussed this internally and would favor the right solution...
I wonder if folks from our team can weigh in on whether this approach makes sense. This is not something I have a great understanding of from an implementation perspective.
Thanks Ben! While we love the idea of integrating into other open source services, I can admit that it's not a great solution to ask your OSS users to go deploy another service in order to get a feature like this.
Ultimately most of the functionality comes from a Ruby gem, and there should be a path where you can consume that gem, create some tables, and mount the rack apps from your rails app to build Osso into forem proper. We haven't really tried or documented that, but it's certainly feasible. Then you could make use of our react package to build the Admin configuration functionality, generate documentation, etc.
I think the hardest I'm willing to sell this here is that implementing SAML is not fun, your team would rather work on other stuff, and you're better off not having a great understanding of this all and letting Osso worry about it 😉
But at the end of the day this was a fun little project, so thanks for making forem available to hack on!