Skip to main content

About 2 min

In this tutorial, we will use the Datawiza Access Proxy (DAP) to enable SSO and granular access control for a sample header-based web app. We will use DAP's side deployment mode, which means that our application and the Access Proxy are running on the same server.

  • The application will run on localhost:3001.
  • The DAP will run on localhost:9772, which means the traffic to the app will first reach the DAP (running on port 9772) and then be proxied to the application (running on port 3001).
  • We will provide the Docker images for the DAP and this header-based application.

Create an Auth0 Application

Follow IdP Configuration Guide: Auth0open in new window to register an Application in Auth0 dashboard and get the following values:

  • Domain
  • Client ID
  • Client Secret

These values will later be used to set up the Datawiza Access Proxy in the Datawiza Cloud Management Console.

Create an Application on Datawiza Cloud Management Console (DCMC)

You'll now need to create an application and generate a pair of PROVISIONING_KEY and PROVISIONING_SECRET for your application on the DCMC.

Follow Datawiza Cloud Management Consoleopen in new window for configuration steps.

Run DAP With a Header-Based Application

You can use either Docker or Kubernetes to run DAP. The following is an sample docker-compose.yml file. You will need to login to our container registry to download the images of the DAP and the header-based app. See Configure DAP and SSO Integrationopen in new window for more deployment-specific steps, or alternatively Deploy DAP with Kubernetesopen in new window for Kubernetes-specific instructions.

version: '3'

services:
  datawiza-access-broker:
    # Access Proxy image that we pulled from container registry
    image: registry.gitlab.com/datawiza/access-broker
    container_name: datawiza-access-broker
    restart: always
    ports:
      - "9772:9772"
    environment:
      # Replace below with your PROVISIONING_KEY and PROVISIONING_SECRET
      PROVISIONING_KEY: #############################
      PROVISIONING_SECRET: #############################

  header-based-app:
    # Sample Header-Based App image that we pulled from container registry
    image: registry.gitlab.com/datawiza/header-based-app
    container_name: ab-demo-header-app
    restart: always
    ports:
      - "3001:3001"

Run the following command to start the app:

docker-compose -f docker-compose.yml up

The header-based app should now have SSO enabled with Auth0. Open a browser and navigate to localhost:9772open in new window. You should see the Auth0 login page. Note that if you are already logged in to Auth0, you may need to log out to see the login page.

Pass User Attributes to the Header-Based App

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

Follow the Pass User Attributesopen in new window guide to pass user attributes to the header-based app. In this case, the application is expecting:

  • email
  • firstname
  • lastname
  • groups

Since the Auth0 default Authorization Coreopen in new window doesn't support groups, we instead set a role for testing purposes.

You can follow the update user info by APIopen in new window instructions to add family_name and given_name to the test user.

After successfully configuring the user attributes, you should see the green check sign for each of the user attributes as follows:

Achieve Granular Access Control

You can configure access control to an application based on user's attributes (e.g., groups, department) and other metadata of a request (e.g., URL, IP, http method, access time).

Refer to Achieve Granular Access Controlopen in new window for detailed instructions on how to set up access policies. An example rule configuration is provided below:

  1. Create a user in Auth0, put them in hr role, and assign this person to your application on Auth0.
  2. Create the following two rules:
    • hr path can only be accessed by hr role.
    • sales path can only be accessed by sales role.
  3. Verify that the user you created can only access hr page in the header-based app, but cannot access the sales page. If you try to access the header-based application on localhost:9772 in your browser, you should get the following screenshot.

On localhost:9772/hropen in new window:

On localhost:9772/salesopen in new window: