4 Replies Latest reply: Oct 2, 2009 10:29 PM by Bill Chosiad RSS

    NT Token/Ticket Authentication

    yiling1990

      Can anyone explain how to set up ticket authentication for Qlikview Server 9? I don't really understand what is written in the manual.

      I have QVS 9 running with IIS. Right now, i know the NT-tokens are coming in correctly and have the right information (username, group membership, etc) but somehow Qlikview isn't reading them correctly, and is prompting me for a password whenever I reach the AccessPoint page.

      Any ideas will be greatly appreciated,

      Yiling

        • NT Token/Ticket Authentication
          yiling1990

          Any information on how to get Qlikview to read authentication tokens would also be helpful.

          Thanks,

          • NT Token/Ticket Authentication
            yiling1990

            In the Qlikview Server/Publisher 9 documentation, it says:

            In programming (ASP/VBScript), try the following:

            set ntsecurity = CreateObject ("QVSRemote.Client")
            ntsecurity.AdminConnect "localhost"
            ticket = ntsecurity.Execute("<Global method='Get-
            Ticket'><UserId>User</UserId></Global>")
            msgbox ticket

            Do I put this in a configuration file for Qlikview or is this just for an example file that I would write just to see what the getTicket function does? If it is only an example, then where is this set in Qlikview Server's setup files?

            Thanks in advance for anything help.

            • NT Token/Ticket Authentication

              I've just started playing with this under QV9 SR1. Right now I'm using the QV Web Server, but will go to IIS on a separate box shortly.

              I set up a little VBScript file to test this. Here it is:

               


              InputBox "ticket","ticket",GetATicket("myuserid")
              Function GetATicket(userID)
              Dim client, cmd, ticketXML, objXMLDoc
              Const QVSERVER = "myqlikviewserver.mydomain.com"

              Set client= CreateObject("QvsRemote.Client")
              client.AdminConnect QVSERVER
              cmd="<Global method='GetTicket'><UserId>" & userID & "</UserId></Global>"
              ticketXML = client.Execute(cmd)

              Set objXMLDoc = CreateObject("Microsoft.XMLDOM")
              objXMLDoc.async = False
              objXMLDoc.loadXML(ticketXML)
              GetATicket = objXMLDoc.documentElement.selectSingleNode("//_retval_").text
              End Function


              (Note that this is just for testing. A real routine would have much beefier error checking and graceful recovery.)

               

              This seems to work when I run it on the QV9 Server. It relies on a DLL to be installed that handles the call to create the QvsRemote.Client call. The DLL is installed as part of the QVS install. I haven't tried it yet, but I believe it's also installed as part of the web connector stuff if you have IIS on a separate box from QVS.

              So if you run this little app (setting myuserid to your user id), it will create a big ticket string, such as 841F141FBF15EE2EABF3CD1533A6D2C2E5CF39AC.

              For this to be of any use to you, your server must be using DMS authentication on the QV Server.

              If you know the URL to your QV document, for example:
              http://mycompany.mydomain.com/QvAJAXZfc/AccessPoint.aspx?open=&id=QVS@mydomain%7CRefreshTest.qvw&client=Ajax

              You can can add "&userid=841F141FBF15EE2EABF3CD1533A6D2C2E5CF39AC" to the end, for example:
              http://mycompany.mydomain.com/QvAJAXZfc/AccessPoint.aspx?open=&id=QVS@mydomain%7CRefreshTest.qvw&client=Ajax&userid=841F141FBF15EE2EABF3CD1533A6D2C2E5CF39AC

              So what does this get you? It's assumed that you have already authenticated the user. The ticket assures you that this user is authorized to use the document that's being requested.

              For example, where I work, we have our own authentication system. When users ask for a QV document, we intercept those requests and instead, send them off to our own authentication system. They enter their user ids and passwords to prove *who* they are, and are then sent back to our web server. So far, we know who they are, but that doesn't mean they are allowed to see our QV documents. At this point, we request the ticket and redirect them to the actual document with the ticket appended to the end of the URL.

              When the ticket is generated, it keeps a record of it on the qlickview server for some short period of time. When they request the document with the ticket, QV knows who they are, and checks the document security to make sure they are authorized to actually view it.

              I hope that made sense. Best of luck.