Although the access control rules allow you to explicitly include dimension values by using the limit-dimension and limit-rows-by-values tags, DI recommends that you do so only on a limited basis.
As a best practice, DI recommends that you separate the access control rules from any data values. You can achieve this separation by using properties. By separating the access control rules from the data values, you can set the rules once based on the properties and not touch them again. Once the access rules are set, security is addressed at the user and group level by property values assignments. As users come and go, or change roles in the organization, you adjust the property value assignments either for the specific user or for the groups that the user is a member of. Not needing to modify access rules, but just the assigned values, minimizes errors that could upset existing security settings for users.
Defining and Assigning Properties
You define properties on the server and associate values on the Server Setting > Properties tab. You define rules using those properties. When you create users or groups, all properties are available. If you want a property to apply to a user or group, you set the assigned values as part of the profile on the Server Settings > Users > <user> > Properties tab or Server Settings > Groups > <group> > Projects and Properties tab. When users log in, access rules are applied based on their assigned properties and values. That is, when the system determines a particular user's property values assignments, it takes the union of all the values contributed by assignments for the groups that this user is a member of, and any explicit assignments for the particular user.
NOTE: It is always best to use role-based assignment when possible. If you tie rules to a particular user, you create a maintenance headache as people come and go. If all access is done using groups, it is simple to move users in and out of groups as needed. This means that it is best to assign property values at the group level whenever possible.
For example:
Suppose you have a cBase with Sales Region data. The Salespersons are allowed to see all data for their region. You could define a property called Allowed Regions on the server and have for values the individual regions. Then, create the rule to limit access based on that property. For example, define a row-based cBase rule for all users that limits the column Sales Region to values in the Allowed Regions property.
The Salespersons are assigned to groups, and each group has the Allowed Regions property set to the value of the region name; for example the group North has the value North, and the group Boston has the value Boston.
cbase-access {
limit-rows-by-property {
column "Sales Region"
property "Allowed Regions"
}
}
Each Salesperson who opens the cBase sees data according to the assigned values for the Allowed Regions property.
TIP: Property value assignments can be set from an external file. You could, for example, have a nightly external process that creates a flat file used to update property values and assignments. Once set, the rules do not change—just the assignment of values to properties.
See also: