When designing a BI or CPM solution with Jedox we often deal with a wide variety of users with different roles and responsibilities in their business domain. The security structure should therefore mirror these roles and responsibilities in order to restrict the users, if necessary, in their accessibility of data and capability of data entry. In order to realize a flexible and transparent structure, Jedox provides the designer with a lot of options. In this two-part blog, I provide an overview of all available options, their effects, and how to select the right option(s) for your security requirements.
Security options
Security design within Jedox is very flexible and provides a designer with the possibility to apply user security restrictions as low as cell-level all the way up to the level of the database (referred to here as model-based security). However, since one Jedox installation can consist of different solutions and databases, there’s also the possibility to implement system-wide security based on user groups and roles (referred to here as system-based security). Following the previous blog explaining the available system-based security options, this blog explores the more specific model-based security options in Jedox.
Model-based security in Jedox
Cube level security (model)
When building planning and control solutions for large organizations you are often dealing with a wide range of business departments. Business users within these departments carry the responsibility for different business functions and activities that require their own models and structure for effective analysis and reporting. All users require access to the underlying database for this solution, however, they usually have to be restricted when it comes to the specific data they need to be able to see and manipulate.
Therefore, the end-users’ access rights should be limited to certain database objects. The highest level of objects in the database are the cubes. As illustrated in the previous part, different business functions often require their own structure and models for effective analysis and reporting. To facilitate this, separate data storage in several different cubes with their own specific collection of dimensions and business rules is likely. During the design process of the multidimensional data model, several user management cubes are created in the background automatically. These user management cubes provide the means to restrict the Jedox users in their access rights within the database and are available through the user management database. One of these cubes, the #_GROUP_CUBE_DATA cube, allows you to restrict access rights to different database cubes based on user group.
In short, this functionality allows you to restrict user access to only those data cubes they require to perform their tasks and responsibilities while other cubes (with potential sensitive data) can be fenced off. An example below depicts how this cube level security can be implemented:
Example: Sensitive data in the organization
Context: A comprehensive planning and control solution has been implemented for a large construction company. This entails a multidimensional model has been created with several different cubes that seamlessly fit onto the business functions within the scope of the project. In this case, separate cubes were created for personnel planning, project planning, and a separate cube for the entire P&L. These cubes include company wide data on all business units and departments, however, not all users should have access to all of this data. Generally, a project controller should not be able to access the personnel planning cube, because this likely contains sensitive information on FTE’s, salaries and the like.
Solution: To make sure the project controllers cannot access the sensitive information that is stored in the Personnel Planning cube we have to make sure that these controllers are contained in one or more user groups. Subsequently, the #_GROUP_CUBE_DATA cube from the user management database is used to restrict access for these user groups to the specific cubes within the database. As depicted in Figure 1, the user group project controllers has full access to the Project Control cube, read access to the P&L cube, but they cannot access the Personnel Planning cube. Only the user group personnel planners has full access to the Personnel Planning cube.
Dimension level security (model)
When building planning and control solutions within Jedox we can optimally utilize the multidimensionality of the database to slice and dice through the data in the cubes. This allows users throughout the organization to consult data from multiple different points of view. However, users with different responsibilities might not be allowed the same level of access throughout the whole cube. For instance, a sales planner for one specific product group should not be able to consult or manipulate the data from another product group. Therefore, security restrictions on database or cube level is not sufficient.
The next level of security (and the most appropriate for the described situation) is on individual dimensions cubes consists of. These dimensions consist of one or multiple elements that may or may not be structured into different hierarchical levels, forming a so-called hierarchy. On each of these hierarchical levels and each element you can specify security through the #_GROUP_DIMENSION_DATA_{Dimension_name} cubes in the user management database. These cubes provide the means to restrict access rights to one or multiple cube sections by security specification on the elements within a dimension. NB: The security restrictions that have been applied on a single dimension will apply on all cubes that contain this dimension.
To summarize, this functionality allows you to restrict access to specific data sections within a cube based on the rigid allocation of user rights on elements in a dimension that is contained in a cube. An example below depicts how this dimension level security can be implemented:
Example: Sales planning for different product groups
Context: A simple sales planning solution is implemented for a manufacturer of consumer bikes. The solution consists of a Sales cube that is used by the sales planners to consult their actual sales and to enter their budgeted and forecasted sales for the future. Each of the sales planners carry the responsibility for a specific product group and are required to provide their estimates for budgets and forecasts throughout the year. Therefore, security restrictions should be implemented based on the Products dimension within this cube.
Solution: To make sure the sales planners can only enter budgets and forecasts for their own product groups, we first have to make sure that they are contained in different user groups (e.g. Bikes sales planner, Clothing sales planner, Accessories sales planner). After that, we apply security restrictions in the #_GROUP_DIMENSION_DATA_Products cube in the user management database. As depicted in Figure 2, the user group Bikes sales planner has full access to read and write data for all products contained in the hierarchy under the consolidated element Bikes. On the other hand, he only has permission to read data for the products contained in the hierarchies under Clothing and Accessories. So, regardless of the settings in the designed application screens, the Bikes sales planner will never be able to alter any sales data on Clothes and Accessories. NB: In order to ensure that Actuals are never over-written, it is also advised to apply security restrictions on the Datatype dimension.
![Applying user rights in Jedox 2]()
Cell level security – rigid (model)
When security restrictions are dependent on a certain composition of elements (coordinates) within a single cube, a simple set of security restrictions on multiple separate dimensions might not be enough. For instance, a user should be able to alter data for a specific section made in one dimension, but only when the user is in a specific sub-section determined by the selection of elements in other dimensions of the cube. For this reason there is also an option to specify cell level security to target specific coordinates in a cube.
Cell level security is based on the collection of dimensions contained in the targeted cube and the user group that applies to a certain user. This allows us to apply security restrictions on any specific cell (coordinate) contained in the cube. You can do this via the user management database by selecting one of the #_GROUP_CELL_DATA_{Cube_name} cubes. Similar to a paste view of actual data cubes, you can paste a view of this cube on your screen and apply the desired level of security on the specific coordinates you would like to target based on the user group selection in the #_GROUP_ dimension.
To summarize, this functionality allows you to restrict access to specific cells within a cube based on the rigid allocation of user rights on a specific coordinate in a cube. An example below depicts how this cell level security can be implemented:
Example: Product only sold in specific period of the year
Context: A company has implemented a sales planning solution where they can consult and plan for their whole range of products. Unfortunately, due to a change in legislation for a specific category of products (Stationary PC’s), these products cannot be sold in a specific geographical region (West) after June of the following year (2016). Sales planners responsible for these products should therefore not be allowed to enter forecasted sales units for those regions after month 6 of next year.
Solution: as you probably noticed, application of dimension level security is not sufficient enough for this situation. Since only one category of products is affected you cannot apply security restrictions on either of the time or region dimensions without affecting all products. For this reason we have to turn to the #_GROUP_CELL_DATA_Sales cube from the user management database and apply security restrictions on the set of coordinates that should be un-editable (and thus 0) from month 6 of the following year for the specified product category. As depicted in the picture below the user group sales will not be able to input budgeted values for Stationary PC’s in de West Region for Qtr.3 and Qtr.4 in 2016.
![Applying user rights in Jedox 3]()
Cell level security – flexible (model)
Additionally, when building solutions including workflow, the rigid application of cell level security restrictions might not be sufficient. This is due to the variable and situation dependent implications on security restrictions. For instance, a sales planner can only enter new budget values when the budget planning cycle is still active, but as soon as the budget is final no more changes should be allowed. Usually workflow status is contained in separate cubes or attributes so in order to apply the right security restrictions at the right time you need to be able to include these dependencies.
So, next to the rigid cell level security, Jedox also provides flexible cell level security rules on user management cubes. Rules allow you to implement cell specific but variable security for any of the defined user groups. You can do this by right-clicking a #_GROUP_CELL_DATA_{Cube_name} cube in the user management database and define a new rule in the rule editor.
This functionality allows you to restrict access to specific cells within a cube based on the definition of rules in user management cubes. A brief example below depicts how this cell level security can be implemented:
Example: Sales planning status is updated
Context: a company implemented a sales planning solution but now wants to implement workflow in order to facilitate the phased budgeting cycle for their product lines. A sales planner should be able to enter the budgeted product sales for the upcoming year and then submit these to the regional manager. Subsequently, the regional manager should be able to check and alter the budgeted product sales upon approving the proposal or rejecting it for alterations by the sales planner.
Solution: simple dimension level security or defining a rule on the regular Sales cube will not work in this case (the latter because it’s dependent on the user group whether coordinates should be editable or not). So, after the introduction of a Status cube that allows for the storage of the budgeting cycle status for each product or product group per year, a rule on the #_GROUP_CELL_DATA_Sales has to be defined. This rule will apply user group specific security restrictions based on the status in the Status cube. As depicted in Figure 4, you can see that two rules have been implemented. The first rule determines when the sales user group can enter budgeted sales and when they can only read their budgeted sales. The second rule determines when the manager user group can adapt the budgeted sales and when they are only allowed to read the budgeted sales.
![Applying user rights in Jedox 4]()
![Applying user rights in Jedox 5]()