Data Access Control Architecture

Center of Excellence

1. Abstract

Database and Application security refers in general to the range of tools designed to establish and preserve data confidentiality, integrity, and availability.

In Board terms it is the definition of the various access levels so that the users are presented and can modify only data relevant to them and for which they have been authorized.

2. Context

The purpose of this article is to explain how the different security and data access layers interact with each other and the best practices to follow during implementations.

3. Content

3.1 DB and Roles Security

3.1.1 The security layers and why they are necessary

The most important security layer of the Board applications is “Database security”.

This is essentially an area of each Board database where developers can create “DB Profiles” which contain, amongst other features, security selections on entities that are specific to that database.

DB profiles can then be attached to a Role and then the Role is assigned to a user. This way the selections performed at the DB profile level are propagated to all the Roles/Users that share that security profile.

On top of these DB Profiles selections, a developer can add extra selections also at the Role level directly. These roles’ specific selections will essentially be applied in the same way as the DB profiles ones.

The Roles’ selections layer allows also to set up the security in a more dynamic way or easily change it in case of security reorganizations, through the usage of Sub-Hub metadata. Please refer to the dedicated material to understand more about the Sub-Hub metadata setup.

Starting from Summer 2023 version, this selection in the DB Security/Roles Layer will also be “based on cube” and not just fixed. The end result is the same, a static security selection is calculated at login and then does not change for the entire session.

Regardless of how they are technically activated all the above layers generate “Selection” which are:

• Fixed: in the sense that they are applied throughout the data model in the same way and do not vary based on the application usage
• Refreshed at login: if a change is applied it becomes active when the user logs in again.
• Entity-based: they are a simple list of items that can be accessed for that entity and do not allow to set access to specific combinations of entities’ elements (i.e., matrixial security)
• DB specific: they are set for each DB separately; again, here the Sub-Hub metadata setup can help to simplify the security management if multiple DBs are active on the same instance

The layer briefly described above is the ONLY repository of Security definitions in the Board. This means that they are the only feature that allows segregating user access without any possibility to bypass it for end users. Only the Admin/Developer users can change that.

For this reason, the best practice is to always define these levels of security. We see many projects where the security is defined on the application level with custom selection processes embedded into the navigation, however for the reasons explained above that does not guarantee a secure application. In particular:

• since these application-level controls are defined at the application level they will not be executed in case there are application or DB failures, or it will be possible for certain users to remove them (i.e. power users, no Admin developers, etc.).
• many native Board features will have to be disabled to prevent users from bypassing the application level controls (i.e., Screen list, Selection window, edit layout, etc.)

The second-best practice is to keep the number of Roles and DB profiles to a minimum. The idea of the roles and DB profiles is to structure them so that they are generic, and can cover all users with the minimum setup. Having a lot of profiles/roles would increase the level of maintenance required. Again here, the Sub-Hub metadata setup can help to reduce the need for many Roles/DB Profiles.

Finally, a last best practice is to leverage appropriately the Folder profiles feature. This is a feature that allows to set up for each capsule folder a series of access rights. This does not replace the best practices above but can remove complexity from the overall data access architecture design and implementation. To use at its full potential this feature, however, it is required to apply also another best practice which is to use the “multi-capsules” approach.

The next paragraph will explain how to decide which Entities should be included in the security layer and therefore help developers to practically define the structure of DB Profiles/Roles.

3.1.2 Which entities should be included in the Security Layers?

Practically speaking the most important decision when designing the Security architecture of a Board data model is to decide which dimensions should be included in the security and which ones not.

Usually, these entities are quite clear to the customer so it will be natural to decide which entities should be part of the Security layer and which ones not. However, the following characteristics can be considered to guide/simplify the decision process.

An entity should be added to the security layer when it is:

• Stable and Valid for the entire session: authorization does not change frequently over time and not in the middle of the user session; an example of this is Company/Cost center, users typically are authorized to a certain company and their authorizations on this dimension do not change very frequently.
• Mandatory: the entity defines a perimeter of access which should never be crossed, regardless of the process or application status; for example, Department = HR, users who are not authorized to see HR-related data should be clearly marked.
• Not matrixial: the perimeter of work does not change in combination with other entities.

By adding these entities to the DB Security/Roles Layer we will make sure that data is truly secure and not accessible where not authorized.

Moreover, in case of application failures, we will confine potential errors and make sure that users can delete/compromise only datasets within their security setup.

