Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Qlikview 10 WebParts and handling Multi-Hop security.

We have a project based around using Sharepoint 2010 and using the WebParts to display Qlikview data on various pages throughout the site. Our main requirement for the parts is to display charts but depending upon which page they are on we would pre-filter the data using JavaScript to hook into the API.

Our main issue with version 9 was the multi-hop authentication issue. This is where we have Sharepoint on one server and Qlikview on another. Using NTLM, when the client browser connects to Sharepoint, then Sharepoint calls over to Qlikview, NTLM cannot do the impersonation, therefore Qlikview sees the call as being anonymous.

We could solve this using Kerberos, but Kerberos always seems to be a nightmare to configure and as we are using a 3rd party hoster this might not be an option.

As we were using Sharepoint 2010, Qlikview would only support the upcoming version 10, which luckily was adverstised as solving this multi hop issue by hosting the QvAjaxZfc in a virtual directory alongside sharepoint whihc could then handle the authentication through to Qlikview.....Fantastic...the solution to all of our problems.

However, after working our way through the new Qlikview 10 documentation, it does indeed state in many places that we can host the QvAjaxZfc directory on Sharepoint and this solves the Multi-Hop issue, but nowhere does it explain how you set it up and configure it.

We have spent days trying to set up QV10 for this scenarion with no success, and unfortunately, the Qlikview support team refuse to help as this is not a standard install (maybe this should not have been documented as such in the product literature !).

In addition to this, the Qlikview web parts seem to have been re-written and the Javascript used for version 9 no longer works. There is probably a new Javascript calling method, but as yet I have been unable to find anything on this.

Is there anybody out there who has used QV10 web parts who can offer any suggestions, help, advise or at least some soothing words to lower my frustration with the new product...

Cheers.

16 Replies
sjenkins
Contributor
Contributor

Have you gotten anywhere with your Sharepoint issues? We are also trying to set-up Qlikview web parts in Sharepoint 2010. We currently have a trial version and went through a lot with QV support to get it installed. We have the same desire to filter reports with particular parameters on certain pages. I also noticed that if you make a selection on one Sharepoint page, it will filter results on another, which is not always desirable. You would need away to clear those selection as you can do with Actions in QV tabs.

Sorry I can't offer help but am curious to know if you made progress before purchasing product.

Thanks,

Steve Jenkins

Not applicable
Author

Hm;

Have you checked the Proxy-Setting that is described in the documentation:

"The SharePoint dialog lets you enter the url to your SharePoint web application where you wish to use the QlikView Web Part. Make sure to enable the Use Proxy setting if you have SharePoint and the QvAjaxZfc folder on different computers. If you want an automatic installation, you must check the Install check box. Click on the question mark to read more about the stsadmin commands that are"

From what I understand is, that in QV10 you should use this proxy if QVS does not run on the same machine as Sharepoint.

You are right, Authentication in QV10 is redeveloped and now uses /QvAJAXZfc/Authenticate.aspx.
The problem that now appears is not only NTLM-multihop, but Cross Domain AJAX calls (from your Sharepoint-Server to the QvAjaxZfc-Folder on your QVS) --> therefore the proxy was introduced!

Roland

Bjorn_Wedbratt
Former Employee
Former Employee

That's correct the proxy should be used if the QlikviewWebServer is running on a different machine than the Sharepoint web server. If not using the proxu the QVWS must be running on the same machine as the Sharepoint web server (and in the same site) in a similar way as when you set up QVWS as a front-end web server with a back-end QVS. In the later scenario Web parts should be configured to utilize the QvAjaxZfc locally (hence no XSS issue as the security domain will be the same, i.e. http://mysharepointsite)

If one uses the proxy you need to dig into the the delegation hell with Kerberos configuration etc.
In this setup communication will be Client -> HTTP -> Sharepoint -> HTTP -> QVWS (QVS) so you need to pay attention that HTTP is the protocol being used between Sharepoint and QVWS if you aim for constraint delegation and/or protocol transition.
In v9 the communcation was Client -> HTTP -> Sharepoint -> TCP/4747 -> QVS so you had to register SPN:s on the service account running QVS if you wanted to configure constraint delegation.

