Using Multiple concurrent Identity Providers with Qlik Cloud

Leigh_Kennedy — Thu, 22 May 2025 22:45:34 GMT

Content

Introduction

Qlik Cloud is designed to support a single interactive Identity Provider (IdP) per tenant.

As my friend @Dave_Channon explains in Why Qlik doesn't support multiple interactive identity providers on a Qlik Cloud tenant, only one interactive identity provider can be enabled at any one time for Qlik Cloud (Which includes Qlik Cloud Analytics and Qlik Talend Cloud Data Integration). Without restating the points Dave made, the short answer is we do not plan to change this as we don't consider this good practice.

So, if your organisation needs to support multiple IDPs, what can you do? There are many use-cases that require this, such as:

Providing access to external parties without adding them to your Organisation's IDP.
OEM use-cases with customers who have their own IDPs
Company mergers (This is one we've used ourselves a few times)

These are just a few examples but this is a very common use case for most large organisations. So what do you have to do? Well, you could solve this with multiple tenants, but that's often a high-maintenance solution and isn't ideal. That's why, as Dave mentioned, we recommend that customers use Identity federation to address this.

Identity Federation

Identity federation is a mechanism that links a user's identity across multiple identity management systems, allowing them to access different applications and resources without needing separate logins or credentials. Almost all major providers support this. For example, these IDPs all support federation:

Microsoft Entra ID
Google Workspace
Okta
Auth0
Ping Identity
OneLogin
Amazon Cognito
IBM Cloud Identity
Cisco Duo
Microsoft ADFS (Active Directory Federation Services)
KeyCloak

Case Study - KeyCloak Federating with Auth0

So, how complex is this and how does it look to my users and Qlik Cloud tenant?

I set up a simple example of this using KeyCloak and Auth0. The way this works is:

The user tries to connect to their Qlik Cloud tenant
Qlik sends the user to KeyCloak for authentication
KeyCloak provides the user the option to either log in directly with KeyCloak or be directed to Auth0 to log in.
After logging in, KeyCloak received user metadata, such as e-mail, groups, etc.
KeyCloak then provides this to Qlik Cloud
The user gains access to Qlik Cloud.

While this is not a 'how-to' article, at a high level, what I've set up is:

KeyCloak is the IDP for my Qlik Cloud tenant:
In Keycloak I have my Groups and users set up as group members:
And I have also set up Auth0 as an Identity provider for KeyCloak:
And hard-coded the 'External' group to any users coming from Auth0:

This may not always be what you want to do. You may wish to use the groups coming from Auth0 also, and that is possible, but not needed for my use case.

Finally, here are my users set up in Auth0:

User Experience and Security

So what happens when I log in?

First, let's look at jane@qmi.com. Jane is set up in KeyCloak. After opening the URL for our Qlik Cloud tenant, I am redirected to the keycloak login screen:

I can log in directly here or choose to sign in with Auth0. Jane logs into KeyCloak directly and is then sent back to the Qlik Tenant:

To understand what information Qlik Clouid has been provided, we can append "/api/v1/diagnose-claims" to the end of our tenant URL. This will show us the metadata Qlik has received about Jane, such as:

We are most concerned about Jane's groups, as that is how we will control access. Jane is in the Finance and Human Resources groups.

In our tenant, we have the following spaces and access rules:

Space Name	Space Type	Groups with Access
External	Managed	External: Read Only
External_development	Shared	Finance: full access Sales: full access Human Resources: full access
Finance	Shared	Finance: Read Only
Sales	Shared	Sales: Read Only
Human Resources	Shared	Human Resources: Read Only

So Jane sees the Finance, Human Resources, and External_development spaces:

What happens when a user logs in through Auth0? This time joe.public@company1.com will log in via Auth0:

As this user has never logged in before, KeyCloak asks for some details:

After logging in, we can look at the "/api/v1/diagnose-claims" endpoint to see the user's metadata. We see the External group, which we hard-coded for Auth0 users in KeyCloak:

And when looking at the user's space access, we can only see the External space as expected:

Final Thoughts

This is a simple example I put together in a couple of hours. I selected KeyCloak and Auth0 simply because I have some experience with them - most IDPs could do this (and also, I could have chosen to reverse the order and have Auth0 as the primary IDP).

Neither Qlik nor I make any specific recommendations as to what identity providers customers should use.

While we haven't looked at it here, it's also possible to use social services (such as LinkedIn, GitHub, Facebook, etc.) as external Identity providers, which may well be a better solution for some use-cases. And you can support many of these at the same time as your needs require.