5.9.3 Data Security with Materialized Views
If you are using a VPM to filter data based on particular users, you should generally enable the 'Create Materialized View for all users in group' option. This allows custom materialized views to be generated for each user (based on their individual VPM permissions). If this option is disabled, only the group name will be available to the VPM, and the filter will not be correctly applied for users.
Implementing Security at the Data Block Level
In some cases, the VPM-based approach described above may generate too many distinct materialized views when security is applied at the user-level. In this case, you can substitute Data Block filtering in place of VPM-based filtering. To implement Data Block filtering, follow the steps below:
1. Place a filtering condition directly on the Worksheet Data Block that supplies data to the Viewsheet. (See Using a Parameter in a Condition in Data Mashup for directions.) The condition should include a parameter that filters the Data Block appropriately for a particular user. For example, the condition
[First Name][is][equal to][$(_USER_)]
filters the Data Block based on the user name by using the predefined variable _USER_ (which supplies the name of the currently logged-in user). To filter on a property such as the user's corporate customers (i.e., companies), simply define your own variable to store the information:
[Company][is][one of][$(comp)]
The value of the variable (comp) will be provided by the SRPrincipal object as explained in the next step.
2. (Optional) Use the setParameter() method of the SRPrincipal object to assign a value to the Data Block condition variable. You can do this from within an external module (e.g., an SSO request filter or Login Listener) or from within an internal Viewsheet script.
a. From within an external module, assign the desired user data to an SRPrincipal parameter of the same name as the target variable. For example, the following Login Listener assigns a set of companies to the 'comp' parameter:
See Accessing the User Session with SRPrincipal in Integration for alternate SRPrincipal access.
import inetsoft.sree.security.*;
public class MyLoginListener implements LoginListener {
public void userLogin(LoginEvent event) {
SRPrincipal prin = event.getPrincipal();
prin.setParameter("comp", new String[] {"Ubermeyer", "Rutgers Bank", "Bigmart Foodstores"});
}
}
b. From within a Viewsheet script, assign the desired user data to an SRPrincipal parameter of the same name as the target variable. For example, the following script assigns a set of companies to the 'comp' parameter:
var p = parameter['__principal__'];
p.setParameter("comp", new String[] {"Ubermeyer", "Rutgers Bank", "Bigmart Foodstores"});
These procedures pass the desired user data (e.g., companies) directly into the Data Block condition. If a materialized view has been generated for the data set, the condition is applied to the post-materialized data set, extracting the appropriate data for the logged-in user. There is therefore no need to generate a distinct materialized view for each user.
Multi-tenant Considerations
For multi-tenant implementations utilizing the multi-connection feature, materialized views are created based on user/group connection assignments. For this reason, if you set a Viewsheet's permissions by role (on the Viewsheet's Security tab), you should also add individual permissions for users or groups that have particular connections. This will enable the materialized views to be generated from the appropriate connections.
See Also
Configuring Viewsheets, for information about setting Viewsheet security.
Adding Additional Connections, in Data Modeling, for information on connections.
| << 5.9.2 Incrementally Updating a Materialized View | © 1996-2013 InetSoft Technology Corporation (v11.5) | 5.9.4 Materialized View Performance Considerations >> |