1. Abstract
The security is crucial and critical part of the data model design. It should be considered during the design phase already.
In the following chapters clarifications and best practice approaches are described.
This document is not a replacement for the manual. It will give some impression/ideas. It is recommended to read about the different security settings in the manual before this document is read.
2. Common Understanding
2.1 Overview
The security in Board covers following objects:
- Database
- Entities
- Cubes
- Capsule Folders or Folder Profiles
- Users
- (Rules)
- (Procedures)
For screens, no native security is available.
2.2 Users
The first created user is the Administrator user with a password. This user has full access to all settings and should not be restricted at all. Further full-access users (like Administrator user) can be generated (depending on the number of licenses).
For technical tasks (like scheduled procedures) it is recommended to create a TECHNICAL User with USER license. This user should not have access to capsules, should not be able to access layouts and screen selections but can run system critical tasks (see Security Profile or Features (IDP)), e.g. backups. This user might be used in the scheduled tasks and therefore, it is a password user.
The passwords should have a very secure password and should be changed regularly. This applies to all password users.
For the other users it is highly recommended to use Single-Sign-On (SSO) authentication like Active Directory, Windows authentication, Office 365 and so on.
For the IDP it is possible to add more than one Identity Provider. Therefore, it is recommended for the Board employees to add Board’s identity provider. This will secure the access and reduces the need to have user/password user which are less secure. Especially Board employees usually have many permissions or even full access.
There are at least three roles, features, security profiles expected:
2.3 Security Settings
2.3.1 Data Model Security – Profile
The data model security is used to restrict the database access (capabilities, entities, cubes).
Figure 1: Data Model Security
See
https://help.board.com/v14/docs/the-database-security-section
for detailed information on the different settings.
It is not recommended to use the “Add Security Selection” feature as it sets fixed entity selections on entities which could become a problem when the internal IDs of the elements change. Instead, it is recommended to use “Select Entity based on Cube” feature for Entities in combination of a user entity and the selection script “Select User=@User ”. Also, the Security Selection of the same entity will be overwritten by the selection script of the same entity. The dynamic selection will be applied at the end and does not overrule restrictions made above. Multiple Select Entity based on Cube selections can be added for one Entity. The intersection of all cubes will be used for the final selection of an entity.
A good design for permission cubes is that the access is prevented when a cube is empty (e.g. somebody cleared and so …). This already applies for the entities. For the cube visibility the same logic should be applied but can be done differently (not recommended), i.e. for the grant cube access the “<> 0” option and for the deny data entry the “= 0” option should be used.
It is highly recommended to set permission cubes to read only for the users which are affected by them.
The locking condition is not compatible with the deep locker in the layout. Either the deep locker is used or the locking condition. As the deep locker requires the same dimensions or aggregated or less but no other dimensions, the usage of the deep locker is not recommended anymore.
There are cases where settings are not active immediately. In this case a data reader on an entity (no specific) with APPEND and REPLACE is sufficient to force the renewal of caches.
Recommended settings for profiles could look like this:
- Create the ADMIN profile.
- Name: ADMIN
- Access Mode: Data Model Administrator
- Security System: Builder
- Create USER profile.
- Name: User
- Access Mode: Read and Write (i.e. data entry is possible)
- Security System: Access Denied
- Custom Selection Script:
- Select User=@User
- Select Role=@var (User Metadata Field) [for IDP if used. Could be multiple lines]
- Select Entity Based On Cube: Select Entities and the cube which are setting the permissions for the user.
- Set Cube Visibility and Locking Conditions
2.3.2 IDP
2.3.2.1 IDP – User
Users are managed in the User overview.
Also, in Platform authorization the user can be assigned to different instances, roles and licenses.
Figure 2: Platform Assignment
2.3.2.2 IDP – User Metadata
The User Meta is useful to add some more information about the user OR to use this information in the security. In the case it is used for roles it is suggested to use a Dropdown list – to prevent typos.
Figure 3: User Metadata Creation
Also, such field can be used to insert a security selection script. This should not be required anymore. Instead, the Select Entity Based on Cube Security should be used.
2.3.2.3 System Administration – Role
Preferably, the Default data model security profile should be used instead of adding profiles manually.
This applies at least for the ADMIN and TECHNICAL users. If possible, this should be used for the standard user profiles also.
Figure 4: Role Settings - Overview
2.3.2.4 System Administration – Features
Depending on the application design it might be recommended to DENY the layout designer and the selection editor for the standard user. Allow execution of security critical procedures should be deactivated. With the access to the layout designer the User can change the layout and might be able to see values which should not be seen. By changing the selections on a screen, the user might be able to change it and create errors or even unintended data entries. Of course, most of the cases could be prevented by setting up the security properly.
Deny the layout designer and the selection editor can be set on each screen individually also. It is not recommended to use it (intensively) because it also applies to full-access users (like Administrator user). They usually rely on the access to the layout and the selection editor in test and error cases.
For the TECHNICAL user, all settings should be denied/disallowed. Only the Allow execution of security critical procedures must be allowed.
For the ADMIN nothing should be denied or disallowed.
Figure 5: Features Overview - Example
2.3.3 On-Premise
2.3.3.1 System Administration – User
It is possible to explicitly set the entity selections per user and data model. This is not recommended, as this sets fixed entity selections. The recommendation is “Select Entity Based on Cube” feature in the data model security instead.
Figure 6: User Settings
2.3.3.2 System Administration – Profiles
The Security profiles combine the settings of Role and Feature (see checkmarks) of the IDP instances. In addition, the license needs to be assigned. Therefore, the same recommendations as for the IDP apply:
2.3.3.2.1 Checkmarks
Depending on the application design it might be recommended to DENY the layout designer and the selection editor for the standard user. Allow execution of security critical procedures should be deactivated. With the access to the layout designer the User can change the layout and might be able to see values which should not be seen. By changing the selections on a screen, the user might be able to change it and create errors or even unintended data entries. Of course, most of the cases could be prevented by setting up the security properly.
Deny the layout designer and the selection editor can be set on each screen individually also. It is not recommended to use it (intensively) because it also applies to full-access user (like Administrator user). They usually rely on the access to the layout and the selection editor in test and error cases.
For the TECHNICAL user, all settings should be denied/disallowed. Only the Allow execution of security critical procedures must be allowed.
For the ADMIN nothing should be denied or disallowed.
2.3.3.2.2 Data Model
Preferably, the Default data model security profile should be used instead of adding profiles manually.
This applies at least for the ADMIN and TECHNICAL users. If possible, this should be used for the standard user profiles also.
2.3.4 System Administration – Folder Profile Security
The folder profile security is deactivated by default but provides a lot more possibilities than the default capsule security, i.e. full-access folder selection.
One or more folder security profiles can be assigned to a security profile (On Premise) or role (IDP). It is additive, i.e. if two profiles have different security settings for the same folder, then the highest permission wins.
See
https://help.board.com/docs/the-folder-security-section
for more information.
Following permissions are available:
- Play only: Cannot switch to Design mode.
- Read only: Can switch to Design mode but cannot save changes.
- Read & Write: Can create, delete and change capsules.
At least one profile is required:
- ADMIN
- Folder: Capsules (e.g. C:\Board\Capsules)
- Mode: Read & Write
- Apply to all Subfolders: Activated
For the further design it is recommended to create folder profiles depending on application roles (But usually different from the roles within an application).
Example:
- [Database 1] Planner: Has play access to the planning capsule for Database 1.
- [Database 1] Security Admin: Has play access to the security capsule for Database 1.
- [Database 1] Admin: Has play access to the administration capsule for Database 1.
- [Database 1] Developer: Has Read & Write access to all capsules for Database 1.
Figure 7: Folder Security Profile
2.4 Fixed Entity Selections
A fixed entity selection is when an element is selected from the e.g. the screen selection, block selection and so on. In this case Board stores the internal element ID (not the Code nor the description) which will be dependent on the loading order.
Risk
If the order changes because the order is not controlled specifically then users might get other permissions. This is a worst-case scenario in the security. Therefore, fixed entity selections are not recommended when the entity is not fully controlled, and the internal IDs always point to the same element.
3. Profile Duplication Driver
3.1 Introduction
The main goals of the security architecture are easy maintenance and good scalability (besides, it is working).
Easy maintenance can be achieved when profiles (= data model profiles, security profiles, security role, security features) can be used for multiple users and the profiles are not named like the users, e.g. the user driven profile creation should be prevented. Also, the creation of profiles depending on all possible mathematical combinations of data models and/or capsule should be prevented/reduced.
This topic becomes relevant when some databases exist and users have very individual access (Access, No Access, Entities, Cubes etc.).
3.2 Drivers for multiple profiles
What are drivers for multiple profiles (and which are not)?
Driver | Y/N | Description |
|---|
Entity | N | In the data model security, it is possible to define Select Entity Based On Cube restrictions for each entity. User entity is usually required. On-Premise: In the User administration a selection for each data model and user can be set. User entity is not required but it is a fixed entity selection. IDP: This selection setting is available on the Role and therefore not helpful to reduce the number of roles. Also, user metadata can be injected in the security script to set the restrictions (which might not be readable because of displaying only codes and its length) |
Cube Visibility | N | In the data model security is possible to define the use of other cubes’ values to drive the visibility/writing access. |
Cube Write Permissions | N | In the data model security is possible to define the use of other cubes’ values to drive the visibility/writing access. |
Database Access | Y/N | The database access is defined in the Security profile (On Premise) or Roles (IDP). In the data model section, a data model can be added by using a specific data model security profile. (Y) But also, a default data model security profile can be defined (N). When the second option is used a user might get access to a database which should not be accessed. How can this be restricted? IDP: Work with user metadata, e.g. roles (No Access, Admin, Controller, …) or Access attributes (Y, N) for each data model. These attributes are connected in the data model security selection script (Select Entity = @var (ACCESS_BUDGET). Important is that the No Access or the N are not within the entity. In this case the access to the database will fail. On-Premise: Such method does not exist. In the case the ~DBName is used, a wrong selection to a “Security Entity” was set in the selection script, e.g. entity contains only the element Y, and the script is written like this: Select Security-Entity = NO_ACCESS. In this case the user could not access the database until the ~DBName overrules the selection script by adding permissions to the Entity Members cube for the user’s slice. As the usage ~DBName is not recommended, the entity restrictions and cube visibility should be built in a way that a user cannot see relevant data and cannot start any critical processes. E.g. all security relevant dimensions are set by the “Select Entity based on Cube” feature. |
Capsules (Default Security) | Y | The capsule security is defined in the IDP: Roles On-Premise: Security Profile. Therefore, it is the main driver for the duplication of security profiles. |
Folder Security (Alternative) | Y (/N) | The folder security (Alternative for the capsule default security) is also assigned in the IDP: Roles On-Premise: Security Profile. Therefore, it is the main driver for the duplication of security profiles. (Y) But the ~Security allows to manage the assignment with the cube Assigned Folder Profiles. Then the duplication of profiles is prevented. (N) |
Screens | - | Cannot be managed individually by security |
License | Y/N | The license is set in the IDP: User management and therefore, it is not a driver. (N) On-Premise: Security Profile and therefore, it is a driver. (Y) |
Other settings | Y | Other settings like Deny Layout Designer, Deny Selection Editor, do not allow execution of security critical Procedures, … are also driving the duplication but are usually not relevant as they have the same settings for most of the profiles. |
3.3 Conclusion
It is recommended to prevent the profile duplication. Therefore, settings such as Default Data Model, the Select Entity Based On Cube and the cube visibility/write permission by cube should be used.
Only in heavy cases the ~Security needs to be considered for the Folder Profile Security.
4. Security Application
4.1 Overview
The settings “Select Entity based on Cube” for entities and the access and locking conditions for cubes by other cubes create many possibilities to manage the security in a Board application.
It is highly recommended to use these settings.
Maintaining the security with cubes, requires creating an application and a frontend for the administration. The administration should only be accessible for certain users. Therefore, a separate capsule might be required.
4.2 Requirements
- Define key users who can change the security for other users besides full-access users (like Administrator user). The key users are not allowed to extend their own permissions. This can be achieved by using a cube visibility cube on User x User [Security] (CLC_MAP User x User [Security Entry]). Also, all security data entry cubes should be secured by the cube visibility by a cube which contains the information which users are key users ([SEC] INP_Key User). This part is optional but should be considered when many users need to be managed.
- Set visibility access for entities. There might be several entities within one tree for which an input is required. All these permissions need be calculated to one level. E.g. for cost center hierarchy:
- Cost Center (Most required detailed level. Therefore, it is used for the Select Entity Based On Cube Entity Security in the data model security)
- Plant
- Legal Entity
- All Cost Centers
- Set writing access for entities. These settings will also be used to calculate the entity visibility.
- Set special permissions, e.g.
- is allowed to see sales only
- or only production
- or can control the workflow
- or is only able to submit a workflow
- or is allowed to upload data via smart import
- …
Example for the visibility settings for the organization tree and product tree:
Figure 8: Example Entity Permissions
In the next example is a configuration of the Select Entity based on Cube. The cost center is part of the organization tree. Due to the design of the dimensions there are 4 more hierarchies which use cost centers. The setting of the cost center is transformed to these 4 other hierarchies and is applied in the security. There is still just one setting in the frontend for the cost center hierarchy.
Figure 9: Example Select Entity based on Cube
4.3 Database
The security frontend can be built into the application database. In the case a consolidation of permissions is required, it could make sense to create a separate database (e.g. Application_Security) which collects all the permission input, calculates the permissions and extract it. The permissions are loaded by each application database at the end.
| Advantage | Disadvantage |
|---|
Built-In Security | - Entities are already available.
- Key Users are restricted already.
| - No consolidation view
- Multiple databases could lead to higher maintenance efforts
|
Central Security Database | - Scalable solution
- Single point of entry
- Simplified user security
- Easier to manage security across sandboxes
- No common @user restriction for security admins
- Stronger, role-based access control
| - Entities need to be collected from Application databases
|
There is no recommendation. It depends on the situation/customer/setup/future.
4.4 Roles and Users
Not every setting for a user is individually for a user. Usually, an aggregation like a role could be used to simplify the settings.
In the IDP the role could be added per data model via the user metadata and @var function in the selection script .
On-Premise this is usually done be adding an aggregation entity above the user entity.
An example:
The access to certain planning areas depends on the role. In addition, it is defined whether the role has read access only, writing access (when the versions are opened) or validation rights (data entry is always open & user controls the workflow):
Figure 10: Example Role Permissions
This setting is used for the calculation of the locking cubes. Even though there is just one input, it creates several locking cubes, depending on the role. The multiple locking cubes are required for the simplified setting of the cube visibility.
Figure 11: Data model security profile (IDP)
4.5 Key Users and their implications
Key Users are restricted by the same security they can change. As they are restricted in the User entity, another User entity is required for the permission setting.
Therefore, another user entity must be created, e.g. User [Security Entry]* which needs to be filled by the same processes which fill the User entity.
All the data entry cubes are dimensioned by this new entity. When the security is saved, a procedure is executed which always runs in full permission with every selection step activated “Run as administrator” option. In this procedure the User [Security Entry] is switched to the User.
*A replication is not proposed but it is expected to work.
After all calculations, the results are written to the physical permission cubes on User entity.
4.6 Visible/Writable Access
The visibility will be used for the “Select Entity Based on Cube” permission of the entities. For each tree (which requires security) the most required detailed level will be used.
The writable settings are also used to calculate the “Select Entity Based on Cube” permission but are also used to calculate specific permission cubes which will be added in every data entry cube in the locking condition.
4.7 Cube Visibility
The advantage of the cube visibility are the simplified layouts in the frontend. The data entry lock is maintained in the data model security model completely. Layout/Block locking is not required in most of the cases.
In the following example the access to the cube is connected to a role which is defined in the user metadata in the IDP. Therefore, only users of certain roles are allowed to see the cube content.
In the cell editing part two cubes are used:
- Workflow: This cube contains the dimensions role, year, plant, version. In other cases, this cube might be split in the security by adding one cube each for
- Open versions
- Open plants
- Open years
- Writing permissions to the Cost Center (per User)
Figure 12: Example Cube Visibility
Keep in mind: During the development, the settings need to be checked regularly and exported/imported to other servers. Therefore, it is required to keep a certain naming convention (e.g. prefixes, abbreviation) to maintain the cube visibility easily and finding gaps fast. Data model security is NOT a part of the data model transport. Also, the permission cubes should only contain the required dimensions as bigger cubes might slow down the performance.
4.8 Security Calculation
The calculation of the security should be triggered on the save of the security AND during the night run. It should be designed in a way that all dataflows run in the most efficient way (preferably JOIN and straight).
5. Source: User Entity
There are various sources to fill the user entity automatically.
5.1 IDP: Sync to Data Model
In the IDP a synchronization of user metadata can be added. These entities will be loaded automatically (see Board manual for full details). Advantage: the name is transferred, too.
Figure 13: Sync to Data Model (Board Manual)
5.2 On-Premise: UsersCreated_YYYYMM.log
The creation of new users depends on the UsersCreated log. This file contains all the user creations. With a data reader the users can be added to the Users entity. Preferably this should be scheduled before midnight, reading the log of the current month. Following custom path can be used in the data reader action in the procedure:
C:\Board\Dataset\Log\UsersCreated_@DateMonth .log
Also, the login log can be considered. Then only users will be added who tried to login.
The name of the user needs to be managed manually, or source is required to load the names automatically.
6. Special Cases
6.1 Multiple Role Concept
Most multiple role concepts can be implemented with the existing security, i.e. Cube visibility. But there might be cases where it is necessary to change the permission in the Select Entity Based on Cube Entity Security.
6.1.1 Customer Case
The screens are designed to show just one legal entity. The legal entity should not be part of selectors and the screen design. Therefore, the legal entity needs to be selected before.
In this case the security is updated instead.
To achieve this logic, a cube contains the possible permissions of all legal entities per user. Automatically, the first element is loaded to the security cube (Select Entity Based on Cube Entity Security).
A procedure with an interactive selection allows the user to select a different legal entity. After the selection this is applied to the security cube.
