DiveLine Security: 6.x versus 7.x

Security in 6.x—Grant access to objects based on a user (or group)

• Users log in
• Users may be in groups
• Access Control Lists (ACLs access control list. The security tool that DiveLine 6.x uses to control user and group access to the server. DiveLine 7.x applies access control rules to projects and can apply ACLs to non-project resources that use the 6.4 DiveLine namespace.) are developed for users and/or groups
• Directory, file, or model level ACLs could be set
• The DiveLine variables $USER and $GROUP allow the comparison of user and group names to dimension values in the data
• When conditional rules for a dimension are applied, they are OR'd together— expanding access
• Possible hierarchy of rules: specific user, groups the user may be in, or a catch-all * user (default). The * rules only apply if no other selectors for group/user matched. The most specific category gets chosen, allowing for default-deny setups. For example, in general, deletes are done in a default-allow style, but some have used the * rule to delete columns for everyone, with certain users or groups having that rule replaced with one that only deletes some (or none) of the columns. That is effectively a default-deny setup.
• Default-allow approach requires caution

Security in 7.x—Use properties to separate the rules from the data and simplify maintenance

• Users log in
• Users may be in groups
• Users and groups are granted access to projects
• Properties are defined on the server
• Users and groups may have property values assigned
• Access is defined at a directory or project level, based on user, group, and/or user/group property-value pairs
• Property-value pairs may be directly compared to dimension values in the data
• Conditional rules on rows are applied, then rules are AND'd together—narrowing access
• There is no hierarchy of rules
• Default-deny approach is safer than default-allow
• Divide tasks between developers and administrators

• Users, groups, and user/group property value pairs are maintained in server settings
• Access rules are maintained within the project
• The person who sets up users may not be the same person who develops the application or sets the rules for access.
• Aim to have administration handled on the server settings side—it should never be necessary to change the access rules.

• Let the data define the access rules
• Develop rules in terms of properties
• Develop property files to describe who can see what—assign property values to users and groups
• User properties and their selected values may be maintained externally, and placed in a file to be read by DiveLine at the time of access.
• User properties and their selected values may be maintained manually in Workbench.

For 7.x, the best practice is to define and use properties. If done for groups, the maintenance will be less of a burden than if done for users. Think in terms of the roles individuals play, rather than the individuals. Define the groups and their property-value pairs.

NOTE: Property values for different groups are all considered (OR'd together) when evaluated for an individual user who is in multiple groups. That is, the values for a property assigned to the individual, plus the values for that same property assigned to the groups the individual are assigned to, are all used when evaluating access control.

A common scenario is to build into a model a dimension that has as its value the salesperson's login username. The global 6.x variable $USER can then be used to limit access to only that part of the model associated with that salesperson. If you are using the 6.4 DiveLine Namespace project in Workbench and, have models and ACLs configured this way, they will continue to work.

It is still possible to include usernames in 7.x models and cBases and place limits on the data seen by using the current user's DiveLine username. This is not done using $USER but with the directory's access control rules. For cBases you can use the tag limit-rows-by-username-column or, if you are writing a custom expression for use with the tag limit-rows-by-filter, you can use the calc function current_user(). For models, a similar tag exists: limit-dimension-by-username.

A cBase example is shown here:

The generated access control script snippet is shown here:

access {
  . . .
  cbase-access {
      limit-rows-by-username-column {
          column "Sales Manager"
      }
  }
}

A model example is shown here:

The generated access control script snippet is shown here:

access {
   . . .
  model-access {
     limit-dimension-by-username {
         dimension "Sales Manager"
     }
  }
}

NOTE:

• Model rules use limit-dimension tags because you are placing a limit on valid values in a dimension.
• cBase rules use tags involving rows because cBases do not designate certain columns as dimensions or not.
• Tags such as if-group, if-user, and if-property are all used to make the rule conditional. Rather than applying to all users, they only apply to those who pass the if test.

Configuring limits on dimensions is fundamentally different between 6.x and 7.x, and between models and cBases.

For Solution 6.x ACLs, new Limits on the same dimension in a Model add records that the user can see. If one group limits the user to Region “North”, and another group limits that same user to Region “South”, then both limits will apply and the user will have access to all records for both "North" and "South"—limits are OR'd together—expanding what can be seen.

In 7.x access control, the method of resolving same-dimension limits in Models is the same as in the 6.4 DiveLine namespace. The code translates this new style of limits into the same internal representation used in 6.x. This makes it easier to replicate certain 6.x ACLs.

However, for cBases, same-dimension rules are not combined. Each of the row-limiting rules which pass their condition are processed and converted into a Spectre expression—then all the expressions are AND'd together—narrowing what can be seen.

Setting cBase limits via limit-rows-by-values is not additive like setting model limits via limit-dimension. In addition, explicitly putting dimension values into the access control file via the limit-dimension and limit-rows-by-values tags is inefficient. It is a better practice to separate the access rules from the data values. This is done using User Properties. See Properties: Separating Access Control Rules from Data Values.