In Pigment, Access rights are defined at the application level through User roles and customized by Access rights rules and options. This article discusses the different factors to consider when implementing an Access rights configuration.
Table of Contents
This article is based on the current Access Rights system. You can identify which system you are on by navigating to Roles, permissions & access section and seeing if you see Version: Legacy or if there is an Unspecified option for read or write permissions within a Role then you are on the Legacy system. For more information, check out this article.
What are Access rights?
Access Rights are a form of data security that allows you to configure what data individual users can see and interact with. This is different from Permissions, Permissions define the actions a Member can take, such as Creating new Metrics, Boards, and Lists. To better understand the basics of Access rights, please refer to this article.
Understanding the Impact of the User Role on Access rights
In order for a Member to have access to an Application, they must be given a User role. Each Role has a Default Read and Write setting for Access rights. This will become the default setting for the entire Application before applying any other Access rights rules.
Because the most restrictive permission will always override the lesser restrictive, this becomes a critical decision.
If you set your Role’s Access right settings to Write vs No Write, this means you will have to use additional rules to restrict all data that you do not want to be writable. If you do the opposite and set it to No Write, you will have to use two additional rules.
One to state where the User Role does not apply and another to set additional rules to apply writable access. While this approach requires multiple rules, it is the recommended approach for a more secure Application.
This also applies to when setting Read vs No Read Access rights.
Access rights only controls access and interactions to data, Access to Boards is controlled by User roles and/or customizing those permissions with Board permission metrics
Understanding the Impact of the Application Level Access Rights inheritance
When setting up your data security plan, it's important to understand Inheritance of Access rights, please refer to the linked article.
Early on in your plan, you want to decide how you want to handle inheritance, you can handle it at the Metric level with the use of RESETACCESSRIGHTS() or you can remove the inheritance at the application level by adjusting the inheritance options. While there are different methods to easily identify if the Access rights are being directly applied or inherited, making a decision early on will help you with troubleshooting and confirming Member’s Access rights.
Considerations when creating an AR Metric
Creating Access Rights Rules for Individuals
While the Access rights default configuration is established at the Role level, Access rights rules are assigned to each individual. This means you can establish two different access rights configurations for Members with the same Role.
For example, two Members can be set up with a Role called Country Manager. When setting up an Access right rule, you can establish one Member can read data in the US, while the other can read in France.
When creating an Access rights Metric, the following conditions are necessary;
- Data type - Set to Access rights
- User list must be present to have different settings for different users
- Dimension List to which security is to be applied to, must be included
It is important to think about what the overall goal is for an Access rights Metric.
Will the Access right Metric be used as a Read, Write or Read & Write rule?
When setting up an Access rights Metric to configure a Rule, you will have to define the type of Rule. This means it can apply to Read access, Write access, or a combination of both. For example, if you select only Read access for Rule type, Pigment will ignore the Write part in your Metric, regardless of how it is set up in the Metric.
It is common to use a Metric for multiple rules so this stresses the importance also of an aligned on naming convention.
How will the Access Metric’s data be populated?
While it is possible to manually populate data in an Access right rule, it is not very scalable. In most instances, you will create other Metrics and reference them with the ACCESSRIGHTS formula. You might have one Metric referencing Read access and another influencing Write access. In most cases, you will want to have these visible on an Board designed for Admins.
Where do I want to apply these Access rights configurations?
It is important to plan exactly where you want to control access to your data, whether it be on a Transaction list, Dimension list, or Metric.
If on Metric’ data, do you want to apply it to All Metrics with that dimensionality or only some specific Metrics?
If for data on Transactions or Dimension lists, are you applying it to the item’s values or for properties on that list?
In all cases, it's important to remember the impact of Access inheritance if it is still activated. If activated, and you have an Access rights rule on an Item’s property, this means all Metrics that reference it, will inherit that configuration (see this article to understand inheritance).
Removing the User role to apply a new Access right rule
While building your Access rules, the most restrictive rule will always prevail. This means that a rule preventing access to some data will always be prioritized against a rule that gives access.
Therefore if you set the default access of a Role to No Read or No Write, you must write another Access right rule to remove that in order to give Read or Write access or Pigment will always select the more restrictive selection.
Blank is considered a restrictive setting and will override a Read or Write setting to result in No Read / No Write. This is why it will become important to establish the Rule Type and if the Metric should apply to Read/ Write or both settings.
For example, if you had your User Roles set to No Write and and you wanted to provide Write access to Members on a Specific Metric.
First, create an Access right rule that states User Roles does not apply to the area you wish to add a new Access rights rule to, in this example it is Specific Metric(s).
Next, create your new rule and configure it for the area you wish to apply new Access rights. This allows you to give Write or Read access to Members that have been assigned a User Role that was set to No write or No read.
Whenever removing the User Role rule from an area of an Application, we recommend using part of your formula to ensure that admins still can have access. If you are going to manually input the configuration, you can still enter this formula and just turn on the ability to override formulas.
if('Users roles' = Role."Admin",accessrights(true,true)
A typical access rights setup
Now let’s bring everything together to describe a typical Access rights setup in an Application.
Members must have the Define Application Security Permission to view the Roles, permissions & access page.
Step 1 - Establish the Default Access Rights per Role
Navigate to the Roles, permissions & access page and click on the Roles Tab. Hover over each Role and click the pencil icon to set the Read and Write permissions for the Roles. This will define the default setting for all blocks in the application and then every user who is assigned these Roles.
Typically, the Admin Role would be set as READ /WRITE and other Roles would typically be READ / NO WRITE.
Step 2 - Create the Metrics and Rules for your READ setup
While you do not need to establish READ before WRITE and can do them at the same time, we have separate setups to highlight the difference.
Next, Create the rules for defining the areas of the Application individual Members should be denied Read access. This is done with Access rights Metrics and the formula ACCESSRIGHTS to scale it out.
Depending on your security needs, you might set up an admin Board with Metrics to input information about an individual to feed into the Access rights Metric
The Metrics and Rules for Access rights should be set to deny the ability to Read for specific users in those Roles using No Read as the result. This is because the Role settings granted Read to the entire Application
Step 3 - Create Does Not Apply Rules to remove default setting for Write
Since the most restrictive setting always takes precedence and the User Roles were configured as No Write, you need to remove that setting from areas where you intend to allow write access. This is done by creating an access right rule set to Does not apply to.
Step 4 - Create the Metrics and Rules for your Write setup
Remove User Role
Once you have removed the restrictive setting of the User Role, you need to add a new Rule establishing Write permissions.
In our example, we are using the ARM_Cost_Center_WRITE Metric to apply our rule. Notice the naming convention, ARM is the prefix to establish this is an Access Right Metric(ARM). Then the suffix of WRITE was added to easily identify this as a Write Metric to be used with a Rule type of Write.
When setting up these rules, make sure to include in your formula an exception to define the WRITE access needed for the Admin Role as an exception.
if('Users roles' = Role."Admin",accessrights(true,true)
Here is a very simple example that shows the rules. You can see the Write rule applied to the same 5 Metrics that the User roles default settings have been removed from.
If you prefer to assign No Read access by default in the Role to ensure maximum security and limited access by default, you would have to use the same steps as for Write Access defined in Step 4 above, to assign custom Read access.