Qlik Community

Qlik Sense Documents & Videos

Documents & videos about Qlik Sense.

How To: Configure Qlik Sense Enterprise SaaS to use Azure AD as an IdP


How To: Configure Qlik Sense Enterprise SaaS to use Azure AD as an IdP


  • Step-by-step instructions for implementing Azure AD identity provider connectivity in Qlik Sense Enterprise SaaS.
  • Configuring an App registration in Azure AD.
  • Configuring group claims when Azure AD Connect is implemented.


Please make sure to have the following before starting this process:

  • Microsoft Azure account
  • Microsoft Azure Active Directory instance
  • Qlik Sense Enterprise SaaS tenant

Helpful vocab

Throughout this tutorial, some words will be used interchangeably.

  • Qlik Sense Enterprise SaaS: Qlik Sense hosted in Qlik’s public cloud
  • Microsoft Azure Active Directory: Azure AD
  • Tenant: Qlik Sense Enterprise SaaS tenant or instance
  • Instance: Microsoft Azure AD
  • OIDC: Open Id Connect
  • IdP: Identity Provider

Tutorial sections

This is a long tutorial with many clicks. It’s broken up into sections to make it easier to skip the desired set of instructions:

Considerations when using Azure AD with Qlik Sense Enterprise SaaS 


Configure Azure AD

Create the app registration
Create the client secret
Add claims to the token configuration
Optional: add group claims
Collect Azure AD configuration information

Configure Qlik Sense Enterprise SaaS IdP


