Starting in Server 8.2, QlikView authentication is much more flexible with tickets. I’m just getting started with them myself, and I’ll be sharing the resources I find along the way.
Big thanks to Dan English, Johan Jeanson and Claes Linsefors for my education about tickets at Qonnections 2008.
If you have a working QV Server implementation including an IIS or QVS HTTP frontend, copy this URL and see the ticket number in the response:
http://localhost/QvAjaxZfc/qvsviewclient.asp?cmd=<Global%20method=”GetTicketForMe”/>
NOTE: The double-quotes don’t copy correctly. Be sure to fix them or you’ll get an “invalid syntax” error.
Copy the ticket value to the end of this request to open a file:
qvp://localhost/YourDocument.qvw?TICKET= (paste ticket number here)
Behind the scenes the QlikView Server (QVS) is passed the username that authenticated to the web server. QVS issues a ticket in an XML response. You apply the ticket to your document request. QVS confirms the ticket, looks up the username that was passed, and then checks if that username can open the document (using NTFS permissions or the QlikView Document Metadata Service [DMS]). You are presented with the document in your client.
Most likely you are running IIS and you were authenticated using the same Integrated Windows Authentication (IWA) or a user/password combination that you use every day. In that case, this demo isn’t very impressive because you didn’t see different behavior. The key difference is that unlike QlikView versions prior to 8.2, your authentication to the server is not tied to your Windows account. QVS did not rely on IWA to pass your credentials, as it normally does. Instead QVS trusts that if you are authenticated to the web server, then you are a real user.
What this all means is that you don’t need IIS to authenticate the user. Combine flexible authentication with flexible authorization using DMS, and you can use two different schemes simultaneously. For example, local users on the Windows network will authenticate transparently using IIS and IWA. Meanwhile, remote users that are not a part of your network can enter a user/pass combo, or be referred through an Apache server, or the ERP system.
Related posts: