Do you want to learn how to add Azure AD SSO to your Superset without writing code? In this step-by-step tutorial, you will learn how to integrate Superset with Azure Active Directory (Azure AD) using Datawiza to implement OIDC/OAuth SSO authentication in 5 mins. Note that Datawiza is a generic identity-aware OIDC/OAuth/SAML proxy with a centralized management console that you can easily use to achieve the same integration with other identity providers like Okta, Auth0, PingIdentity, Google, etc.
The benefits of using Datawiza
- No need to learn complex OIDC/OAuth or SAML protocols
- No need to manage refresh tokens, access tokens, or ID tokens
- No need to manage user sessions
- No need to use SDKs, call APIs or write code
- Reduce weeks or months of engineering work to hours, even minutes
- Avoid security vulnerabilities with a no-code product developed by security experts
Ready to see how easy it is? Let’s get started!
There is an official guide to running Superset using docker compose, which we will use as the example here:
docker-compose -f docker-compose-non-dev.yml up -d
Then go to http://localhost:8088
And log in with the default username/password:
As Superset suggests, we will use a simple middleware class to add Azure AD authentication. We provide a superset_config_docker.py configuration file that uses the AUTH_REMOTE_USER as the AUTH_TYPE and will authenticate the user from HTTP request headers. Meanwhile, you can create a new user through headers, and username, first name, last name, email, and role are needed:
- dw-token: By default, we will ONLY try to get user info from HTTP request header dw-token, which is a JWT. In this way, you need to provide a JWT secret used to decode the JWT. This is the RECOMMENDED approach.
- You can also store user information in headers simply by setting the variable. USER_INFO_SOURCE to IdpUserInfoSource.HEADER. We will also read HTTP request headers: username, firstName, lastName, email, role.
Use the Configuration File in Superset
- Move the file to the docker/pythonpath_env directory.
The configuration file will read the variable JWT_SECRET from env, so you need to add the key/value in the .env-non-dev file in the directory docker:
Then re-run the docker-compose file:
docker-compose -f docker-compose.yaml up -d
Introduction to the Datawiza Platform
The Datawiza Platform is a cloud-delivered platform. It includes a data plane and a control plane: Datawiza Access Proxy (DAP) and Datawiza Cloud Management Console (DCMC).
DAP is a lightweight, container-based access proxy deployed close to your application via the sidecar (agent) or gateway mode. It talks to Azure AD on behalf of your applications, so you don’t need to worry about the integration work. DCMC is a cloud-based management console where you can configure and manage the policies of DAPs. Such a SaaS-based design makes the whole platform much easier to use.
Configurations in Datawiza Cloud Management Console
Self-register an account in the Datawiza Cloud Management Console. You can easily get started with your Google account, Microsoft account, or GitHub account.
Upon logging into the Datawiza Cloud Management Console, click the orange Getting started button.
This runs a step-by-step guide for configuring your application.
Add a New Deployment
The first step of the configuration process is creating a “deployment.” A deployment is a way of organizing applications and identity providers that are associated with the same cluster as Datawiza Access Proxies. Don’t worry if this seems a bit complicated to understand in the beginning. You will get used to it when you work with it more. For now, just give your deployment a meaningful name and description.
Add a New Application
The second step is to create an application. This is simply collecting the network information of your application.
Here is an explanation of each field.
- Platform: Select WEB here.
- App Name: The name of your application. Put a meaningful name here. I use Superset demo App.
- Description: A meaningful description for you to understand this application.
- Public Domain: This is how your user will access your application. Normally it’s the URL in the address bar. You can use http://localhost if you are running locally. Be sure to add the port if you have a non-standard one. We use http://localhost:9772 as an example.
- Listen Port: This is the port that the Datawiza Access Proxy listens on. For simplicity, you can use the same port as the one in Public Domain above if you are not deploying the Datawiza Access Proxy behind a load balancer.
- Upstream Servers: This configuration tells Datawiza Access Proxy where the actual Superset resides, put http://host.docker.internal:8088.
- If you use the DAP in sidecar mode and your application is running on http://localhost:8088 on Mac or Windows, then set the upstream server to http://host.docker.internal:8088 (Docker 18.03+).
- If your application is running on Linux, use ip addr show docker0 to get docker host IP (e.g., 172.17.0.1) and then set the upstream server to http://172.17.0.1:8088 (see this for more details).
Add a New Identity Provider
The third step is to fill in the identity provider information. For Azure AD, we offer a more convenient way to integrate Azure AD with DCMC, which can create a new application on your behalf in your Azure tenant.
Here is the explanation of each field.
- Name: A reasonable name for your identity provider.
- Protocol: Modern identity providers support OIDC, and so does Azure AD. Therefore I use OIDC here.
- Identity Provider: Select the one that you are using, e.g. Microsoft Azure Active Directory.
- Automatic Generator: Whether to use one-click integration, which will create a new application on your behalf in your Azure tenant.
- Supported account type: Put restrictions on who can use this application.
- Tenant ID: If you want to create the Azure AD application in a specified tenant, you can enter the tenant ID here.
Click on Create to proceed.
Log in to your Azure AD account. You will be asked to consent to permission to automatically create a new application on your behalf in your Azure tenant. Accept the permission
Start the Access Proxy
The last step of this guide will provide you with the environment configurations. Here you will see the Provision Key and Provision Secret.
Follow the steps (1, 2, and 3 below) on the page to log in to our docker registry, pull the Access Proxy image, and use the docker-compose.yml file we provided to start the DAP.
Click Done, then you will be redirected to the configuration page. Click the Application tab and click the application:
Click Attribute Pass and Add new attribute pass:
Add basic user info attribute pass in the type of JWT:
Go to Advanced tab:
Scroll down, select Use your custom secret as the JWT Secret Option and enter the JWT Secret. The secret should be the same as the jwt_secret set in the Superset env file.
docker-compose -f docker-compose.yml up -d
In your browser, hit the Public Domain URL as you set previously. You should then see the identity provider login page.
Note that if you are already logged into Azure AD in your browser, you may need to log out to see the login page.
After logging in to Azure AD, the Superset will be shown.
Go to profile page: