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.
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.
For vicuser1, only Victoria is available in the Area field:
For other users, all states are available:
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:
|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.|
A continuous variable/measure available in the clients through the Summation Options.
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.|
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?|
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.
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.
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.