topic Re: SA and a BINARY in QlikView

SA and a BINARY

datanibbler — Tue, 19 Sep 2017 07:35:38 GMT

Hi,

I have a question rgd. the combination of a BINARY LOAD, which we have in every app visible to the
"general public" and a SECTION_ACCESS - which comes down to a matter of the order of execution: Is the SA,
as I believe, computed on the server from the Header BEFORE actually doing anything in the qvw? In that case the BINARY
would not be executed on the machine of somebody who is not granted access to the app. Then it could be the very first Statement in the script, as it has to be, and the code to load the SA anew could come afterwards.

Right?
Thanks a lot!
Best regards,

DataNibbler

Re: SA and a BINARY

tresB — Tue, 19 Sep 2017 07:40:35 GMT

AFAIK, binary load gets executed first. And that is why you should always check 'Prohibit Binary Load' (Document Settings->Opening tab) on all the applications that has SA. Because your qvw with SA being binary loaded can always be overridden by a new qvw with another SA.

Re: SA and a BINARY

prieper — Tue, 19 Sep 2017 07:49:59 GMT

Typically these applications should only reside on a server. The server-user needs not to be restricted and needs to be declared as ADMIN.

Therefore the sequence does not matter (actually BINARY must be the first statement), as these files should not be available to the public.

A user, who is not authorized, will not be able to open the application, where there is SA.

A user, who is not authorized as ADMIN will not be able to refresh the application.

Restriction to the baseapplications will need to be handled / governed by Windows.

Re: SA and a BINARY

datanibbler — Tue, 19 Sep 2017 09:06:06 GMT

Hi,

the apps do reside on a Server and typically they are reloaded on the Server (by a dedicated user) once a day.

But my question was a Little bit different, owing to the fact that EVERYONE in this Company has a Named_User_CAL, so everyone can basically open any app (which is why we Need the SAs in the first place) and everyone can also reload an app (which no one usually does, but who knows ...)

<=> ah, Forget it, I just noticed my mistake: In principle, everyone can also reload any app and thus execute the BINARY if there is one, but if that Person is not in the SA, he/she won't be allowed to open the app, so he/she won't be allowed to reload it, so there's no issue actually ...

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 09:14:38 GMT

Indeed, there shouldn't be an issue. Even if your users have a Named CAL, you can still restrict or completely deny access to your document. Just don't make them ADMIN.

As a side note, it's a pity that Qlik never created a fine-grained license lease-switch. At the moment it's still a global switch, but if we would be able to tell the QMC that this user should be able to lease his/her license, and that one shouldn't, things would become much simpler and IMHO security would become stricter.

Re: SA and a BINARY

prieper — Tue, 19 Sep 2017 09:57:48 GMT

Hi Tresesco,

as far as I know, the BINARY-load restricts the amount of data to your profile, i.e. when you are not allowed to see the entire dataset, you will load in the binary only those data, which you are allowed to.

Not quite sure, whether you are still able to overwrite the SA in such document (it was possible in earlier versions), but then you need to know the exact structure of the SA-file.

edit: incorrect statement

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 10:08:52 GMT

If I remember correctly, recent discussions on that lmatter came to the conclusion that the SA from the original QVW would come over with the BINARY LOAD and couldn't be modified in any way. The first SA is final.

I'll check if I can find one of those dicussions...

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 10:16:33 GMT

Actually, the recent one wasn't conclusive.

But this one may shed some light: binary and section acess?

Re: SA and a BINARY

tresB — Tue, 19 Sep 2017 10:24:41 GMT

Hi Peter,

I might not be able to SEE the entire data, but it is STILL THERE at the back-end, I believe. This nature makes sense to me, because you are not really loading (read reload) the data to restrict, unlike publisher.

And yes, I carried out a small testing (not rigorous though) in recent version QV 12.1, and it seems that I was not wrong; qv SA gets overridden still today as I explained above.

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 10:29:46 GMT