3.1.3 How are the Different Security layers interacting with each other?

From the previous paragraphs, other best-practice documents, and the manual, we can see that there are several layers in Board to define security on Entity elements. In this paragraph, we would like to describe how they interact with each other and eventual best practices. These are the different layers which can be identified:

• Roles selection
• DB profile selection
  1. Security selection
  2. Custom selection script → manual or through Metadata
  3. Select Entity based on cube
  4. Cube Visibility

The main area for security is the DB Profile. Here we have most of the security definitions.

When defining the security in the DB profile section we should keep in mind that:

• The manual security selection is overwritten by the “Custom selection script” if applied to the same entities.
• The custom selection script can be populated manually and linked to variables like the @User or any User Metadata defined on the Sub hub.
• The result of these two areas is then further restricted by the “Select based on cube” security.
• Finally the “Cube visibility” is applied

This kind of interaction is displayed in the picture below:

The “manual selections” and the “Custom selection scripts” can be defined also at Role level:

These selections at role level are meant to enrich the flexibility given to Makers when defining the security architecture. For example, define certain entities at role level and then further restrict them at DB level. The best practice here is not to overlap these definitions on the same entities for which security has been defined at DB Profile level. Moreover, unless there is a specific requirement the security should be simply defined at DB profile level.

After all these selections are applied the final “Visibility” layer is applied. We describe it in the following paragraphs.

3.2 Data Visibility

3.2.1 What is it and how does it interact with security?

The Data visibility layer is an additional level of data access control which can be defined in Board. It can be defined for each Role and, through the roles, is then applied to the users.

It allows to use one or several cubes to control the data visibility for end users. These cubes are checked in sequence with AND/OR kind of clauses and filtered with the selections active. Please refer to the manual for a practical guide on how to set it up.

Since it is “cube based”, the data visibility is always executed within the selection defined at DB/Role level and, then, it is affected by any further selection placed directly on the application level.

The result is that with this layer we can:

• define data access control on a matrixial level: the perimeter of work changes based on the application usage.
• manage default selections without extra developments on the application level.
• simplify filtering of data throughout the application.

See more about the benefits of this layer in the next paragraph.

3.2.2 Approach with “Security + @User” vs “Security + Cube visibility”:

Up until the introduction of “cube visibility” (i.e., version Summer 2022) and “select based on” in DB security (i.e., version Summer 2023), the only way to restrict data access in BOARD was to use the following features:

• Database security: this is the security defined directly on DB or Sub-hub level and it is a fixed selection applied across the entire application.
• Procedure selection and predefined navigation paths: this is the usage of “Go to” procedures which contain “Select based on” steps to restrict even further the security setup before landing on a certain screen; these processes are embedded into the navigation buttons and menu.

With this architecture, the “Database Security” defines the overall security perimeter, while the “Go to” procedures restrict and guide the navigation within that perimeter.

The main problems of this approach are the following:

• It complicates the developments and application: ad hoc procedures must be developed to navigate to every screen.
• It worsens the performance: instead of just opening a screen the user must run a series of selection steps which calculate all the time the desired selection.
• It is not enough detailed: since it is based on the “Select” step, it is not capable of intercepting “matrixial access” points; this means that it is difficult to guarantee access to only certain data combinations (i.e., I can see all the Product/Customer combinations in my select but I cannot restrict only to a number of specific combinations).
• It interferes with the Navigation and application UX setup: since a procedure must be executed, it is not sufficient to just navigate to a screen, but the screen must be opened with a certain sequence and always from a button so that the procedure can be executed.
• It requires that certain native Board features are deactivated (i.e., selection window, screen list, etc.) to avoid users going out of the “Select based on” perimeter; of course, the overall DB security still applies.

For all the above reasons, it is considered best practice to use the DB Security/Roles Layer in combination with Cube visibility instead.

With these 2 features, we can replace most of the procedure selections which are used in the previously described approach. Instead of restricting access through “select based on” steps in “Go-to” procedures we will centrally define “select based on” security and where also needed the visibility for each cube exposed to end users. In this way, we will achieve the following results:

• Navigation is simplified and only defined to improve usability.
• A lower number of procedures to develop and - for the users - to execute.
• Centralized definition which is much easier to manage in terms of maintenance.
• Flexibility: the definition of data visibility is now at the combination level, i.e., at the cube’s cell level.
• Immediacy: any change is immediately reflected in the application and can be even managed by the end-user without many navigation steps.

