Table of Contents

Tutorial: Enable B2B Single Sign-On (SSO) for a SaaS Application with No-Code/Low-Code

6 minutes read
Modern Office: Portrait of Motivated Black IT Programmer Working on Laptop Computer. Male Specialist Create Website, Software Engineer Develop App, Program, Video Game. Stress Free Inclusive Space
Table of Contents

Preview

B2B single sign-on (SSO) is critical for SaaS applications serving enterprise customers. Current solutions such as Auth0 and Amazon Cognito require developers to leverage SDKs and APIs, resulting in a time-consuming and expensive process. However, Datawiza provides an innovative, no-code solution that is based on configuration, simplifying SSO implementation.

In this tutorial, we will use the Datawiza Access Proxy (DAP) to enable this functionality. For the tutorial, we assume a web application, “WebApp,” has two enterprise customers. Acme Corp. is using Microsoft Azure AD as its SSO platform. Globex Corp. is using Okta. 

We will show how to use the DAP to enable SSO for WebApp to serve these two customers. We’ll use the DAP’s sidecar deployment mode, which means the DAP and WebApp are running on the same server.

  • WebApp will run on localhost:3001, and it can receive HTTP headers to retrieve user information passed by the DAP. 
  • The DAP will run on localhost:9772, which means the traffic to the app will reach the DAP (running on port 9772) first and then be proxied to the application (running on port 3001).
  • We will provide the docker images for the DAP and WebApp.

Part I: Azure AD Configuration

The customer Acme Corp needs to register WebApp in the Microsoft Portal and get the following values for this application:

  • Client ID
  • Client Secret
  • Tenant Id

These values will later be used to set up the DAP in the Datawiza Cloud Management Console (DCMC). Please follow IdP Configuration Guide: Azure AD instructions on how to get those keys/values.

Part II: Okta Configuration

Similarly, the customer Globex Corp needs to create an application on Okta and provide the following values:

  • Client ID
  • Client Secret
  • Okta Org

These values are needed to set up the DAP in the Datawiza Cloud Management Console (DCMC). Please follow IdP Configuration Guide: Okta instructions on how to get those keys/values.

Part III: Create Application on Datawiza Cloud Management Console (DCMC)

  1. Sign in to the Datawiza Cloud Management Console.

Navigate to the Deployments page on the left menu, and then click the Create Deployment button

Navigate to the Deployments page on the left menu, and then click the Create Deployment button

3. In the Name and Description fields, enter the relevant information.

4. Select Create.

Deployment

 

5. Navigate to the Provisioning Keys tab, and then click the Create Provisioning Key button.

Deployment Detail

6. In the Key Name and Expires fields, enter the relevant information.

Tutorial: Enable B2B Single Sign-On (SSO) for a SaaS Application with No-Code/Low-Code

 

7. Make a note of the Provisioning Key and Secret, you will need to use this key pair later.

8. Navigate to Applications sub-tab, and then click the Create Application button.

Deployment Detail

9. In the Add Application dialog box, use the following values:

Property

Value

Platform

Web

App Name

Enter a unique application name. For example, you can use the WebApp.

Public Domain

Application url that end users will visit.

For example: https://WebApp.example.com

For testing, you can use localhost DNS. Here we use http://localhost:9772

Listen Port

The port that DAP listens on. Here we use the 9772.

Upstream Servers

TheURL and port of your SaaS app. Here we use http://docker.host.internal:3001

10. Select Create.

Add a web app

11. Select Create.

12. Switch to the IdP Configuration tab, Click the Create IdP button under Domain Hint.

header app

13. In the Add IdP dialog box, add an organization domain. Here we use acme. Select the Microsoft Azure Active Directory as Identity Provider. Switch off Automatic Generator. Enter all the information from Part II.

14. Then click the Create button.

15. We can now repeat the previous steps to create an Okta IdP. Click the Create idp under the Domain hint. Put all the information from Part I. This time we use globex as an organization domain.

16.  Your IdP configuration will now look like this.

Part IV: Run the DAP with the Sample Web Application “WebApp”

You need Docker to run the DAP. The following is an example docker-compose.yml file to run the DAP. You may need to log in to our container registry to download the image of the DAP and the sample web application, called “WebApp” in the docker-compose file. See Step3: Configure DAP and SSO Integration for more details. Replace marked #### with the recorded Provisioning Key and Secret in the previous step.

version: ‘3’

services:
  datawiza-access-broker:
    image: registry.gitlab.com/datawiza/access-broker
    container_name: datawiza-access-broker
    restart: always
    ports:
      – “9772:9772”
    environment:
      PROVISIONING_KEY: #############################
      PROVISIONING_SECRET: #############################

  WebApp:
    image: registry.gitlab.com/datawiza/header-based-app
    container_name: ab-demo-header-app
    restart: always
    ports:
      – “3001:3001”

 

After executing docker-compose -f docker-compose.yml up -d, the Datawiza Access Proxy and the WebApp should be up and running.

Part V: Test the Application

Open a browser and type in http://localhost:9772/. The login page of the WebApp should be shown:

Sign on page

Click Sign in with SSO, and then input the organization domain acme. It will automatically redirect you to the Azure AD to login.

Sign on page

After entering the credentials, you should be able to login successfully and see the homepage of the WebApp.

Now you can click the logout button and try to log in using OKTA. This time you input globex on the organization domain. After clicking the continue button, it will redirect you to Okta to login.

(Optional) Part VI: Pass User Attributes to the WebApp

The DAP gets user attributes from IdP and can pass the user attributes to the application via header or cookie.

Please follow the instructions of Step4: Pass User Attributes to pass the user attributes to the WebApp, which is expecting:

  • email
  • firstname
  • lastname

If you want to get user’s groups, you need to add groups in custom claim. You can see Add Claims in ID Token and Create Claims

for more details.

After successfully configuring the user attributes and adding groups in Okta claim and the DCMC configuration, you should see the green check sign for each of the user attributes as follows.

Conclusion

In this tutorial, you learned how to use Datawiza to configure B2B SSO logins for a SaaS app using OKTA and Azure AD as the Identity Providers. 

This is only a small sampling of what Datawiza can do. See Datawiza’s online docs or official website for much more information. You can also get a free trial by signing up/in here!

Written by the Datawiza team — hope you enjoyed! Join us if you have any questions or need any help on our Discord server.