So you are saying that the original SA wont restrict what the BINARY load imports into the current document (or there wouldn't be a complete data model with all records in the background), and since the new SA is never made active during the load that creates the SA table, a new SA will become active as soon as the new document is saved and reopened. Thereby eliminating the original SA from the first document, correct?

Re: SA and a BINARY

Miguel_Angel_Baeyens — Tue, 19 Sep 2017 10:46:49 GMT

Kind of, yes. Note that any USER with permissions to reload, after reloading will see the whole data set. Only after saving, the section access will happen and the data set reduced to match the user ID.

This can be modified in the Security settings of the Document Properties and disable the reloads for USER type of ACCESS.

The same way than a USER opening the application could eventually change himself to ADMIN access, but this change will not happen after reloading, but after saving and opening again.

Re: SA and a BINARY

tresB — Tue, 19 Sep 2017 10:54:39 GMT

Saving and reopening would indeed reduce the application based on SA.

When I say the SA gets overridden, I mean - second document's SA gets precedence over the first one (binary-loaded), i.e. - as if, it (the first document SA) was never there.

This is what I have found so far. If any contradiction in behavior noticed please let know, we might have to test it more rigorously before we conclude.

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 11:03:33 GMT

It would surely make BINARY LOAD a powerful tool for circumventing any sort of SA security. It it weren't for the "Prohibit Binary Load" flag in the original document that is ... Binary Loaded.

It seems logical to me that Section Access of the first document doesn't play ball if you Binary Load the first document into a second one. And during that script run - immediately after the BINARY statement - the script would have access to all tables and data that's loaded from the first document.

However, I'm not sure that the second statement - SA gets overridden - is true as well. And based on the different help articles in both 11.20, 12.00 and 12.10 (even the most recent version), it seems illogical that the SA data model can be overridden. You cannot even do that with two section access areas in the same script... It does seem logical that the SA data inherited thru BINARY load only becomes active after saving and reopening the second document. But it should still be there...

[Edit] This is interesting: in a single script, which of multiple section access tables prevails: the first one or the last one? We may not even need a binary load test to prove/explain what has been said here before

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 11:16:31 GMT

Bad example; multiple separate - even disguised - Section Access tables just add to the same ACL list. At the end you just get all of it. Same after a Binary Load?

Re: SA and a BINARY

Miguel_Angel_Baeyens — Tue, 19 Sep 2017 11:16:56 GMT

I agree it makes sense, after all, if the user must reload, the application must reload the entire script for the full data set. In a server also works the same, even if the service account has access to reduced set of data, the script is either executed or not, but nothing in between. Security rules in Qlik Sense somehow tackle this.

A USER cannot use SECTION ACCESS in the script, the script stops. If the user access is USER in the source document, it will not be able to use SECTION statement in the destination document which binary loads the source one. However, as mentioned, the USER in the source document, if able to reload, will be able to reload the application fully, even modify SECTION. To look after this, perhaps the hidden script is a good idea.

An ADMIN with different reductions will use the latest one, so the section access in the second document, not in the original script.

EDIT: Necessary to say if the source data is saved with the reduction produced, the binary load with a new section access may lock the user out, if the reductions are not associated.

Re: SA and a BINARY

datanibbler — Tue, 19 Sep 2017 11:38:46 GMT

Yep.

I haven't really analyzed that issue, but being able to Switch something only globally, not specific for People, always renders things a bit complicated.

For my part, I have been wondering a few times since I'm here who in heaven's Name had the idea of purchasing ONLY Named_User_CALs for everyone in the Company ... they cost five times as much - 1000 NUCs make a difference of approx. €800.000 - and moreover - well, it makes things like an SA in every publicly visible app necessary ...

Re: SA and a BINARY

Peter_Cammaert — Tue, 19 Sep 2017 11:41:27 GMT

Tres, you're absolutely right.

Some of my findings:

Multiple Section Access statements + table loads just add to a single internal SA table.
Doc1[SectionAccess] -> Doc2[BINARY Load Doc1] inherits the first section access table as-is
Doc1[SectionAccess] -> Doc2[BINARY Load Doc1, NEW SectionAccess] replaces the original SA table with a new one. The original SA data is lost.

A QVW Save sort-of finalizes the SectionAccess data. After that, you cannot change or expand the SA data anymore. Just replace it.

Re: SA and a BINARY

marcus_sommer — Tue, 19 Sep 2017 13:58:00 GMT

Section Access is only one part of the security and the access control and should be combined with the NT access rights to the folders/files and/or with restrictions/distributions within the publisher - especially if it's the main-goal to control the visibility within the access point.

- Marcus