Datawiza

Datawiza provides the next-gen cloud-delivered Access Management as a Service (AMaaS). Its plug-and-play no-code/low-code solution seamlessly integrates apps to Auth0 to enable SSO (OIDC/OAuth and SAML) and MFA (Multi-Factor Authentication) without writing integration code.

The top use cases of Datawiza platform are:

• Seamlessly integrate apps or APIs to Auth0 without writing integration code.
• Unified, granular access control for apps, APIs and other resources in hybrid multi-cloud environments.
• Enable a zero trust architecture for apps, APIs and and other resources.

The benefits of Datawiza platform are:

• Implement Auth0 via a plug-and-play solution built by security experts.
• Free up developers' time to focus on their core capabilities instead.
• Speed up the project delivery and save on expensive engineering costs.
• Improve security posture by enabling the zero-trust architecture.

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

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

Create an Auth0 Application

Follow IdP Configuration Guide: Auth0 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 Broker 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 Console for configuration steps.

Run DAB With a Header-Based Application

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

version: '3'

services:
  datawiza-access-broker:
    # Access Broker 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:9772. 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 DAB gets user attributes from Auth0 and can pass those user attributes to the application via header or cookie.

Follow the Pass User Attributes 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 Core doesn't support groups, we instead set a role for testing purposes.

You can follow the update user info by API 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 Control 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/hr:

On localhost:9772/sales: