Reverse proxy for QVP

[#1]

I have to set up QV Server in a very constraint environment from a security point of view.

For most users, the situation is a no brainer: they may use either QV Desktop connected to QV Server or the web access point, both from the LAN (either directly or through an existing VPN with two-factor authentication) to access the qvw files, activate their licence. Once their QV Desktop licence activated, they may open the qvw sent by emails as well.

Some users in subsidiaries aren't on the LAN, don't have a corporate PC and therefore can't be granted a VPN access. They receive the qvw files by mail (corporate mail accounts) but cannot access any server resource.

The security policy forbids any exposure of data that is not controled by a two-factor authentication.

I thought about exposing an empty qvw file dedicated to QV Desktop licence (re)activation through a reverse proxy in a DMZ.

This supposes to reverse proxy QVP. Is it possible? I saw in the QV Server Reference Manual that « If the QVS communication port (4747) is blocked in the network firewall, Windows clients attempt to re-route their connection through port 80 (http). This connection path must then include the QVWS, or be installed on Microsoft IIS, so that QVS tunnel communication can be established.”. A reverse proxy could be added in front of this tunnel, couln't it? If I could also configure the reverse proxy to open an access limited to my empy qvw file, this would meet my requirements.

Another option would be to abandon the QV Desktop client and implement two-factor authentication on IIS. It would though be a degraded solution since not compatible with offline usage.

Has anyone faced a similar need or has any idea to help me move forward?

[marcus_sommer]

I don't know if this is possible - I assume rather not. Then to get access to the server is one thing (might not easy) and to lease a licence is another (more difficult) thing. Why don't give those users simply a VPN connection, too?

- Marcus

[#3]

Thank you Marcus for your quick answer.

Those users belong to subsidiaries who have not been integrated into the group from an IT perspective. Theses subsidiaries have their own PC farm with their own security policy which is not compliant with the one of the group. The Security team of the group considers that installing a VPN on such "uncontrolled" machines would introduce an unacceptable breach. Rationalizing the IT accross the group would indeed be the neatest approach but this would be a huge effort I cannot ask as a prerequisite for our QV deployment.

[Anonymous · Accepted solution]

Once you email somebody a qvw that is picked up on a non corporate PC, then that qvw is effectively in the wild and could end up anywhere with all its data readable by anyone - even the freebie non licenced QV Desktop can open such qvw's a few times until restrictions kick in.

You make no mention of Section Access, so I assume it is not being used in your qvw's.

I would urge caution and double check if this is compatible with your security policy.

I agree with Marcus about giving VPN access to your AccessPoint and would suggest a policy of no QlikView Access unless via VPN [or LAN] access.

[#5]

Thank you Bill.

I agree with you on the email point but that's beyond my reach.

We do use Section Access.

Not easy, obviously.

[marcus_sommer]

Yes it's difficult to understand. On the one side those people should get access to (probably confidential) data and on the other side there is no real trust to them. I'm not from the IT but I think there will be possible ways with a further VPN maybe to a subdomain to which are set restrictions to all accesses unless qlikview or maybe any remote-desktop or citrix solutions.

But maybe it's easier (and it has lesser costs) to buy another qlikview server which is outside from your company IT and served only the reason to give those people the opportunity to lease a licence.

- Marcus

[#7]

Yes, we're considering the option of an empty QV server dedicated to licence leasing. Not an ideal solution, whether financially or operationaly but simple and easy to set up.

Thank you again.

[marcus_sommer]

Maybe such a specialized server could have have further use by simplifying various security-measures by splitting some of your applications in a inside and outside use and therefore reducing from available data and/or section access and maybe other things, too.

- Marcus

[#9]

! got a solution from QLik!

IIS should be configured to support tunneling (look for "Tunneling Using Microsoft IIS" in the QV Server reference manual).

The QV Desktop client may be configured with the Access Point URL : "Settings \ User preferences \ Locations", set "Qlikview Server Accesspoint (URL)" to the HTTP(S) URL of the dummy Licence.qvw.

A reverse proxy may be set up between the client and the server.

Now, select "Tools \ Open Qlikview AccessPoint" to open the dummy file for manual licence activation.

Licence activation may be scripted with the following command:

"C:\Program Files\QlikView\qv.exe" "http://server-name/QvAJAXZfc/opendoc.htm?document=Licence.qvw&host=server-name"