Note: Database security (fixed or select based on the cube) remains the best way to define security within the data model; the cube visibility feature is to guide data visibility within the DB security perimeter and does not replace the security.

3.2.3. Which entities should be included in the Visibility Layer?

Similarly, to the DB-Role security also for Visibility is quite important to define which entities are most suited to be part of the layer.

Of course, we could start defining these entities as the ones that have the opposite characteristics to the ones included in the security:

• Non-Mandatory: the entity defines a perimeter of access that is not necessary in all the screens of the application or part of the business process; for example, Scenario-Version, which is a restriction necessary only in certain parts of the application and not relevant in others.
• Matrixial: the perimeter of work changes in combination with other entities; for example, Role-Product Group, a user can see many product groups if he/she works under the role of Reviewer but can edit only one product group when he/she works under the role of Planner.

3.2.4 How to manage in-screen objects like dataviews, pager/selectors and procedures

When introducing the Visibility Layer is also fundamental to talk about how it affects the in-screen objects:

• Selection: as described in the previous paragraphs visibility is not the security; so, it does not affect the screen selection, it stays within the selection; this means that the visibility will simply filter all the objects in the screen containing cubes for which the visibility has been defined.
• Pager/Selectors: these are a representation in the screen of the selection itself and therefore they are not affected by the visibility setup; these objects will expose all the elements which are within the selection and visibility will act on the data itself by hiding what is outside the data access perimeter; the DB security and in particular the Metadata selections or the “select based on” are the features which can be used to restrict this objects to the only elements which the user should be allowed to see.
• Layout-based objects (data views, labels, graphs): the cubes for which it has been configured the visibility will be filtered accordingly; this means that all the objects using cubes, like labels/data views/graphs, will display only data within the visibility perimeter; the “show all“ option will show also the entity elements outside the visibility perimeter but of course not the related data; this is by design because the visibility is meant to filter data and not master data;
• Procedures: in general the procedures will start with the selection defined in the security or anyway the active selection on the screen, depending on the application configuration; the visibility will not affect automatically the dataflows while it will affect all procedure steps involving layouts (the “Select based on” or “Dynamic selects”) containing cubes for which the visibility has been set up (as explained on the Board user manual); this means that the developer should consider whether extra selections based on the visibility cube are required before executing a dataflow; for example, the “Scenario-Version” is defined through visibility and therefore not applied as a selection on the screen, if the screen contains a procedure which must work only on one specific scenario, the developer will need to place a “select based on “ step using the visibility cube to make sure only the desired Scenario-Version is processed.

Of course, the security (fixed or based on cube) is applied as usual and therefore affects the selection of the user for the entire session and all the objects/screens accessed.

Center of Excellence

Thanks @Andrea C. for the insights on this topic!

Neha Hasija

Hi Team,

1. Is there a preference to define “manual selections” and the “Custom selection scripts” ?Whether it should be in Database Security Profile or Role?
2. Also, By default can we enable the Inheritance check in the Folder Security to provide access to all capsules in that folder or new capsules that will be created?

Thanks & Regards,

Neha Hasija

Neha Hasija

Thanks team for the security enhancement on "Select based on cube". Would like to explore it more in the upcoming projects.

Tommaso Riva

Hi Neha,

to answer you questions in order:

1. My personal advice is to use the Database Security layer to provide manual and custom selection scripts, and instead use the Role to manage the Features and Folder Security layers.
2. It can't be by default, but to provide full visibility to all capsules, simply navigate to the root Capsule, select it and click the "add folder" button. This creates the folder "\", activating the inheritance option that allows access to any folder or capsule (existing or newly created). The same applies to any level of your capsule organization.

Regards,

Tommaso

Julien CARDON

Hello

About cube visibility : Does it have impact on screen loading performance ?

Let's consider that a screen is using 15 data cubes where I have set cube visibility condition.

⇒ It means that each time a user access a screen, BOARD in the background will execute query on the 15 data cubes but also query each time all the tech cubes setup the cube visbility ?

regards

julien

Leone Scaburri

https://community.board.com/discussion/comment/15255#Comment_15255

Hello @Julien CARDON,

the expected impact is minimal cause we expect cubes driving cube visibility are quite aggregated.

On the other side cube visibility helps to reduce number of cubes within a layout for locking purposes.