SSO offers a user the ability use a single credential to allow access to several inter-related or integrated systems of software. Given that companies use 16 SaaS applications on average, it is clear why SSO is a common feature request among enterprise and mid-market companies (BetterCloud, State of the SaaS Powered Workplace Report 2017).
After the implementation of SendBird into customer applications, most users interact with the SendBird system through the dashboard. Oftentimes, a single organization has multiple users and operators, so SSO becomes the most secure and convenient authentication process for our customers.
This article shares our rationale and implementation process for adding SSO to our service dashboard.
Single sign-on is a method of access control allowing multiple users associated with a single company to login to multiple applications using one set of login credentials. We also use it to make authorization of user roles and permissions more convenient.
This benefits our customers in a few ways:
Other software products also make it easier for users to sign-up for our product. Instead of having to go through a sign-up form with any number of input boxes and radio buttons, users can reuse their credentials without worrying about identity theft.
Even though it is a common and trending practice to use SSO, there are a number of open standards enabling the single sign-on process. Some of the most popular options are OAuth2, SAML2, OpenID Connect.
The following table summarizes these options and gives some background about their use-case and format.
SAML is the only standard that supports both authentication and authorization. That means users can not only login with their own id/password combination but they can also share their profile, roles, and permissions through this same protocol.
Among all the other options, SAML provides more control to companies for keeping their SSO logins more secure by supporting signing and encrypting data on both the Service Provider and Identity Provider sides. So, if needed, one can encrypt data for the entire process and an attack cannot decrypt it unless they already have access to the private keys of both the Service and Identity provider. The spec was announced in 2005, so it has many implementations for multiple systems and languages.
This is what the user flow of SAML based SSO looks like when data transfer is based on HTTP-Redirect and HTTP-POST (See “How do you implement it?” below for 2 other options).
The process proceeds as follows:
As you can see from the above structure, you will need two endpoints:
How data is transferred from one entity to another could be dealt with three different ways:
Most often, authentication requests are sent utilizing HTTP-Redirect or HTTP-Post binding because the data payload is small. But, since the SAML response is usually too large to fit into an url, it’s common practice to use HTTP-Post binding to transfer the SAML response data.
This is what it’ll look like on the authentication request side:
This is what it’ll look like on the SAML response side:
Summary and further discussion
This article tells you about SSO and why your product may need it. It also covers how to implement it with basic code examples. But, for our actual product, we used python-saml.
There are other things you could consider for SSO as well. This article only covers how to let users log in through IdP (and provision an account).
Some other things to consider when building your SSO:
In the future, we’ll think about these additional ideas for SSO. We are already working on adding features like JIT provisioning and will support customers with rich features like enforcing SSO to organization members.