QLIKLOGIN (qsda 3.0.3) with SAML virtual proxy

QSDA
1

Hi Rob,

I hope you’re doing well.

My client purchased an enterprise license with 100 users.

We were on version 2 and we upgraded to version 3.0.3 a few days ago, the API engine was used a lot on quite a few endpoints, after the upgrade our pipeline remained functional, almost nothing was wrong and that’s great.

Sorry if this post looks like a duplicate of the one I created before, but quite a few details have changed, like the license, the version, etc.

We are on a qliksense enterprise cluster (August 2023 version), with four servers, two front servers (consumer0 and consumer1), two back servers (central and failover). exposed by a load balancer (ALB on aWS).

All our clients connect with a SAML virtual proxy, and all authorization is managed by SAML attributes (groups).

QSDA Pro worked very well for us, since we only used it with a technical account and we only used the API calls to create an automatic analysis pipeline for each deployment.

Now that my client has purchased an enterprise license with 100 users, the work in progress is opening the GUI to developers and the solution that interests us is that developers needs to be limited on QSDA Pro only to applications on which they have access on qliksense, hence the interest of the QLIKLOGIN connector.

Our access URL (which corresponds to the fully qualified domain name is staging.qls-nprd.cloud.xxxx.fr) it’s a DNS that goes through a load balancer (ALB on AWS).

For the moment, the connectors (certificate, QLIKLOGIN) only work with DNS that points directly to the machines (without load balancer), example: consumer0.staging.qls-nprd.cloud.xxxx.fr

When I started configuring the QLIKLOGIN connector (using the main DNS), I had error messages which said that the QLIKLOGIN connector could not reach the QLIK clusters, and by reading the logs I understood that the API call made by the QLIKLOGIN goes through port 4747, we therefore opened all the network flows and added a listener on port 4747, since then we have failed authentication…

On the QLIKLOGIN configuration, the main DNS does not work and I therefore I cannot save the connector, so I tried to modify the ServerConnection.json file to force the modification of the host to staging.qls-nprd.cloud.xxx. fr/saml (saml is the virtual proxy header), when I did that, as a QSDA user on the GUI, when I use the QLIKLOGIN connector, it opened a SAML session on qliksense and returned to QSDA, but it remained blocked on “connection to Qlik is in progress”… I saw that there is an intermediate URL that displays a “requestToken” before it returns to QSDA, does it mean that is works only with “ticket” virtual proxy ?

My question is to know if QLIKLOGIN is compatible with a SAML virtual proxy ?

Otherwise, to give developers graphical access only to their Qliksense application scope, is there another way to implement this ?

The QLIKLOGIN works when used on subdomain that points directly on the servers, but we cannot use it like that, because it opens NTLM sessions directly on consumers nodes and don’t use oour main SAML virtual proxy…

Maybe I need to ask the support ?

Sorry for this long topic.

-Youssef

2

Hi Youssef,

"remained blocked on “connection to Qlik is in progress”

There is a fix for that problem in QSDA 3.1 What's New in V3.1. It should be a smooth upgrade from 3.0.3 to 3.1.1. Make sure you do the post-install step from the release notes:

If you are a QSDA Enterprise customer who has installed the QSDA Login Extension, please re-install the extension after upgrade.

The fix is in the login extension, so you must install the updated extension.

Regarding the load balancer issue. You may be able to work by using the Connection Advanced Settings as:

Proxy Host: Your load balancer URL
Engine Host: Your Qlik server
Repository Service Host: Your Qlik Server

Let me know how this works out for you.

-Rob

3

Thank you for your quick response as always Rob !

Ill try all this today and let you know how it goes.

-Youssef

4

Hi Rob,

Thank you so much, it worked like a charm.

I’ve upgraded to 3.1.1 and updated the extension like mentioned on the doc.

For those who are in the same Qliksense architecture like me, here is a screen shot on how I configured QlikLogin connector:

image
image1104×763 44.2 KB

It might also work by putting the main DNS on the qliksense engine and repository service host, but it is already working like this.

I have two questions that my team asked me

  1. Does the applications and streams lists have to be the same between QSDA and Qliksense when logged on analysis connection ?

Because we are authenticated with SAML (both on Qliksense and QSDA), we tought that, as a user, we gonna see the same apps (and streams) that we see on the hub, but we noticed that is not necessarily the case… let me explain:

On Qliksense Hub, i see my work section and 4 streams
On QSDA Pro GUI, I see all the apps that I own, and more streams than on the qliksense hub, it is the ones that I have apps that I own on them…

  1. Is it possible to simplify the login/authentication process ?

Now it seems that we need to make this on two different steps, the first one to login to QSDA and the second one to authenticate on qliksense server… is one analysis connection (without login connection) enough to see my apps on qsda ?

Thank you.

-Youssef

5

Thank you for the thorough feedback and screenshot. Very helpful.

If you change the connection Applist Rule to “stream”, QSDA will use a “stream first” security strategy and you should see the same list you see on the hub.

It’s possible this could be streamlined for a limited case. If the login server is the same as the Applist server, we could assume the same credential. The only issue I see is if someone wanted to login to the qlik server for analysis using a different userid than they used to login to QSDA. That is an atypical use, but is does happen. I’ll have to think about ways to handle that.

-Rob

1 Like
6

Ok Rob, it is very clear, thanks again !
Have a nice weekend !