Implementing Single Sign-on (SSO) for a product dashboard

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.

What is SSO and what are its benefits?

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:

1. Since SSO allows users to authenticate using their own login system it also allows admins to manage user accounts and enable employees to use it across the multiple applications used by a company
2. SSO allows admins to immediately control access to all applications, rather than logging into 100 different user management portals to make changes to user permissions
3. Importantly, SSO also helps with security. Since there’s only a single system holding all employee information, it’s much easier to secure one place than hundreds of different accounts, which could become possible “leakages.”

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.

Why use SAML for SSO?

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).

(Source: Wikipedia SAML 2.0)

The process proceeds as follows:

1. User request initiation of SSO to service provider.
2. Service provider creates an base64 encoded authentication request and send it to identity provider.
3. Identity provider receives authentication request, verify it, and request user to authenticate (login).
4. Identity provider sends user XHTML form with base64 encoded SAML response.
5. User sends SAML response to service provider.
6. Service provider verify SAML response and redirect user to target resource.

How do you implement SSO?

As you can see from the above structure, you will need two endpoints:

• One endpoint initiates a build up authentication request and redirects the user to the login form, while it sends base64 encoded login request data
• Another endpoint accepts and receives a SAML response after a successful login process

How data is transferred from one entity to another could be dealt with three different ways:

1. HTTP-Redirect binding encapsulates data in the form of receiving a parameter.
2. HTTP-Post binding sends data in the HTTP post request. It is usually done by creating an XHTML form.
3. HTTP-Artifact does not involve the user (or a browser) but creates a direct connection to each endpoint.

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:

• What about user credentials?
• What if users want to update/or sync on SP side?
• We only covered SP initialized authentication. What about an IdP initialized authentication?
• What about SLO?
• What about multi-organization?

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.