Intra-model security
This topic addresses:
- How do you "hide" some details of your model from model end-users?
- How do you give some users access to parts of your model, while denying other users to those same parts?
In both cases, we assume the context of a model running in ACP.
An ACP Group plan allows you to control access at the project level. You can manage the set of users with access to any given project, who can upload models or files (authors), who can manage users (managers) and who can run models (reviewers). The user portal provides an easy to use interface for managing users and models. This is the first and most commonly-used method for controlling access from ACP, and is the first mechanism you should consider using, but it is not the topic of the current page. This page looks at how to control access to parts within a single model.
Hiding model details
Suppose you don't want model end-users to see certain parts of your model. Maybe this is just to avoid overwhelming them with extra information. Maybe this is because you want to hide a proprietary algorithm or other IP from your client. Or maybe some variables in your model contain confidential information. The methods described in this section hide information equally for all model end-users.
Hiding definitions
The first technique is to hide one or more definitions. To do this, select the node(s) whose definitions you want to hide, or select a module if you want to hide all definitions in the module, and select Hide Definition(s) on the Object menu while you are developing the model in the Analytica Enterprise or Analytica Optimizer edition. (This feature requires Analytica Enterprise or higher).
You should consider saving a locked copy of your model (from the Save a copy in... option on the file menu), and publish this locked copy so that if anyone downloads your model and loads it into their own copy of Analytica, they won't be able to unhide these definitions.
A variable or function with a hidden definition continues to appear as a node on the influence diagram, and other attributes (including Title, Units, and Description) remain visible to the model end-user. The Definition cannot be accessed and appears as "Definition is hidden". Your own code within the model cannot access the definition directly either even by using Analytica expressions.
You should be aware that even though hiding definitions is quite secure in the sense that there is really no way to access a hidden definition directly in a locked model, this mechanism is not a fool-proof way of protecting confidential data, since it doesn't prevent someone from computing new results from the data. For example, even though the definition of X may be hidden, if you allow a model end-user to compute and view the result of X+0 from another variable, he would be able to infer the content of X's definition. Also, hiding a definition does not hide the result.
Definition hiding is an excellent mechanism for hiding proprietary algorithms.
Hiding nodes or modules
You can hide individual nodes, including module nodes, on an influence diagram so that these are not visible while someone is using the model in ACP. This also hides the module in the outliner view. A common arrangement is for the top-level diagram to contain an application user-interface, with a node named Model_details that contains all the logic underlying the application. The Model_details module is hidden from the end-users, so they only see the user interface.
To hide a node (or nodes), in Analytica Enterprise or higher (and in Analytica 6.3 or higher), while you are in edit mode, select and right-click on the node(s) to hide. Then select Hide in browse on the context menu. To see the effect immediately, toggle between edit and browse mode. In Analytica, end-users of models stay in browse mode, whereas model builders use edit mode. When the model is running on ACP, it runs in browse-mode, and hence, the node(s) do not appear.
When a node or module is hidden, it makes it very difficult to get to from browse-mode. There are situations where the hidden context can be accessed. For example, your own model logic can navigate to a hidden module, which is allowed (for example, using ShowWindow from a button or an OnChange event).
User-specific or context-specific access
Whereas the previous section looked at simple methods for hiding content equally for all users, this section considers the case where you want access to vary. It might vary by user, or by groups that the user belongs to, or by some other arbitrary logic.
This type of user-specific access control is part of your model logic. As a model builder, it is up to you to design the logic that determines what is or is not accessible.
The primary mechanism for restricting content is node hiding, except instead of simply selecting Hide in browse from the context menu, you need to write the "code" that determines when to hide or unhide content. The options available for this logic is unlimited -- any logic that you can code in Analytica expressions.
User Identity
Your user-specific access will most likely need to know who the current user is. Thus, you should NOT share your model as an email evite, which enables someone to use the model anonymously. Instead, you need to manage your model in an ACP group plan, requiring people to log in to use it, and granting any potential users access to the project that contains your model.
Your model logic can obtain the current user's identity by calling GetProcessInfo("User Identity"). In ACP, user identity is their email address.
You need to implement the logic that decides how to map this identity (along with other relevant factors) into permissions. You might utilize a permissions table, for example -- i.e., an Edit Table that maps users to permission.
Exposing or hiding content
Your logic will most likely operate by showing or hiding certain module nodes. For example, Jane may have access to the Staff module but not the Company financials, whereas John's access might be the other way around.
For an example of permissions logic (yours might be different), let's suppose you have the following indexes and table set up:
Index User := [ 'jane@acme.com', 'john@acme.com']
Index ACL := ['Staff', 'Financials']
Next, create a button that sets up the visibility of the modules initially.
Button Initial_access
OnClick :=
Local perms := Permissions[User=TextLowerCase(GetProcessInfo('User Identity"))];
ChangeNodeVisibility( Handle( Staff ), If perms[ACL='Payroll'] Then "Visible" Else "Hidden" );
ChangeNodeVisibility( Handle( Company_financials), If perms[ACL='Financials'] Then "Visible" Else "Hidden" );
From desktop Analytica while in edit mode, right-click on this button and select Run at load time. When the model is first loaded, this button will set the initial access based on the user and the Permissions table. This is a simple example of one possible organization of the logic. To be ultra safe, you may want to hide all modules before you upload the model (using the Hide in browse option described earlier), so access will be denied by default should your button logic fail in some way.
Using the ChangeNodeVisibility function, your model logic can change visibilities during a user's session. This might occur from other OnClick or OnChange events.
Enable comment auto-refresher