Considerations when using Azure AD with Qlik Sense Enterprise SaaS

  • Qlik Sense Enterprise SaaS allows for customers to bring their own identity provider to provide authentication to the tenant using the Open ID Connect (OIDC) specification (https://openid.net/connect/)


  • Given that OIDC is a specification and not a standard, vendors (e.g. Microsoft) may implement the capability in ways that are outside of the core specification. In this case, Microsoft Azure AD OIDC configurations do not send standard OIDC claims like email_verified. This will create warnings during validation but does not impact the overall functionality of the identity provider in a tenant.


  • Native Azure AD groups materialize as unique identifiers in sent claims. Group name resolution requires contacting the Microsoft Graph API with the user’s ID token. Qlik Sense Enterprise SaaS does not provide the capability to contact the API to perform resolution.


  • Groups synchronized from an on-premises Active Directory to Azure AD using Azure AD Connect are available with resolved group names using the optional groups claim configuration in Azure App registration. Please see the section Optional: Adding groups claim for instructions.



This document will guide the reader through adding the necessary application configuration in Azure AD and Qlik Sense Enterprise SaaS identity provider configuration so that Qlik Sense Enterprise SaaS users may log into a tenant using their Azure AD credentials.

Read the Considerations section to understand the limitations of Azure AD group claims or want to learn more about the OIDC specification. Steps with pictures will provide the instructions above the picture.

Configure Azure AD

Create the app registration

1. Log into Microsoft Azure by going to https://portal.azure.com.

2. Click on the Azure Active Directory icon in the browser. The overview page for the active directory will appear.


3. Click on the App registrations item in the menu to the left.



4. Click the New registration button at the top of the detail window. The application registration page appears.


5. Begin by adding a name in the Name section to identify the application. In this example, the name of the hostname of the tenant is entered along with the word OIDC.


6. The next section contains radio buttons for selecting the Supported account types. In this example, the default – Accounts in this organizational directory only – is selected.


7. The last section is for entering the redirect URI. From the dropdown list on the left select “web” and then enter the callback URL from the tenant. Enter the URI https://<tenant hostname>/login/callback.



8. Complete the registration by clicking the Register button at the bottom of the page.



9. Click on the Authentication menu item on the left side of the screen.



10. On the middle of the page, the reference to the callback URI appears. There is no additional configuration required on this page.



Create the client secret

11. Click on the Certificates and secrets menu item on the left side of the screen.


12. In the center of the Certificates and secrets page, there is a section labeled Client secrets with a button labeled New client secret. Click the button.



13. In the dialog that appears, enter a description for the client secret and select an expiration time. Click the Add button after entering the information.


14. Once a client secret is added, it will appear in the Client secrets section of the page. Copy the value of the client secret and paste it somewhere safe. After saving the configuration the value will become hidden and unavailable.



Add claims to the token configuration

15. Click on the Token configuration menu item on the left side of the screen.



16. The Optional claims window appears with two buttons. One for adding optional claims, and another for adding group claims. Click on the Add optional claim button.


17. For optional claims, select the ID token type, and then select the claims to include in the token that will be sent to the Qlik Sense Enterprise SaaS tenant. In this example, ctry, email, tenant_ctry, upn, and verified_primary_email are checked. None of these optional claims are required for the tenant identity provider to work properly.



18. Click the Add button to complete the optional claim selection. The claims will appear in the window.



Optional: add group claims

19. Click on the Add groups claim button.

20. In the Edit groups claim panel, select the types of groups to send in the token. In this example, only the security groups are necessary.


21. Expand the ID accordion in the Customize token properties section and select the format the groups in the claim should be formatted. In this example, the sAMAccountName is the “friendly”, recognizable name of the group.


*The groups claim provided in this functionality will work only for groups that have been synchronized from an on-premises Active Directory through Azure AD Connect. This setting has no relevance to native Azure AD groups and will not resolve group names from Azure AD group ids.


22. Click the Add button to save the configuration.


23. Once all of the optional claims are added the Optional claims page may resemble this example.



Collect Azure AD configuration information

24. Click on the API permissions menu item on the left side of the screen.


25. In the Configured permissions window confirm the User.Read option is in the list.


26. Click on the Overview menu item to return to the main App registration screen for the new app. Copy the Application (client) ID unique identifier. This value is needed for the tenant’s idp configuration.


27. Click on the Endpoints button in the horizontal menu of the overview.


28. Copy the OpenID Connect metadata document endpoint URI. This is needed for the tenant’s IdP configuration.



Configure Qlik Sense Enterprise SaaS IdP

29. With the configuration complete and required information in hand, open the tenant’s management console and click on the Identity provider menu item on the left side of the screen.


30. Click the Create new button on the upper right side of the main panel.


31. Select Interactive from the Type drop-down menu item, and select ADFS from the Provider drop-down menu item.


32. Scroll down to the Application credentials section of the configuration panel and enter the following information:

a. ADFS discovery URL: This is the endpoint URI copied from Azure AD.

b.Client ID: This is the application (client) id copied from Azure AD.

c. Client secret: This is the value copy and pasted to a safe location from the Certificates & secrets section from Azure AD.

d. The Realm is an optional value used if you want to enter what is commonly referred to as the Active Directory domain name.


33. Scroll down to the Claims mapping section of the configuration panel. There are five textboxes to confirm or alter.



33a. The sub field is the subject of the token sent from Azure AD. This is normally a unique identifier and will represent the UserID of the user in the tenant. In this example, the value “sub” is left and appid is removed. To use a different claim from the token, replace the default value with the name of the desired attribute value.



33b. The name field is the “friendly” name of the user to be displayed in the tenant. For Azure AD, change the attribute name from the default value to “name”.


33c. In this example, the groups, email, and client_id attributes are configured properly, therefore, they do not need to be altered.



34. Scroll down to the Advanced options and expand the menu. Make sure the Scope textbox includes openid, profile, and email. If this information is missing from the Scope field, IdP validation will fail.



35. The Post logout redirect URI is not required for Azure AD because upon logging out the user will be sent to the Azure log out page.

36. Click the Save button at the bottom of the configuration to save the configuration. A message will appear confirming intent to create the identity provider. Click the Save button again to start the validation process.


37. The validation procedure begins by redirecting the person configuring the IdP to the login page for the IdP.


38. After successful authentication, Azure AD will confirm that permission should be granted for this user to the tenant. Click the Accept button.


39. If the validation fails, the validation procedure will return a window like the following.


40. If the validation succeeds, the validation procedure will return a mapped claims window. In this example, there is a warning because the email claim isn’t valid. This is a result of Azure AD not following the OIDC specification. The specification states a claim named “email_verified” be sent as a default claim. This warning does not impact the usability of the IdP or user accounts in the tenant.


41. After confirming the information is correct, the account used to validate the IdP may be elevated to a TenantAdmin role. It is strongly recommended to do make sure the box is checked before clicking continue.



42. The next to last screen in the configuration will ask to activate the IdP. By activating the Azure AD IdP in the tenant, any other identity providers configured in the tenant will be disabled.


43. ‘nuff said.


44. Please log out of the tenant and re-authenticate using the new identity provider connection. Once logged in, change the url in the address bar to point to https://<tenanthostname>/api/v1/diagnose-claims. This will return the JSON of the claims information Azure AD sent to the tenant. Here is a slightly redacted example.





While not hard, configuring Azure AD to work with Qlik Sense Enterprise SaaS is not trivial. Most of the legwork to make this authentication scheme work is on the Azure side. However, it's important to note that without making some small tweaks to the IdP configuration in Qlik Sense you may receive a failure or two during the validation process.

And yes, it does not sit right that native Azure AD groups continue to come over as guids. But as stated in the Considerations section, unfortunately Microsoft does not make it easy to resolve groups without taking an extra step with a call to their Graph API.


Hi Jeff,


I hope all is well. Awesome guide, we set this up a couple of months ago and got it to work. We intended to sync multicloud to a onprem solution (where we have SAML auth). In general, works fine, but when we use the QSEoCS at x.eu.qlikcloud.com there is no identity mapping from the on-prem solution. So users exists with the same credentials (sub) as DOMAIN\user@domain.com on both on-prem and cloud, but when deploying apps to a cloud environment the apps don't get any ownership, which is a bit annoying. When setting up the idp on QSEoCS it actually says "The email claim is not valid. The identity mapping feature will not work for the users in the tentant" which would explain the behavior. Any idea of a workaround to actually hard-core/manually add the claim "email_verified" as true? It appears to be the only thing missing.





Very similar issue as @erikadvectas ... 

We are working through changing a customer from one Azure AD tenant to another. Changing IdP in QSEoCS is apparently fairly seamless as long as the email addresses of the new & old users match. However with this config, the email addresses, whilst passed in the authentication process, don't show in the user list and this seems to be a problem.  I assume this must be to do with the missing email_verified field. Is there any way to manually add a mapping for this like you would with SAML or similar? I find it weird there's no box to map a claim to that field - although perhaps since it's part of the underlying OpenID Connect spec it's meant to be included by default.

Contributor III
Contributor III

Does anyone was able to retrieve users email and picture from the azure AD?


@sfbi No - I wasn't able to get email address or picture. The email address appears to be to do with the lack of email_verified field coming from Azure. I haven't managed to figure out if it's possible to send a static value as part of the auth process for this, so email addresses can show in QSE SaaS... As for pictures, I haven't looked but assume it's a similar issue with it not being passed by Azure.


I wasn't either. I added a support case but nothing they could do, so I added an idea. Feel free to upvote it:



If you have any input on the actual "idea", please let me know.




@erikadvectas  and @AlexOmetis  I've been trying to figure out if there is a way in Azure to add an email_verified claim. And I found one! But... it adds a prefix in the claim name "extn." Here's the document: https://docs.microsoft.com/en-us/powershell/azure/active-directory/using-extension-attributes-sample...

@erikadvectas  I commented on your idea and it's a good place to put it.

This issue along with groups is aggravating for me as much as I know it is for you. We are researching what the art of the possible is without a large amount of customization per IdP.

I hate to say stay tuned so I'll say "keep a sharp eye". If you see something that may work let me know!

Contributor III
Contributor III

I was able to get the email with "email" claim. Still, IDP config won't create user with the current email. All auth user emails are set as null.


Profile Picture:
It look likes azure ad doesn't support profile picture as claim.

picturePhoto is supported using MicrosoftGraph only:

have no idea on how to get it working on IDP...

Contributor III
Contributor III


I suggest you to add at the top of this How To, the advise about SESSION ACCESS... it is an important step that is described on help, but some people (like myself) might ignore prior to implement the IdP.


@sfbi if I play it back you mean changing the SUB to something a bit more friendly than the actual subject. Like Email or something else.  Good feedback to add to the considerations section.




Contributor III
Contributor III

Here is an example on Users MC page. The first line is the new user create from the Azure AD IdP (no email) and the second line is the "old" QlikID user created before implement the IdP... 


It's not affecting the usability, but when you need to add a lot of users, it might get a lit bit complicated to manage it by users Names instead users Emails. 

What I don't understand is why I'm getting the email from the email claim, and its not been set as user email on the MC User page.

Also, I added the folowing API permissions at Azure AD.

Thank you

Version history
Revision #:
10 of 10
Last update:
‎2020-05-22 12:52 PM
Updated by: