Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
May 13, 2024 1:21:30 AM
Jan 11, 2021 8:55:44 AM
This article provides step-by-step instructions for implementing Azure AD as an identify provider for Qlik Cloud. We cover configuring an App registration in Azure AD and configuring group support using MS Graph permissions.
It guides 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.
Content:
Throughout this tutorial, some words will be used interchangeably.
The tenant hostname required in this context is the original hostname provided to the Qlik Enterprise SaaS tenant.
Copy the "value of the client secret" and paste it somewhere safe.After saving the configuration the value will become hidden and unavailable.
In the OpenID permissions section, check email, openid, and profile. In the Users section, check user.read.
Failing to grant consent to GroupMember.Read.All may result in errors authenticating to Qlik using Azure AD. Make sure to complete this step before moving on.
In this example, I had to change the email claim to upn to obtain the user's email address from Azure AD. Your results may vary.
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.
For many of you, adding Azure AD means you potentially have a bunch of clean up you need to do to remove legacy groups. Unfortunately, there is no way to do this in the UI but there is an API endpoint for deleting groups. See Deleting guid group values from Qlik Sense Enterprise SaaS for a guide on how to delete groups from a Qlik Sense Enterprise SaaS tenant.
Qlik Cloud: Configure Azure Active Directory as an IdP
The email isn't mapping because Azure AD does not send a specific claim named "email_verified". This is a claim Qlik Sense SaaS is expecting and not getting, therefore, no mapping your email to the user account created.
We are working on adding the ability to specify the claim that represents "email_verified" so the mapping will work properly. No timeframes of course but I do have an appreciation for the urgency to implement this in SaaS.
The other thing is from your screenshot is you are showing permissions, but not the optional claims you are sending. You need to send the email as an optional claim AND the "primary_verified_email" claim as an optional claim. Once we have the customization in platform (described above) you will be able to tell Qlik Sense IdP config to look for "primary_email_verified" as the claim for email_verified.
jg
ok now I got it... all claims are set correctly and I'm geeting it at the diagnose
"verified_primary_email":["henrique@....."]
@Jeffrey_Goldberg
is it on the roadmap to allow anonymous user on SaaS?
Did anybody figure out a workaround or a solution?
Updated configuration now enables to set the email_verified on the IDP config.
PS:
for current users to get the appropriate email address at the users table (MC) and be able to be notified by emails, you'll need to exclude the current users and ask them to login again as a new user after updating the IDP config. After you'll need to allocate again spaces authorizations. (at least that was the only way for me).
That's not a good idea if you need to exclude app owners as you'll need to reset app ownership on the MC (App Tab) and republish all apps on manage spaces as you can't change it's ownership within the MC. So if you do, do it carefully.
Users IDP Entity remains the same after the new login, so you won't need to update any table used on section access (if its the case).
Nice!
I noticed that too. But using "verified_primary_email" still doesn't make Azure AD provide proper identity mapping. I belive "email_verified": true needs to be in the claims. I can verify at https://xx.eu.qlikcloud.com/api/v1/diagnose-claims that there no such attribute. Any ideas?
your are not getting the email_verified claim on the diagnose?
I'm getting both email and primary and
"email_verified":["henrique@xxxxxxx"]
"verified_primary_email":["henrique@xxxxxxxx"]
I do. And that works to add, but it doesn't help with the identity mapping for Azure AD. Tried to sync an app and it loses the owner.
understood... same here, no idea on how to manage it too...
Hi folks, allow me to chime in here. You've stumbled upon the first phase of addressing the email_verified problem some identity providers have with Qlik Sense SaaS configuration. Qlik requires email_verified as a claim in the OIDC handshake because we want to make sure the email is indeed unique and the email intended to be supplied with the credential sent from the IdP.
The email_verified input has been added to the configuration to help you point to a custom claim that you would create in your IdP that would map the custom claim to the email_verified attribute required by Qlik's OIDC implementations.
With respect to Azure AD, just because we've added the input doesn't mean Azure AD will now surface this attribute. In fact, Azure AD will not because Azure AD does not have this claim to send, full stop.
What you can do is add what is called an extension attribute to your app registration (link: https://docs.microsoft.com/en-us/powershell/azure/active-directory/using-extension-attributes-sample...) and then send this as an optional claim using the optional claims configuration in the app registration. You would then map this custom claim to the email_verified input in the Qlik Sense SaaS IdP config for Azure AD.
screenshot of azure ad:
While doable, it's an inelegant solution.
I feel this is a bit clunky, so I've asked our R&D team to investigate implementing a toggle that will set email_verified to true when using AzureAD.
This toggle, in addition to adding group resolution from AzureAD object ids from an Azure AD menu item in the IdP config will be available in the not too distant future.
When it becomes available, I will update the document.
Cheers,
Jeff G