Also worth paying attention to is that IIS 7 introduces Kernel-mode authentication, i.e delegation rights should in normal situations be given to the machine account running IIS. However Sharepoint will disable Kernel-mode authentication by default (as it's not supported in a server farm with multiple front-end web servers), so when running Sharepoint on IIS 7, delegation rights should be given to the application pool account in the same way as in IIS 6.

Final thing to remember, QVWS does only support NTLM authentication out-of-the-box, hence if you run QVWS on the back-end web-server (on the QVS machine) you cannot delegate authentication as it's not possible with the NTLM protocol. What you need to do is enable Negotiate on the QVWS by altering config.xml (on the back-end QVWS):

Change

<HttpAuthentication url="/QvAJAXZfc/Authenticate.aspx" scheme="Ntlm" />

to

<HttpAuthentication url="/QvAJAXZfc/Authenticate.aspx" scheme="Negotiate" />

in config.xml and restart QVWS

Also if running QVWS and constraint delegation is required you need to register SPN:s for the HTTP protocol on the QVWS service account in the format http/NETBIOSNAME and http/FQN



ashfaq_haseeb
Champion III
Champion III

HI jonwilks

Did you resolve this issue?

If so, can you please guide me how to configure it. I have the same scenerio as yours.

Your Inputs will be Helpful.

Regards

ASHFAQ

Not applicable
Author

Changing from NTLM to Negotiate in C:\ProgramData\QlikTech\WebServer\Config.xml forbid me to log in to Accesspoint at all.

Error shown in accesspoint: Login failed

Any ideas why?

<HttpAuthentication url="/QvAJAXZfc/Authenticate.aspx" scheme="Negotiate" />

ashfaq_haseeb
Champion III
Champion III

HI All

Did any one succeed in the integration.

Can some one share with us the steps you followed.

Regards

ASHFAQ

ashfaq_haseeb
Champion III
Champion III

Dear all,

Can some 1 help me in integrating qlikvie 10 with sharepoint wss 3.0

Its very much urgent for me

Regards

ASHFAQ

Bjorn_Wedbratt
Former Employee
Former Employee

Easiest way would be to:

- Install QVWS on the front-end Sharepoint (note: NOT IIS Support, but the actual QlikView Web Server!). Server OS like Win 2003/2008 will handle port sharing so you can host multiple applications sharing the same port (in this case port 80 for HTTP). You can use the same domain account used when installing the back-end QVS (domain\qvservice or similar).

- Make sure port 4747 is open to the back-end QVS so QVWS can communicate with QVS.

- Once QVWS is installed on Sharepoint (and started) you should be able to connect to it using http://sharepoint:4750/qtws.asmx. Try accessing the URL in IE from the back-end QVS. If prompted for credentials, add the site to Local Intranet Zone

- Add the front-end QVWS in the QEMC on the back-end QVS.

- Check Accesspoint is working on Sharepoint (http://sharepoint/qlikview)

Now you have a front-end QVWS connected to a back-end QVS

- Start installation of Webparts, point to the local QVWS (http://sharepoint/QvAjaxZfc). Don't use proxy*

* If you have the sharepoint site configured to use a different port (like http://sharepoint:19100 or similar) you need to select to proxy, even though QVWS and Sharepoint are hosted on the same machine. From IE:s point of view http://sharepoint:19100 and http://sharepoint is NOT the same site, i.e. not the same security domain will apply and you will get a XSS warning if you don't proxy.

Proxy-settings can be changed after the installation by looking into the web.config file for the sharepoint site.

The above is the easiest way, but requires installation of QVWS on Sharepoint. As stated above, if this is not an option, you need to dig into Kerberos delegation.

Bjorn_Wedbratt
Former Employee
Former Employee

Guess you're missing correct SPN:s for the HTTP protocol on the account running QVWS. You need to register SPN:s on the account running QVWS in the format:

http/HOST
http/HOST.domain.com

Where HOST is the NETBIOSNAME for the machine and HOST.domain.com is the Fully Qualified Name as registered in DNS