Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
We are using qlikview document, which is integrated into a JAVA Portal. So we are having 2 main servers over here -
1. Portal Server
2. Qlikview Server (Where the .qvw document is deployed)
Further, to inform that the single sign on is implemented using webticket.
Now, generally when user login on Portal, he/she can able to access the Qlikview document. However, sometime the user gets Windows Authentication Popup. (5/100 times)
On investigating the same we found that there is some issue with Cookies/Session. Please find the snapshot below. These snap-shots are taken from Client PC -
Cookie Snap-shot for Portal Server
Cookie Snap-shot for Qlikview Server
When we delete the incorrect cookie (marked in RED) the user wont get the Authentication Popup. However, when the incorrect cookie is not deleted and the user logs out and logs in again the Authentication Pop-up comes up.
I am not sure but what I believe is the incorrect cookie is set by calling QvAJAXZfc service (deployed on IIS on QlikView Server) from JAVA Portal.
Questions:
1. How can I avoid creation of incorrect cookie, OR
2. Is there any settings that I have to make on QEMC Server.
How do you have your webticket code formatted? Are you sending along client credentials to IIS? Have you whitelisted the server requesting a ticket from getWebTicket.aspx? Here is a sample webticket aspx page that you can evaluate against your code. Notice that if the whitelist is set up, default credentials do not need to be supplied to IIS because Windows Auth is disabled and Anonymous enabled.
It may help to watch this webinar as well: QVInPractice1_Authorization.mp4 - Google Drive
This page is for solution architects and integration architects implementing web ticketing in a QlikView 11.2 deployment.
Assumptions
It's possible you have Windows Authentication turned on in IIS on the QvAjaxZfc virtual folder. This is required if you are using windows authentication to authorize users to QlikView. If you are using web ticketing or http header injection for authorization, set windows Authentication to disabled and anonymous to enabled.
Here is a configuration document for IIS if using web ticketing or header injection.
Hi Jeffrey,
Thanks for the quick response and detail document.
You are right, we have set the Windows Authentication turned on (Enabled) in IIS on the QvAjaxZfc and QlikView virtual folder. If I turned it to disable then we are unable to view QlikView application on portal.
How do you have your webticket code formatted? Are you sending along client credentials to IIS? Have you whitelisted the server requesting a ticket from getWebTicket.aspx? Here is a sample webticket aspx page that you can evaluate against your code. Notice that if the whitelist is set up, default credentials do not need to be supplied to IIS because Windows Auth is disabled and Anonymous enabled.
It may help to watch this webinar as well: QVInPractice1_Authorization.mp4 - Google Drive
This page is for solution architects and integration architects implementing web ticketing in a QlikView 11.2 deployment.
Assumptions
Hi Jeffrey,
With your above solution -
1. Disable Windows Authentication
2. Enable Anonymous Authantication
3. Enter a <TrustedIP> tag under %ProgramData%\QlikTech\WebServer\Congig.XML
I was able to avoid the Windows Authantication Popup. But, I still get "Failed to authenticate" popup.
Is it because, I am manually deleting the AccessPointSession from Cookie to test the Windows Authentication?
Hiren,
Now that you have set everything for anonymous and you have whitelisted the ip, I'd start by testing with the sample aspx page I attached earlier. You will need to change the ip address or hostname to obtain the webticket (QlikViewServerUrl variable) to your IIS server running Qlik web components. If that works, then it's possible that your cookie deletion code is now removing the accesspoint session cookie you need to stay authorized.
If you receive an error when using the attached aspx page, then there remains something amiss with the configuration.
Do you mind sharing your webticket code?
Hi Jeffrey,
I believe the web ticket code is running good. I was getting the Windows Authentication popup only 5/100 times, 95% its running good.
I don't mind sharing but I don't have ownership of same.
What I observed is, if the portal is remain idle of 10~15 mins then the Windows Authentication popup was coming (earlier), now the Failed to authenticate.
Hi Jeffrey,
I was able to extract the Webticket implementation from Portal Code. Please find below the pseudo code for same.
Step: 1
Webticket = http://<QLIKVIEWSERVERNAME>/QvAjaxZfc/GetWebTicket.aspx?cmd=<Global method='GetWebTicket'><UserId>QLIKVIEW_USER</UserId></Global>
Step: 2
Webticket = lcXb/KLvZ5trBTtwTxliVcqiZLCsPIKAcQFpSiwt
Step: 3
http://<QLIKVIEWSERVERNAME>/QvAJAXZfc/Authenticate.aspx?type=html&webticket=lcXb/KLvZ5trBTtwTxliVcqiZLCsPIKAcQFpSiwt&try=/QvAJAXZfc/opendoc.htm?document=QLIKVIEWDOCUMENT.qvw&back=
What I observed is, if the portal is remain idle of 10~15 mins then the Failed to authenticate Popup is coming and this happens when the 2nd AccessPointSession is created in Cookie under Qlikview Server.
Now, this 2nd AccessPointSession is created For QLIKVIEWSERVER. Is it possible to avoid creation of 2nd AccessPointSession?
Is there content in the QlikView app or in the web page you are embedding Qlik content that may trigger windows auth? The only other thing I can think of is you have set a session timeout and for whatever reason because of the windows auth settings in IIS it prompted you.
I suspect the reason you are receiving an authenticate failure message is that you still have the equivalent lines of code in your web ticket request:
client.PreAuthenticate = true;
client.Credentials = new NetworkCredential(ticketinguser,ticketingpassword);
These lines are required if you are using windows authentication against the webticket code. You will notice the sample, the instructions I provided, and the video all remove these lines because you are trusting the requesting IP in the config.xml. The above lines are no longer required via the instructions I have provided.
Thank you Jeffrey,
Just for everyone reference. In our particular case, we were not doing the session management properly that was the reason QlikView Server was creating a new session with new webticket (which was not valid for portal). That's, why we were getting "Fail to Authenticate" error.