Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
cjgorrin
Contributor III
Contributor III

How to keep different Qlik Sense HTTP sessions (cookies) on the same Qlik Sense server at the same time

In my organization, we have a Qlik Sense Enterprise server. We have a website where we create mashups for non-public apps (no anonymous access allowed).

For each mashup:

  • Our website authenticates the user and checks if they are authorized to access the mashup.
  • If not authorized: we show an error message.
  • If the user is authorized:
    • Our website requests a ticket from the QPS API.
    • We make the user's browser request a static resource from the Qlik Sense server, consuming the ticket, which starts the session and establishes the cookie.
    • Once the session is started, using the Capability API, we open the Qlik Sense app, retrieve objects and embed them into our website's HTML.

The thing is we didn't want to manage user rights on Qlik, because we already had all permissions set in our website. We wanted Qlik to be as detached from the actual permissions and security rules as possible.

With this in mind, we designed a very simple system: one dummy user per app and each user has access to that app and only to that app. One single access rule: userId = appId.

This way, with the QRS, we request a ticket for the dummy user, the human's browser consumes the ticket and immediately opens the app with the Capability API.

This approach looked very good because:

  • A ticket can never be used to access more than one app.
  • Qlik Sense is completely free of complex security rules, which were already implemented in our website's code.

However, we are experiencing some issues:

  • If, on tab T1 of the browser, you open mashup M1, linked to app A1, everything works fine.
  • If you then, on tab T2 of the browser, open mashup M2, linked to app A2, everything works fine.
  • If you go back to tab T1 of the browser, all interaction (selections, retrieving visualizations, etc.) with app A1 works fine, but:
    • Images from app A1's content library that were not loaded before app A2 was open will not be loaded.
    • You can start data exports for app A1's visualisations, but you will not be able to download the resulting file.

This is because whenever we open a new mashup, linked to a new app (A2), we obtain a new ticket, linked to another Qlik Sense user (also called A2). So, even if the Capability API works fine because it relies on the unaffected WebSocket connection, any kind of HTTP request sent to the server will be linked to user A2. So, all resources of app A1 will be forbidden.

Our question is: What would be the best strategy to follow in our case to solve this issue?

We thought of creating one virtual proxy per app (~300 apps), but we don't know how that would affect performance. Also, even though we could create the per-app virtual proxy on the fly, that would invalidate ALL sessions linked to the central proxy, which we don't want. All users would be immediately logged out.

We really would like to keep the security handled by our website and Qlik believing blindly what the website says.

Permissions are set dynamically through a web interface on our website and they can change often. They are based on usernames, departments, email addresses, users belonging to groups defined on our website and some other details that are not necessarily stored in Qlik Sense.

What we need to achieve is something like each mashup having its own Qlik Sense HTTP session (cookie) so they don't overwrite each other's sessions. When you export data from app A1, you retrieve it with a Cookie linked to user A1. When you export data from app A2, you retrieve it with a Cookie linked to user A2.

If anyone has had a similar problem in the past with non-public mashups that require authentication and authorization handled by external systems, I would love to hear how they managed to implement the security on Qlik Sense.

Thanks a lot for your ideas!

Labels (3)
4 Replies
rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

You've run into some problems, and you will run into more problems if you scale this.  I don't think the generic userid model can work with proxy access and a standard license.  Each user of Qlik is expected to consume a license and a licensed user is limited to 5 sessions.  

What you are attempting is effectively, from a licensing perspective, anonymous access. I believe you would require a QAP license to do what you describe.

If you are already doing the authorization in the mashup, why not make the Qlik app read to all?

-Rob

cjgorrin
Contributor III
Contributor III
Author

Dear @rwunderlich , first of all, thanks a lot for taking the time to read our question and answering.

Regarding our server: we have a Qlik Sense Enterprise Core-based license, which is even more than a QAP. I don't think we have a problem regarding that.

From the technical point of view, we cannot make all apps visible to all users because anyone with good Javascript knowledge would be able to open any app with a ticket obtained for a specific app. Our model -with its shortcomings regarding HTTP session- guarantees that if our website tells Qlik "give me a ticket for a human to access app A1", the ticket cannot be used for opening any other app.

We don't need the Qlik Sense server to be aware of the actual humans accessing the apps. We just need the security model to rely as much as possible on our website's security model and as little as possible on Qlik Sense.

If you have any other ideas on how this could be accomplished, we're happy to hear about it 🙂

Thanks again for your help and your time!

 

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

I'm not familiar with how licensing and session rules work with a core based license. I'll ask @websy1985 if he has any ideas for you. 

-Rob

websy1985
Luminary Alumni
Luminary Alumni

As @rwunderlich mentioned I think you'll soon run into session limitations if you use the same userid for everyone. As an alternative, I'd use a generic User Directory instead and follow the same logic. So, userdirectory = appid, for example (or something along those lines). That would make the security rule simple to implement. The userid could then match your Identity Provider and you'll avoid creating too many sessions.

Another thing to try would be to get the ticket reactively rather than proactively. This is tricky with the Capability APIs but what we've done in the past is used the Engine API to open the connection and validate whether or not the user is authenticated (using the 'OnAuthenticationInformation' response from the server). Based on that you can either initiate the routine to get the ticket or to connect to the Capability APIs (and close the Engine API connection if needed).