I think it would be helpful to lend some clarity to this topic is to take a short step back and look at the two environments being discussed. Desktop/Standalone and Server (aka Access Point or Hub/QMC in Sense parlance).
If you need to provide access security to your data in your QlikView or Sense apps when running standalone Desktop (aka Personal Edition in QlikView), you need to have a mechanism to prompt for user and password authentication, and have mechanism for authorizing data access. If running under Desktop, there isn't any external mechanism to provide this functionality, so Section Access allows you to create an app where you essentially define the authentication (userid/role/password) and data reduction based on that login authentication. Typically, a USERID and PASS columns are defined to support this.
When you take the application and run it on a server, now we run the app in an environment that does provide authentication (Active Directory/LDAP for example) that is in use across an entire enterprise. Being that the server environment provides the authentication, there is no longer the need for the QlikView or Sense app to provide that. It should point to/reuse the existing authentication infrastructure and the approach would necessarily have to change in Section Access to reflect that. Hence, having an "Admin" user defined in the app is not needed as this can be defined elsewhere in the server environment using features such as security rules and streams in Sense for example. So one's thinking about Section Access needs to change to reflect the differences between a standalone environment vs a server environment. Furthermore, in a server environment, you would want to use NTNAME vs USERID and PASS for your Section Access table so that you can use your existing Windows domain authentication. The user has already been authenticated before they could even access QlikView/Sense. Whereas standalone, you would want to do the opposite. An ADMIN type user simply has no meaning in a server environment. Just users are consuming the app.
However, under server, there is an additional type of user that would have to be included in Section Access that is not needed in a standalone/desktop environment. This is a "service" account type of user, for example, the account that will run "batch" tasks to reload the app's data (but may not need any interactive access to that data). In Sense, the userid SA_SCHEDULER would have to be added to the Section Access table so it can be allowed to run reload tasks even though no one would login interactively to access the app and its data using that userid. In QlikView, it is the service account.
In summary, keep in mind the two environments are indeed different. One should not be thinking that the approach of Section Access in standalone mode can simply be reused in a server context. There is some commonality, but they need to be approached differently due to the different operational contexts.
One final point that I see in support all too often. When you consider a multi-app deployment, be sure to take into account how you might approach the design of your Section Access. Do you really want to have this hard coded in each an every application? What happens when a change needs to be made and you have deployed 100+ apps that all have the same Section Access code? One should consider using the $(include) or more appropriately $(must_include) feature and store that common code in external (albeit protected) files to be included at reload time. You could include files to point to Section Access code in one case for a "development" or standalone scenario and then to another for a "production" scenario when deploying to a server.
