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). This blog briefly explains the available system-based security options, while the next blog elaborates on the available model-based security options.
System-based security
System level security (system)
During an implementation project of Jedox you usually distinguish many different roles. Generally, there’s the technical administrators responsible for building and maintaining the data model, the functional administrators responsible for providing user account access, the designers responsible for interface development, the power users with in-depth knowledge and full access to the (required) functionality of the application, and the end-users of the application. Due to these different roles and responsibilities, they require specific access rights to the different Jedox components, as depicted in an example in Table 1:
These security rights can easily be implemented by assigning either of the built-in Jedox roles to user groups within the System Manager. However, some users might take on multiple roles requiring the definition of a custom role and adapting the many different role-parameters. This system level security provides you with the ability to assign all members within the project team with the access to all Jedox-components required for them to perform their primary tasks. Below follow two brief examples depicting when and how to use system level security:
Example 1: Designer
Context: After the initial database model is created and the required data is loaded into the cubes, a designer is appointed create the application interface in Jedox. Therefore, this designer needs to be able to access the OLAP-model to subtract the required data, the File Manager to create the required screens and dashboards for the application, and the Report Manager to check the flow and collaboration throughout the application. On the other hand, this designer does not need access to the System Manager, the Task Manager nor the Integration Manager.
Solution: In order to adhere to the abovementioned requirements, the System Manager provides the possibility to assign the built-in designer role to a group with designers and then alter the involved parameters. For instance, among other parameters, the parameters for rights, Integration manager, user, etc. are changed from Full Access to No access.
Example 2: Different end-user roles
Context: After the database model and the interface have been finished, the targeted users can start using the application. However, among the end-users, we can distinguish users who can only consult and write-back data through the web interface (e.g. sales representative), while another group of users should be able to perform additional ad-hoc analysis through the Excel add-in (e.g. business controllers).
Solution: In order to adhere to the abovementioned requirements, within the System Manager you can assign the first user group with the editor role, while the latter user group will be assigned the poweruser role for additional functionality. Based on the detailed access requirements, the role parameters can then be altered accordingly or a new role with similar parameters can be created.
Database level security (system)
The implementation of Jedox within an organization allows you to run more than one solution on the same server. In order to keep database size limited and performance high, the decision can be made to create two separate dedicated databases instead of one database that feeds both solutions. Especially when the two solutions are not (or only slightly) overlapping, this seems to be a valid option. However, the user groups and roles are registered system-wide. This means that the registered Jedox users cannot be restricted in their access rights through the management of their roles, because they might require different roles in each of the solutions (and their respective databases).
So, in order to maintain a flexible design, you can assign specific system access rights to the different databases running on your server. The means to these database level access rights can be found in the separate built-in System database. The System database contains a collection of cubes that allow you to control the user, user group and role assignments and properties that you can also set via the System Manager in web. However, there is one exception; the #_GROUP_DATABASE_DATA cube. This cube allows you to assign specific access rights for each of the user groups to the different databases running on the server.
To summarize, this functionality allows you to run different solutions (and databases) on one server with only one pool of users regardless of their roles in either of these solutions. Below, an example depicts how this database level security can be implemented:
Example: Demo server for prospective Jedox clients
Context: A Jedox partner would like to provide prospective customers with the possibility to work with a ‘proof of concept’ before they decide to purchase the software. This partner custom builds these models and the interfaces on a regular basis. After building these ‘proof of concepts’ the partner wants to provide the prospects with easy access to a central environment dedicated for prospective customers that allows them to see and test their requested solutions from the comfort of their own offices and without any Jedox installation.
Solution: The partner can arrange for a dedicated demo-server that is accessible from anywhere through URL. This server has only one Jedox installation and one pool of users. For each prospect the partner creates a new database and interface that comprise the ‘proof of concept’. However, the prospect should only have access to the ‘proof of concept’ that was designed for him. Therefore, a new user and user group for this specific prospect is created and the #_GROUP_DATABASE_DATA cube is used to restrict the access to the specific database for this ‘proof of concept’. As depicted in Figure 1, prospect 1 and prospect 2 were only given access to their respective ‘proof of concepts’ (i.e. POC1 and POC2) and the demo-databases (i.e. Demo and Biker) but not to each other’s.
The post Applying user rights in Jedox (1): System-based security appeared first on Jedox BI Blog.