Field Level Security
Field Level Security (FLS) is a feature in SuperSTAR that allows administrators to control access to data. Access to fields and/or field values can be limited for specific users or user groups.
Note
- You cannot use field level security to hide field groups.
- Field level security should not be applied to users who are SuperADMIN administrators. Configuring FLS for these users is not recommended.
- Do not apply field level security to the default summation option. This must always be available to all users.
- If you have weighted databases, do not apply field level security to the main weight.
- If field level security is applied to a field or field item that is configured as a mandatory field then users will not be able to access that database using SuperWEB2 as this is considered an invalid configuration.
For example, if you block access to an entire field with field level security then you cannot also make that field mandatory.
However, it is possible to configure a field to be mandatory if only some of the field items within it have field level security applied to them. This can be useful if you are restricting access to a subset of data for particular users, as it can be used to ensure that the results are always filtered according to the field with restricted values. For example, if you are blocking access to data for specific states you can require the geographical field to always be in the table so that users cannot see any data for the hidden states.
- Before you start configuring permissions, make sure you understand the Permissions Model - Inheritance and Conflicts.
Example
This example uses the standard Retail Banking database, which contains data for Australian States accessible via a geographic hierarchy.
In the example scenario a certain user (vicuser1) must only be able to access data for the state of Victoria; other users can see data for all states.
The following examples show the effect of implementing Field Level Security.
SuperCROSS
For vicuser1, only Victoria is available in the Area field:
| For other users, all states are available:
|
SuperWEB2
SuperWEB2 selection tree for vicuser1:
| SuperWEB2 selection tree for other users:
|
What can be Hidden using Field Level Security?
Field level security lets you hide the following elements in a SuperSTAR database:
| Element | Description |
|---|---|
| Cross-Tabulation Field | A complete field. SuperADMIN refers to this as an XTAB Field. |
| Value Set | Field at levels lower than the top level in the hierarchy. |
| Field Values | The individual values within a field or value set. |
| Summation Field | A continuous variable/measure available in the clients through the Summation Options. Do not use field level security on the default summation option, or on the main weight if this is a weighted database. This applies even if you are using the SuperWEB2 rules engine to override the default summation option. The default summation configured in the SXV4 must be accessible to all users. |
Example: Field
This example shows the effect of implementing Field Level Security to hide a cross-tabulation field.
User with full access: Marital Status field is available.
| User with restricted access: Marital Status field is hidden.
|
Example: Value Set
This example shows the effect of implementing Field Level Security to hide a value set.
In this database the geographic hierarchy is four levels deep (State/City/Suburb/Postcode), but FLS has been used to hide the two lowest levels from some users.
User with full access: hierarchy shows all four levels.
| User with restricted access: no access to the two lowest levels.
|
Example: Field Values
This example shows the effect of implementing Field Level Security to hide the field values.
User with full access: all values of Marital Status available.
| User with restricted access: no access to the values Unknown and Not Applicable.
|
Example: Summation Option
This example shows the effect of implementing Field Level Security to hide a summation option.
| User with full access: all summation options available. | User with restricted access: no access to Customer Profit option. |
SuperCROSS:
| SuperCROSS:
|
SuperWEB2:
| SuperWEB2:
|
When does Field Level Security Take Effect?
If a user has one of the clients open when you apply Field Level Security, the new settings may not take effect immediately:
| Client | When Does Field Level Security Take Effect? |
|---|---|
| SuperCROSS | If a user has SuperCROSS open when the settings are applied, then the Field Level Security will not be applied until the user closes and reopens SuperCROSS. |
| SuperWEB2 | If a user has a database open in SuperWEB2 when Field Level Security is applied to that database then the settings will not be applied until the user closes and reopens the database.
|
Field Level Security settings do not apply to users who are SuperADMIN administrators. Do not attempt to set any Field Level Security settings for these users.
You are recommended not to change the field level security settings for a database once it has gone live in your production deployment. Changing these settings may invalidate saved tables, recodes and user defined fields that users have created for the database.
How Do I Implement Field Level Security?
To learn more about implementing Field Level Security:
- Read the Permissions Model - Inheritance and Conflicts to understand how the permissions work together.
- Follow the instructions to implement Field Level Security in your system.
Complete Disclosure Control Solution
When implementing a Disclosure Control Solution, Space-Time Research recommends you use Field Level Security in conjunction with the Data Control API and/or mandatory fields.
If you use only Field Level Security for Disclosure Control, you will not necessarily have a complete solution. Field Level Security settings only apply to fields that are part of a cross-tabulation request. Users can still create cross-tabulations that do not contain the controlled field and therefore may still be able to determine some aggregate data about fields.