STT - Troubleshooting Authentication in Qlik Cloud

[Troy_Raney]

Environment

• Qlik Cloud
• Qlik Sense Client Managed

Transcript

Hello and welcome to the December edition of Techspert Talks. I'm Troy Raney and I'll be your host for today's session. Today's presentation is Troubleshooting Authentication in Qlik Cloud with Damien Villaret. Damien, why don't you tell us a little bit about yourself?
Hi everyone. My name is Damien. I'm working at Qlik as a Principal Technical Support Engineer and my main focus is Qlik Sense Integration, API mashups and extensions, and Authentication. I've been working with Qlik since 2013.
Great. All right, today we're going to take a look at authentication; how that works with Qlik Cloud. We're going to talk about the different supported methods that are out there for setting up your custom Identity Provider. Damien is going to walk us through a demo of setting that up and talk about some best practices; and also look at how to troubleshoot some common issues that customers might run into. So Damien, for those of us who aren't that familiar; could you please walk us through what the authentication workflow looks like for Qlik Cloud?
Sure. They are mainly two types of workflows that we use in Qlik Cloud; and the first one is the one that is using the User Info endpoint.
Okay.
The basic workflow here is that the user will first access Qlik Cloud; Qlik Cloud will redirect the user to the Identity Provider, to the authorized endpoint; on that URL the user will authenticate by whatever method is set on the Identity Provider; and the Identity Provider will send the user back to Qlik Cloud at the Callback URL. So those steps all happen through the user browser through redirection.
Okay. So it all stays in the same session, same tab, bouncing the user back and forth a bit?
Yes. That's correct.
All right.
Then Qlik Cloud will request an Access Token with authorization code; and with that Access Token it will fetch the User Information to the User Info endpoint directly from Qlik Cloud. And that's why we need an outgoing connection to the Identity Provider.
Okay. And you mentioned a second workflow?
The second method is with ID Token, and the workflow is pretty much similar. But here Qlik Cloud will just request the ID Token from the Identity Provider, and will read the User Information directly from the ID Token.
And what determines which method Qlik Cloud will use?
So, we are using User Info for most of the IDPs here.
Okay.
Except for ADFS and Azure AD.
Okay, so it's the chosen Identity Provider that determines which authentication workflow is used?
Yes, and that was also a design choice in Qlik Cloud.
I had a quick question: isn't the ID Token what Qlik Sense uses for Windows?
That's correct, and Qlik Sense for Windows when you use OIDC authentication, it's always using ID Token. It's a generic workflow that just using ID Token every time.
Okay. And all these methods are when we're setting up a custom IDP, and not using Qlik ID right? Just a high level.
That's correct, yes.
All right. Well, let's take a look at the demo. So, you're going to go through the process of setting up Qlik Cloud to use a custom IDP; which provider will you be demoing today?
Today I'm gonna set up an Identity Provider with Qlik Cloud using Okta.
So, we're taking a look at Okta. What do you need to set up here first?
On this Okta instance, I already have my users and groups created.
Okay. So, we got two users and one group.
That's correct. And I'm gonna set up an application.
Okay.
Here I'm just gonna create an app integration.
All right.
Here I'm gonna select OIDC open ID connect, and it's gonna be a web application.
All right. And basically, all we're setting up here is preparing Okta to connect to Qlik Cloud as a form of authentication?
That's correct.
All right.
So, I'm gonna hit Next.
Is the name important?
It's not very important; it's how it's gonna display in in Okta.
Okay.
So just choose a friendly name so that you remember what it is; especially if you have a lot of applications. We are going to set up the Callback URL for Qlik Sense.
All right that's that redirect. What does that need to be?
So, that needs to be your tenant URL / login / callback. It's good to note that it must be - so not your Alias, but the actual tenant URL.
Okay. And where do we find that?
So, if you go in your tenant.
Okay. So, this is your Qlik Cloud tenant you're going to set up to use Okta?
Yes, that's correct. So, I’m first going to go in the console. So, it's good to note that here you only have your actual Alias. You don't see the URL-
With that ID.
Yes.
Okay. So, how do you find that ID?
Easiest way is just to use this endpoint, which is: API/V1/tenants
Okay. Well look at that.
You will find your ID here. So, here is the URL that you need to use.
Okay. So, we paste that into Okta?
Yes. So, back to Okta.
All right.
Login/callback.
What else needs to be said here that's important?
Then choose who you want to allow access to. For test purposes, I'm just gonna allow access to everyone in my organization.
Okay.
And I'm just gonna Save. Here. I have my Client ID that got created.
Okay.
Then I have client secret.
I'm assuming that's something that Qlik Cloud will need?
Yes. Before moving on to Qlik Cloud, I'm gonna set up the groups.
Okay. So, this setting on the Sign-On Tab will send those groups that you've already created in Okta to Qlik Cloud?
Yes. So I'm just gonna select groups and Matches regex, and just write period and star (.*) so that it sends all of the groups.
Okay.
Save.
That's an important setting.
First of all, I'm gonna copy this Qlik Client ID. So, now I'm gonna go to Qlik Cloud.
All right. So, we're in the Management Console - Identity Provider and by default this was set up to use Qlik ID?
That's correct. So, when you're using Qlik ID, you won't see anything here. Here you only see your 3rd-party Identity Providers.
Okay.
So, I'm gonna hit Create New in here. Then I'm gonna select interactive and the provider is going to be Okta I'm gonna test my Client ID here.
Okay. And we still need that Secret; so let's jump back over there.
Repeat the Secret.
All right. Are there any other important settings here in the setup?
So, we also need to set up the Metadata URI in here.
All right. And where do we get that information?
So, you have in Okta, your Okta tenant /.well-known/openID-configuration. And we can just use this one.
Okay.
You can also set up different endpoints if you go in Okta, in API, in authorization server.
But this is just basically where it'll deliver all the metadata for that connection?
That's correct.
Okay.
So, here I'm just gonna copy this endpoint and just gonna paste it here.
Yeah, this mapping: is there any specific things we need to understand about the claims mapping?
So, the clamps mapping here, you have what is called a Realm, and it is optional. And that will be prepended to the Sub, which basically corresponds to your User ID.
Okay.
So, it will be like a user directory if you are using Qlik Sense on-premise, and you want to match users, you might need to set up the user directory here. If you already have the directory included in this claim, then you don't need to prepend another one.
Okay, but in this example, all of our users are in Okta, so by default it'll just pull those users as they're set up with this default configuration?
That's correct.
Okay.
So, Sub doesn’t need to be Sub for example. You can put Email here if you want to use Email as a username.
Okay.
So, we can put this Email and it will pull that instead of Sub, which is usually a random string.
Right. All right; that'll make it a little easier for human eyes to read than just this random string of numbers.
And here in advance option; so, when it's left blank. it will use by default Open ID Profile Email, which is every standard scope to use.
Okay.
And here you have that little option also, which is called Block Offline Access.
Yeah. What does that mean?
That’s mostly for the Qlik Sense native app, that you can use your apps offline.
Ah right.
Yes. So, now we will just hit Create. And just save this configuration which will take us to a validation page.
All right, you set up the tenant to use Okta as the Identity Provider, so it's asking you to login with Okta?
Yes. So, now I'm gonna just login.
Okay.
Looking successful.
And I see you set Sub as Email, so it's picking up your email from Okta.
Yes, that's correct. Yes and we also can see Email Verified set to True here. This is used to map the users by Email.
Okay.
For example, if you're switching Identity Providers; as long as you keep the same email for the users, and you have email verified, then you can just map the old users to the new users without having to just reassign everything.
Oh, that's very important for some people.
So, now I'm just gonna hit I have validated the above data.
Okay. And this seems like an important step.
So, here this step is promote user. So, it's to ensure that you don't lock yourself out when you switch IDP.
Right.
So, make sure to check this box.
Okay.
And then just hit Continue. And the last step is to Activate your IDP, which will switch my current Identity Provider from Qlik ID to Okta.
All right, and there it is: interactive Okta.
Yes. You can see that the status is active. So, next time we login to Qlik Cloud, it will use Okta as Identity Provider. Login here, so I'm now logged in with my Okta user, and I can see two users here, and with that little icon which shows as which user I'm logged in.
Okay. You can see that the one you're currently logged in as is the tenant admin.
Yes.
Is it important to keep that user there, the original Creator, now you have a new one?
Yes. You need to keep the user that is your Service Account Owner for the tenant for Recovery purposes. The recovery URL is your tenant URL/login/recovery.
Well, that's good to know that in case anything changes, it causes some issues, you could always go to that recovery login and log in with the service account owner. Okay. All right, so has this already imported the groups yet, or how does that work for users?
So, for users, it's going to create the groups in Qlik Cloud when the user that is assigned the group has logged in.
Okay. So, you just need to login at least once?
Yes.
And then they'll get right in, and then the admin can manage them according to what permissions they need in the spaces they'll have access to?
That is correct. And also in the configuration here, in settings: enable creation of groups.
So, that will allow all those Okta groups to be imported once the users have logged in?
Yes.
Good to know. So, if we logged out and login again, so if we go to the Management Console, just create a new space, select the type. So, it can be a Managed Space for example.
Sure.
Select Manage Members
Okay. So, we're setting permissions to the users that will have access to that space?
Yes. And here Qlik on Add Members, and I will search for my group here: ’STT test group.’
Okay. And that's a group that exists in Okta and it's able to automatically recognize that group, that's great.
Yes.
But the big caveat here is: it recognizes that group because the user you logged in as is a member of that group?
That's correct.
Great, okay. So, Damien, what are some common issues you've seen users run into when it comes to setting this up or authentication issues?
Some common issues are for example: when your secret expires.
Right. That secret key you set up when you created the application in Okta; that had a secret key.
Yes, that's correct.
Yeah; so, how does that look for users when the secret key expires?
So, there is an article about how you resolve this with the exact error message when it expires.
Okay.
So, this one is for Azure, but you would see something similar for other IDP.
Okay.
You need to log into your Identity Provider; and go to your application, and then you would need to create a new secret.
Okay.
And then use the Recovery URL for on Qlik Cloud, and go there to update your new secret. Ah, so it's that Recovery URL you showed us earlier. And that's pretty much: just copy that, and paste it back in?
Yes, that's correct.
Okay. Well, what other common issues have users encountered or that you've seen?
So, some other common issues are for example the groups that get created; or they are created with an ID instead of the group name, and that's mostly seen with Azure.
Okay. Well, how can you see the groups in Azure to help troubleshoot that?
So, there's an article about this. When we use Azure, we are pulling the group from the Microsoft Graph API. And we are pulling up to 1000 groups in the order that the Microsoft Graph API will return them.
Okay.
It's also good to note that: we do not support nested groups.
So, if a group is inside a group; that nested group doesn't get pulled in? It's only the first level groups that get pulled in?
Yes.
All right, if groups are showing up with number strings instead of names; how would you troubleshoot that issue?
So, in order to troubleshoot that, we need to see what the Microsoft Graph API is returning.
Okay.
We're gonna request an Access Token. And we see this explained in this article here. That's the first step that we need to do before we can call the Microsoft Graph API.
Okay. And all the steps are outlined there.
I'm going to show briefly here.
Okay. So, you've got some scripts already prepared. What will this script do?
So, this one doesn't actually execute anything. It just builds the URL for you.
Okay.
so that's the first step I'm just gonna execute this and it's gonna give me vc1
Okay. So, that URL allows you to authenticate?
Yes. And this URL is built from the authorization endpoint that you can find in the metadata URL that we've shown earlier.
Okay.
And the Client ID is a redirect URL, which is where you want to redirect after your authentication. So, now I have my URL. I'm just gonna copy this in a browser and authenticate there.
Nice.
So, here you will see the site can't be reached, which is expected because this is the dummy URL.
Right. But what we want to get from here is the authorization code here from this URL.
That's a long string.
Just make sure that you don't copy more than you should. So, that's basically from after the code = until the next &.
Okay.
Which is here in our case.
Ah. It's good you're used to picking that out.
This is the authorization code; so, we need this for our next step.
All right.
Here this is when you request the Access Token.
Alright. So, where do you paste in that code that you got from Azure?
Here.
Okay.
So, I'm gonna paste the code here. As this is pretty long. I'm just gonna do like this instead of scrolling all the way. So, here I will paste the authorization code that I got from Azure.
And what will this script do again?
So, this script is gonna request for the Access Token from Azure.
All right.
And we need that Access Token to be able to call the Microsoft Graph API to see our groups.
Okay. Run this, and we'll get the Access Token.
I'm writing those token in a file so that is easier to copy.
Sure.
So, I'm just gonna open this file. So, you have different types of token in here. You have the Access Token, which is the one we need for this troubleshooting step. But you also have the ID Token, which is from where Qlik Cloud will read the Username and Email. So, in this step we need the Access Token.
Okay.
And then you just need to do a Get Request to graph.microsoft.com/V1/ me/memberof. So, that's the endpoint that Qlik Cloud is calling when fetching the groups from Azure.
Okay.
And it's gonna fetch a maximum of 1000 groups.
Where do you paste in that token?
I'm gonna inject this token. So, here I'm just using a little browser extension to just inject it as a header.
Okay.
And I need to call that header Authorization. In the value, I need to put Bearer space and then my token. I paste it here.
All right.
And then if I refresh this page.
All right. So, that pulled the groups from Azure, so you can actually see the names of the groups right?
Yes. So, from here you would see each of the groups. And what QlikSense is doing is that it’s fetching it so the entity of this type. So, here for example, we can see that we have two groups in here. We have two entity with this type of ’microsoft.graph.group.’
Okay.
So, we can see its ID; we can see its display name, here.
Group 2.
So, display name is what Qlik Sense will be using when creating the group.
Okay.
So, if you're missing the display name, that's usually why. You're not seeing the correct group name.
Interesting. All right. Is there another issue you want to highlight?
Yes. So, here we can see an example of a validation failure when we're trying to create a new Identity Provider, and it just can't read the URL.
Right. So, this would be something in the the setup process, when people trying to set up the IDP in the first place, they run into an error: validation failed?
Yes. So, it can be typo in the URL; or it could be also that the URL is not publicly reachable. So, for example, if you use some on-premise Identity Provider (such as ADFS or Bing Federate) then you might not have published the URL on the internet.
Right. Okay. So, need to make sure that's publicly available between Qlik Cloud and the provider. Okay.
Yes. So, when you are pinging that DNS, make sure it returns a correct IP. Also, and we've also seen cases where the certificate wouldn't appear trusted.
Ah.
It it can happen when the site doesn't send the full certificate chain.
Okay. Great. Well, now it's time for Q&A. Please submit your questions through the Q&A panel on the left side of your On24 console. Damien, how about if we just take these from the top? First question is: how do we connect to users in Google?
So, you can connect your users with Google by using the generic IDP type. And also make sure that you check the Block Offline Access in the advanced option; because it's a scope that Google doesn't support.
Right. That one we've talked about at the very bottom.
Yes.
Okay. Next question: the token expiration in Azure active directory is max 24 months. Is there any solution to have this set to permanent?
Unfortunately, this is not possible. So it's a setting from the other side; and it's not really advisable either (security-wise) to have indefinite validity on the tokens.
Okay. So I guess you'll have to just schedule that in the calendar; and set up a maintenance window to create a new token, and add it to try and prevent users from encountering that issue?
Yes, that's correct. That's really only takes a few minutes.
Great. Well, moving on; next question: we have a tenant that's related to a Qlik Sense Enterprise on Windows. In the tenant, the already listed users are not activated (sign-up pending). Do we need to configure active directory in the tenant?
You don't need to have the same Identity Provider in both your cloud and your on-premise.
Okay.
But in order to match your users, you need to make sure that what is displayed here in IDP Subject is matching what you have in your on-premise environment by the user directory backslash the user ID. So, that's what you need to see here in the IDP Subject, so that Qlik Cloud can map the user.
Okay. So, that's the key field there?
Yes.
All right. And that will work for those multi-cloud implementations?
Yes.
Good to know. I guess, kind of related; someone's asking: how can we learn more about single sign-on integration with client active directory?
There is some documentation on the Help site. So, this is explaining how you set up active directory Federation Services as an identifier for Qlik Cloud. And that feature is available from Windows Server 2016 and later.
Okay. That's great, those documentation, even a little video going through that process. Fantastic resource. We’ll make sure to provide that link at the bottom of this article when it's posted in Qlik Community when we're all done. Next question: can you set up a multi-cloud implementation to use Google Cloud as IDP for both client managed and Qlik Cloud?
Yes, you can set up Google as your Identity Provider in client-managed, and then also set up Google as your entity provider on Qlik Cloud; so that you have the same type of authentication on both sides. Although it's not strictly needed to have the same to have the users mapped as I said earlier; but for the distribution task. However, the recommendation is to use local Bearer token in this kind of setup.
Okay. In those kind of multi-cloud setups, is the same license or access pass used for one user even if it's client managed and Qlik Cloud?
If you have a unified license.
There you go, that unified license!
And you can apply the same license on Qlik Cloud and your on-premise environment.
Okay.
And as long as the user matches as per the IDP Subject and Qlik Cloud and as per the user directory and user ID in on-premise, then you will only use one license per user.
Okay. So that's the key. Somebody's asking: where can I find more information about using ping Federate OIDC as a single sign-on for Qlik Cloud?
So, unfortunately, we do not have any documentation on how to setup Ping Federate for Qlik Cloud. However, if you just follow these troubleshooting steps that we've discussed during this webinar, it will be pretty easy to figure out what you need to put in the configuration.
Still is kind of the same steps; you need a secret key, a application ID, those same kind of things as?
That's correct, yes.
Okay. Next question then. We're moving along here. Is it possible to still use your Qlik account as authentication after setting up another IDP option?
So, you cannot authenticate at the same time with Qlik Cloud and some other IDP. You're only allowed to have one active Identity Provider. However, as we said earlier; you should keep the Qlik account for the service account owner for Recovery purposes.
Okay. So, one IDP at a time basically?
Yes.
All right. Next question: when changing to a different IDP, do you have any suggestions for transferring users over to the new IDP without having to redo everything? Is there any recommended mapping tool?
There is no tool to do it. But the recommendation would be to map them by the email. And as we said earlier, that's done by using the email verified claim. So, as long as you have the same email in the old IDP and in the new IDP, then you can just map them by the email. Right. So, that would be best practice then, just to keep everything based on the email address?
Yes. That's the easiest way to do it.
Okay. And how can we set up two-factor authentication?
So, everything is done on the Identity Provider side. There is no extra settings that needs to be done on the Qlik Cloud side.
Right. So, if you're using Google Cloud, that would be Google Cloud doing the two-factor authentication?
Yes, that's correct, yes.
Okay. If you enable the option Email Verified Override, won't it create a duplicate new user? Email Verified Override is a setting that is available for ADFS and Azure which is basically means that you will set Email Verified always to true, even if the Identity Provider hasn't sent the claim.
Okay.
But that's not gonna create a duplicate user. That's just gonna map them based on the email. It could create a duplicate user if the old user didn't have an email. So, that's one case where you could see a duplicate user, but if your users before has an email; and the one the user that you get logged in after setting up the IDP provider has the same email, then it will just merge them.
All right. That's good to clarify that then. Next question: how to restrict access to spaces based on Azure 80 groups in Qlik Cloud?
So, in order to restrict access to spaces with groups; it doesn't matter what kind of identify provider you're using. It will be the same procedure. So you would either go to the hub or through the console; and then find your space, and select Manage Members. In here, when you click Add Members, then use search for your group, and then you can add the group here. So, here I've already added the groups. Here I can see a STT test group that has been added. And that's given access to people that belongs to that group.
And there you can also adjust the permissions level for that group as well.
Yes, that's correct. You can also adjust permissions level from here.
Great. Appreciate that. Next question: (we're getting near the end here) can we connect more than one Azure 80 tenant Identity Provider to Qlik Cloud?
So, you cannot have multiple Identity Providers active. Which means that you can only connect one other AD tenant at a time.
All right. So even though it's the same type, it still limits to one?
Yes, that's correct.
All right. Last question today: is there a way to have an IdP set up through Azure AD and still allow adding manual users that doesn't form part of the domain?
So, that's also not possible. You can only have one type of Identity Provider active, and that's the only one that will allow users to login. So, you cannot have another Identify Provider setup and have some users that are logging with a different method.
Okay. That's clear. Well, Damien, thank you very much for this. I appreciate you going through and clarifying everything in the process for how authentication works with Qlik Cloud.
And thank you everyone for watching this session. And if you have any further questions, just feel free to reach out to us on Community.
Okay, great. Thank you everyone. We hope you enjoyed this session. Thanks to Damien for presenting. We appreciate getting experts like Damien to share with us. Here is our legal disclaimer. Thank you once again. Have a great rest of your day.