Restrict possible expressions in enigma integration

[seckenrode]

We are working on some sensitive views of data in Qlik that are embedded in our application.  We are using enigma for a fairly low-level embedding of qlik and we are building up the data in these views on the fly by creating session objects without a corresponding sheet. 

Given the client-side embedding approach Qlik uses, it is possible for a highly technical user to use the websocket connection that enigma opens to issue aribtrary queries against the underlying data we have in qlik.  This data is already restricted by section access, but we would like to prevent users accessing this data in unique or unexpected ways and instead only grant them "blessed" access to our defined expressions.  The area we are most concerned about is enforcing certain dimension limits or confidentiality thresholds for small buckets of data.

We have explored data model based solution (e.g. pre-aggregation) but they all impose restrictions on functionality we would like to avoid or have performance issues.

Based on our investigation, even if you are embedding an iframe or defined items from sheets, the websocket connection used for filtering/selection still allows you to issue arbitrary queries that are outside of those pre-defined embedded components.

Has anyone come up with a way to do this effectively?  The only path that seems viable is to proxy the websocket connection and maintain an allow/deny list of expected messages and only let allowed ones through, but that seems very brittle. 

Would love any advice or directions to explore.

[Daniel_Pilla · Accepted solution]

Hi @seckenrode ,

As you have stated, a highly savvy Qlik user can absolutely access the engine session over the established socket and probe any data that exists within the model. There is no way to prevent that, and as you state, any security concerns must be addressed instead by section access. I would not advocate for trying to implement security by trying to block or impede the user in any other way as section access is the only way to secure the data within the model once the user has access. 

That said, I have seen a couple of customers go the route of having an aggregated model and then using dynamic views to drill to the more sensitive row-level details that exist in another app. That way it is not in the model, but still possible to be accessed. And if the user then tries to traverse the socket of the dynamic view app, they will of course only see what was requested within the model and nothing else. I have only seen this approach used with iframes, however.

Cheers,

[seckenrode]

OK thank you — that aligns with my understanding after poking at this for quite a bit to try to find ways to harden this connection.

We've explored dynamic views but aren't quite sure they're the right solution for our use case — we essentially have some confidentiality threshold filtering we need to hide data when the n-count of rows is lower than a certain amount.  This hiding would need to happen any time a selection is applied and we want to maintain Qlik's speed when applying those selections.   The hiding is easy to implement as part of our measure definitions & dimension limits on tables, but as you noted a highly savvy Qlik user can access the underlying dataset and bypass those constraints.

Thanks for the confirmation at least!