Enable B2B SSO for homegrown App retaining the local username authentication

Overview

Business-to-Business (B2B) Single Sign-On (SSO) plays an integral role for proprietary applications serving enterprise clients. This tutorial focuses on a specific scenario where we retain the local username and password authentication, while concurrently integrating B2B SSO. To achieve this, we will leverage the capabilities of the Datawiza Access Proxy (DAP).

For the purpose of this tutorial, we consider an existing web application, “WebApp,” which currently employs username-based authentication. The objective is to onboard two enterprise clients, each utilizing different SSO platforms. Acme Corp. uses Microsoft Entra ID (Azure AD) for its SSO operations, while Globex Corp. leverages Okta, but still keeping the current username-based authentication.

We will show how to use the DAP to enable SSO for WebApp to serve these two customers. We'll need to do some minor code changes to the WebApp, but you will see it is quite simple and straightforward.

• WebApp will run on localhost:3001, and it can receive HTTP headers to retrieve user information passed by the DAP.
• DAP will operate 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).

Steps Description

Prerequisites

Before starting this tutorial, you need to have the following:

• A Datawiza account. If you don't have one, sign up here.
• A Docker environment. If you don't have it, follow the instructions to get it.

Part I: Microsoft Entra ID Configuration

Acme Corporation must register the application in the Azure Portal and obtain the following values for this application:

• Client ID
• Client Secret
• Tenant Id

These values will later be used to configure the DAP in the Datawiza Cloud Management Console (DCMC). To obtain these keys/values, please follow the instructions provided in the IdP Configuration Guide: Microsoft Entra ID.

Part II: Okta Configuration

Similar, Globex Corporation must register the application in the Okta Portal and obtain the following values for this application:

• Client ID
• Client Secret
• Okta Org

These values will later be used to configure the DAP in the Datawiza Cloud Management Console (DCMC). To obtain these keys/values, please follow the instructions provided in the IdP Configuration Guide: Okta.

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

1. Sign in to the Datawiza Cloud Management Console.

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

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

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

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.

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

   Property	Value
   App Type	Web
   Name	Enter a unique application name. For example, you can use the WebApp.
   Application URL	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	The URL and port of your Web app. Here we use http://docker.host.internal:3001.

10. Select Create.

11. Switch to the IdP Configuration tab inside your application settings, Click the Create IdP button under Domain Hint.

12. In the Add IdP dialog box, add an organization domain. Here we use acme. Select the Microsoft Entra ID as Identity Provider. Switch off Automatic Generator. Enter all the information from Part II. Then click the Save button.

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

14. Your IdP configuration will now look like this.

15. Edit the rules, and change the default rule to Not Protected.

Part IV: Run the DAP with the Sample Web Application

Return to the deployment you just created, and you'll find the steps to run DAP in the Quick Start tab. Refer to the following screenshot for guidance.

The following is an example docker-compose.yml file to run the DAP. Replace marked #### with the recorded Provisioning Key and Secret from the previous step.

version: '3'
services:
  datawiza-access-proxy:
    image: registry.gitlab.com/datawiza/access-proxy
    container_name: datawiza-access-proxy
    restart: always
    ports:
      - "9772:9772"
    environment:
      PROVISIONING_KEY: #############################
      PROVISIONING_SECRET: #############################

After executing docker-compose -f docker-compose.yml up -d in your terminal, the Datawiza Access Proxy and the SaaSPortal should be up and running.

Part V: Make some code changes to WebApp

Revise the logic used to check if a user is authenticated by reading from the x-dw-user header.

Change the logout url to /datawiza/ab-logout

Add a SSO button, which is pointing to the endpoint /sso/login

Part VI: Test the Application

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

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

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.

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

(Optional) Part VI: Pass User Attributes

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 Pass User Attributes to pass the user attributes to the SaaSPortal, which is expecting:

• email
• firstname
• lastname

If you want to get user's groups, you need to add groups in custom claim. You can refer to Add Claims in ID Token for Microsoft Entra ID and Create Claims in OKTA 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 homegrown app using OKTA and Microsoft Entra ID as the Identity Providers.

This is only a small example of what Datawiza can do. See Datawiza's online docs or official website for more information. Start a free trial today by signing up here!