# Enable SSO for Multiple Applications with Different Identity Providers

# Preview

In this tutorial, we will use the DAB to enable SSO for two Flask applications serving static HTML. For our scenario, one web app will be the homepage for the managers of our company, while the other web app will be the homepage for the engineers. The goal of this tutorial is to see how we can add multiple applications to a single deployment within the Datawiza Cloud Management Console (DCMC), and how we can associate different Identity Providers to each of our applications.

  • Both of our applications will be running on our local docker network, 172.17.0.1. The manager homepage will run on 172.17.0.1:3001 and the engineer homepage will be on 172.17.0.1:3002.
  • The DAB will run on localhost in a container and expose two ports: 9772 and 9773. Traffic to either of our applications will reach DAB first and then be proxied to our applications. Traffic to localhost:9772 will be proxied to 172.17.0.1:3001 and traffic to localhost:9773 will be proxied to 172.17.0.1:3002.

# Part I: Identity Provider Configuration

You will need to register each application with an Identity Provider. For this exercise, we will register the app for the managers with Azure AD and the app for the engineers with Okta. Please follow IdP Configuration Guide: Microsoft Azure AD and IdP Configuration Guide: Okta for specific configuration instructions.

# Part II: Create Deployment and Applications on Datawiza Cloud Management Console (DCMC)

After configuring your desired Identity Provider, we need to create a new deployment on the DCMC which will contain our two applications. We will also generate a keypair (PROVISIONING_KEY, PROVISIONING_SECRET) in order for the DAB to get the latest configurations and policies from the DCMC.

# Sign Into DCMC

  1. Login to the DCMC. If you need a username and password, please contact info@datawiza.com.

DCMC login

# Create New Deployment

  1. Click the orange button + Create Deployment and specify a Name and a Description. Click Save.

New deployment

# Provisioning Keys

  1. Create your set of provisioning keys. This enables the DCMC to verify the DAB's authenticity. Specify a Key Name and set the Expires field to be 1 month later.

Provisioning Key

# IdP Configuration

  1. Choose Microsoft Azure Active Directory from the drop down menu. We'll add Azure AD first, and then add Okta as an additional IdP later.

Populate the fields of the form with the keys/values obtained from IdP Configuration Guide: Microsoft Azure AD. Azure IdP

# Add Manager Application

Configure our application for the managers with the following fields:

  • Name: Manager App
  • Public Domain: http://localhost:9772
  • Upstream Server: http://172.17.0.1:3001
  • Select Create.

Add Manager App

# Note Down Provisioning Keys

Note down your PROVISIONING_KEY and PROVISIONING_SECRET. We will need these values later when deploying the DAB.

Obtain Provisioning Key

# Add Engineer Application

  1. Select the Applications tab. Select the orange button Create Application. You should already see Manager App in the deployment.

New application

  1. Configure our application for the engineers with the following fields:
  • Name: Engineer App
  • Public Domain: http://localhost:9773
  • Upstream Server: http://172.17.0.1:3002
  • Select Create.

You should now see both the Manager App and the Engineer App within the deployment.

Application configured

# Assigning IdPs to our Applications

  1. Return to the Applications tab. Select the Manager App, and go to IdP Configuration. Select Assign IdP. From the drop down menu, you should see the IdPs that we have added to the DCMC. Assign Azure AD to the Manager App and Okta to the Engineer App.

Assign IdP

# Part III: Run DAB With Our Applications

We can use either docker or docker-compose to run the DAB. The following is an example of a docker-compose.yml file. You may need to login to our container registry to download the images of the Access Broker. See Step3: Congifure DAB and SSO Integration for more details.

version: '3'

services:
  datawiza-access-broker:
    # Using the latest image
    image: registry.gitlab.com/datawiza/access-broker:latest
    container_name: datawiza-access-broker
    restart: always
    ports:
      - "9772:9772"	
      - "9773:9773"
    environment:
      PROVISIONING_KEY: #########################
      PROVISIONING_SECRET: #########################

After executing docker-compose -f docker-compose.yml up, Manager App should have SSO enabled with Azure AD. Open a browser and visit http://localhost:9772/. You should see the Azure AD login page as follows:

Azure AD login

If you are seeing the Azure AD login page but are unable to login (Microsoft keeps asking for your username and password repeatedly), ensure that you have created a user for your AD domain. Logging in with the root account will not work. Your username should be in the form of user@your_domain.onmicrosoft.com. Note that if you are already logged into Azure AD in your browser, you may need to logout to see the login page.

After successfully logging in, we can see our manager homepage:

Manager homepage

To test out the engineer homepage, we visit http://localhost:9773. We are greeted with the following Okta login page:

Okta login

After successfully logging in, we can see our engineer homepage:

Engineer homepage

# Summary

In summary, we have seen how to deploy the DAB and implement SSO alongside multiple applications, each using different identity providers. Please refer to Step4: Pass User Attributes and Step5: Achieve Granular Access Control to interact with the other features provided by the Datawiza Access Broker.