Reflections on the RailsConf 2020 talk of Brynn Gitt & Oliver Sanford

Brynn and Oliver shared from their experience implementing Single Sign On (SSO) and Identity Management with various protocols and providers. It was interesting thinking about this from the vendor point of view, most of my experience with SSO has been as a customer trying to implement and troubleshoot SSO integrations.

---

A key lesson up front was how to think about identity when building (or expanding) a business to business (B2B) application, to avoid painting yourself into a corner. Consider:

• A single person may have multiple identities; they may be a member of multiple organisations, at the same time
• A single “identifier”, such as an email address, may apply to different users at different times e.g. if an organisation reuses an old email address for a new member
• A single organisation member may have multiple or mutable identifiers; e.g. for privileged accounts or in the case of name or email address change
• Different organisations will allow or require different Identity Providers
• Different Identity Providers have different implementations of the same protocols and standards

There is no single answer that will be correct in all circumstances but in most cases it makes sense to scope every person to an organisation. If you also need individual accounts there are two common ways to deal with that:

• have many one-person organisations (at least under the hood, I imagine there’d be good arguments not to expose that to customers)
• add individuals to a single “public” organisation (again, under the hood)

Within this first section Oliver briefly touched on the importance of observability and the need to log identity events. They can prove very useful when tuning a system or implementing new functionality.

---

The talk then went on to SAML (which is where most of my experience as a customer setting up SSO has been).

One tip was to use OmniAuth MultiProvider to make it easier to allow different customer organisations to each set up their own Identity Providers.

Another tip was to set up a flag you can turn on in production to log SAML assertions. This will allow you to assist customers as they figure out the required format and parameters while setting up SSO in their own organisation.

One last tip I want to remember is to use KeyCloak in development. It’s an open source Identity and Access Management system that can be used as an IDP in development (and can be launched simply using Docker).

---

After touching on just-in-time account provisioning, the rest of the talk covered SCIM - System for Cross-domain Identity Management. Implementing SCIM enables customers to create and manage accounts in your application directly from their Identity Provider (such as Okta). I’m very interested to dive into that topic a bit more, particularly with regards to how it might apply in the ed-tech space.