Single Sign-on Technology: How to Secure your Project

Nowadays, nearly every business has a lot of applications that require individual login credentials. How many times per day we log in and log out from the apps?

Moreover, passwords can create additional difficulties for users. Imagine you have dozens of passwords that you regularly required to update in order to comply with a privacy policy.

Luckily, there are technologies that can significantly simplify this process. In this article, we’ll tell you about one of these technologies and how we implemented it in our project.

Single sign-on, also known as SSO, relates to the technology for the user authentication process that allows accessing multiple applications with one set of user credentials.

To understand how this technology works, let’s compare a Traditional Web Authentication Process with a Single sign-on.

So here’s the flow:

1. A user visits a website;
2. They enter their login credentials;
3. The system compares the entered credentials with one on file;
4. If it was approved, the domain will store the credentials.

The steps 5-8 are practically the same as they repeat for different steps.

The process of Single sign on technology looks like the following:

1. The user goes to the website they want to visit;
2. Due to the domain redirection, the user goes to a central Single sign on domain to login;
3. The user enters the login credentials;
4. The central SSO Domain submits the credentials to the authentication server for validating them;
5. As soon as the credentials have been validated, the user will be redirected to the original website and embedded a token to guarantee their authentication;
6. The embedded token will be used for an automatic user’s authentication by logging into the original website;
7. The authentication token will be stored so that the user could safely access any website that shares the central SSO domain.

In case the user logs into Domain 2, the whole process will be the same. However, there’s no need for an additional set of credentials to log in as all the login attempts are made on the SSO Domain.

Main Terms:

• Identity Provider (IdP) is a service that provides authentication, which result will be in the SAML format.
• Service Provider (SP) is a web application that the user tries to access.

The Challenge

The project, where we successfully implemented SSO was a unique web application that offers a simple yet very effective solution to the ubiquitous and common problem of mispronouncing names. With its help, you can record and then save your name right on the website so that others could easily access and remember how to accurately say it. Used by some of the largest US universities and colleges like Stanford, Pepperdine, Xavier, Haverford etc., NameCoach successfully tackles the problem of unnecessary alienation and embarrassment that occur at the graduation ceremonies and other important events quite frequently. Currently, there are about 110,000 active website users.

Stanford University, who is one of Name Coach clients, asked us to implement SAML SSO for already existed IdP so that students could authenticate in NameCoach.

The Solution

For a precise work of SAML SSO, we needed to build between IdP and SP.

This means that IdP needs to store data, which was given by SP:

• EntityID is a unique identifier for SP;
• ACS URL (Assertion Consumer Service URL) is a url on which IdP needs to send SAML response after the successful authentication;
• X509 certificate;
• Attribute – a list of attributes that need to be transmitted in case of successful authentication.

IdP, in its turn, should provide the following for SP:

• Certificate;
• EntityID or Issuer – a unique IdP identifier;
• SSO URL – url that initiates an authentication on the IdP side;
• SLO URL – url that closes the user’s session.

We found a solution for the following challenges:

1. We implemented an interface for adding the IdP settings;
2. We added a necessary functionality for SAML SSO implementation from the SFside.

The Bottom Line

The implementation of User Interface and adding the IdP settings allowed a client to provide us with the settings for the SAML SSO implementation. In our turn, we did our best to make the application compatible with all requirements so that it could serve as a Service Provider.

For this purpose, we used OneLogin services for the developers. First, we generated a new certificate x509. Having used OneLogin gem, we implemented logic for Assertion Consumer Service that verifies SAML response from IdP and makes the logic after the successful authentication.

In order IdP could register our application as SP, we needed to provide it with metadata for SSO configuration. For this purpose, we also used gem with all the necessary classes that allow generating metadata with the given settings in xml format.

As a result, we integrated SAML SSO and unified its settings from a personal client’s account to a usual personal interface.