Enable SSO and Granular Access Control For A Header-Based Web App with Generic OIDC

Preview

In this tutorial, we will use the Datawiza Access Proxy (DAP) to enable SSO and granular access control for a header-based web App. The IdP we will use is generic OIDC, which means any IdP follows the general OIDC authorization flow. We will use DAP's sidecar deployment mode, which means DAP and this app 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 reach 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 this header-based application.

Part I: Register an OIDC application

You will need to register an OIDC application in your IdP console and get the following values for this application:

• Client ID
• Client Secret
• Issuer
• Scopes
• OIDC Logout URL

You need to check IdP's docs for how to get these values, we use Microsoft Entra ID (Azure AD) as an example here:

Client ID

You can find the Client ID in your App registration Overview:

Client Secret

You can create a new Client Secret in Certificates & secrets of your App registration:

Scopes

We have pre-configured four basic OIDC scopes: profile, email, openid, and offline_access. You can customize these values based on your IdP requirements. You can see here for more information about these scopes in Microsoft Entra ID.

Issuer

Issuer is the URL that the OpenID provider asserts is its issuer identifier. For Microsoft Entra ID, the issuer should be like https://login.microsoftonline.com/{tenant}/v2.0. The value of {tenant} varies based on the application's sign-in audience. You can see here for more details

OIDC Logout URL

OIDC Logout URL is used to log out a user. For Microsoft Entra ID, the value should be like https://login.microsoftonline.com/common/oauth2/v2.0/logout?post_logout_redirect_uri={your_logout_redirect_uri}, the {your_logout_redirect_uri} is the URL that the user is redirected to after successfully signing out. You can see here for more details.

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

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

You need to create an application and generate a keypair of (PROVISIONING_KEY, PROVISIONING_SECRET) for this app on the DCMC.

Please follow Step2 : Datawiza Cloud Management Console to configure.

Part III: Run DAP With a Header-Based Application

You can use either Docker or Kubernetes to run DAP. The following is an example docker-compose.yml file. You may need to login to our container registry to download the images of DAP and the header-based app. See Step3 : Configure DAP and SSO Integration for more details or Deploy DAP with Kubernetes for Kubernetes-specific instructions.

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: #############################

  header-based-app:
    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, the header-based app should have SSO enabled with your IdP. Open a browser and type in http://localhost:9772/. You should see the IdP login page

Part IV: Pass User Attributes to the Header-Based App

DAP gets user attributes from IdP and can pass the user attributes to the application via header or cookie. For Generic OIDC, we will only fetch user attributes from ID Token. You may need to check IdP's docs for how to add custom attributes. For example, you can see here for how to do it in Microsoft Entra ID.

Please follow the instructions of Step4 : Pass User Attributes to pass the user attributes to the header-based app, which is expecting:

• email
• firstname
• lastname
• groups

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

Part V: 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).

Please reference Step5 : Achieve Granular Access Control for detailed instructions on how to set up access rules. You can practice the rule configuration using the following example.

A Rule Example

1. Create a user in your IdP, put it in hr group.

2. Create the following two rules:

• hr path can only be accessed by hr group.
• sales path can only be accessed by sales group.

1. Verify that the user you created can only access hr page in the header-based app, but cannot access sales page. Trying to access the header-based application on localhost:9772 in your browser, you should get something similar to the following screenshots.