Implementing ticket solution for authenticating to Qlik Sense

[Anonymous]

I did the following as per my understanding on the documentation:

I have a login page that when user submit it will call an api that will authenticate with ldap.  After verifying the identity with ldap, I will send an http post to get the ticket from qlik sense:

   var options = {

        host: <qlik sense hostname>,

        port: 4243,

        path: /qps/<qlik sense proxy>/ticket?xrfkey=1111111111111111',

        method: 'POST',

        headers: { 'X-qlik-xrfkey': '1111111111111111', 'Content-Type': 'application/json' },

        pfx: fs.readFileSync('client.pfx'),

        passphrase: <my passphrase>,

        rejectUnauthorized: false,

        agent: false

    };

    https.request(options, function (res) {

        // I am able to get the ticket at this point

        // Then I use this ticket to send an http get to the hub

        https.get('https://<qlik sense hostname>/<qlik sense proxy>/hub/my/work?QlikTicket=<the ticket retrieved above>', function (r) {

             // At this point I am able to get the session cookie set by qlik sense

        })

    })

If I remove the authentication to ldap, I still am able to get the ticket and session cookie.  So I'm a bit confused, what then is the purpose of authenticating to ldap where I can still get a ticket and session cookie without the ldap part.  There seems to be a disconnect between ldap authentication and getting the ticket/session cookie.  Is my understanding and implementation correct?

[rubenmarin]

Hi Ben, I'm far for being an expert in this area but i made logins without the ldap part, directly get the ticket and login without using a password.

Custom virtual proxy, certificates and login pages where needed to allow access.

I suppose checking to ldap is needed if you want to confirm credentials passed in your login page.

[Levi_Turner]

Hey Ben,

When you POST in a ticket, QPS is performing no authentication*. The use case for ticketing code to check creds is that the use case for ticketing isn't to do any auth. The more common scenario for QPS ticketing is to be able to refer an already authenticated user inside of some portal to Qlik Sense in a seamless manner. But again, in this scenario, the user has already authenticated into the portal so the ticket request merely needs to send the UserId and UserDirectory to Sense for a ticket.

* Technically Qlik Sense / QlikView do not do any authentication anyways. They leverage existing identity management like Windows Active Directory, Local Users, etc.

Hope that clarifies things.

[Anonymous]

Hi Levi, Ruben,

I think I understand it.  I guess I'm doing the authentication properly.  So after I get the session cookie, I used this to connect to qlik engine via enigma:

       enigma.create({

            schema,

            url: wss://<qlik sense hostname>/<qlik sense proxy>/app/<document id>`,

            createSocket: url => new WebSocket(url, {

                headers: {X-Qlik-Session-Enigma: <value from session cookie retrieved earlier>

            })

        });

However, I received a "mustAuthenticate:true" message, with a loginUrl:

{"jsonrpc":"2.0","method":"OnAuthenticationInformation","params":{"loginUri":"https://<qlik sense hostname>:4244/form/?targetId=<some value>","mustAuthenticate":true}}

So I still cannot go into the qlik engine because it seems to be asking me to authenticate again.  My virtual proxy setting is Ticket with Windows pattern (basically just default setting).  Then I tried removing this pattern and I get a different loginUrl:

{"jsonrpc":"2.0","method":"OnAuthenticationInformation","params":{"loginUri":"https://<qlik sense hostname>:4244/windows_authentication/?targetId=<soome value>","mustAuthenticate":true}}

Does this mean that I cannot use in websocket header the session value that I received from /hub/my/work?  Could you please advise how then I can connect to qlik engine after the authentication?

[david_hg96]

Hi! 

Did you find solutions for your question? I am trying to do something like this because at the moment I am login into the Engine using a <iframe> that show up an alert with the request of user and password, then I access the data using the EngineAPI but the selections that I make in the <iframe> object, does not affect in my Engine session, it looks as were different sessions, Dif you manage with something relational?

[riscteam]

Did you find a working solution for your iFrame issue, with the popping up credentials box?

I am trying to tackle the same problem 

[david_hg96]

Hi,

My problem was trying to integrate iFrame with the Enigma.js session, so I solved it adding the id of session for both connections,

in Enigma use the attribute identity: "name"

and in the iFrame add to the url:   ../identity/name/

In this way both connections will use the same identity, and share selections, etc.