Defining user groups and their rights
Preparation is half the battle. This certainly applies when it comes to authorizing system users. You must first have a clear idea of which user groups you need. Then you have to consider what rights the different user groups will get.
An example is discussed below, in which three different user groups are necessary. The rights of each of these user groups are discussed. Then these user groups with their rights are used as an example when entering the different windows.
The user groups
In the organization, different groups can be distinguished that have to work with the system. These include receptionists, the people of surveillance, the system administrators. Each of these groups has different tasks. The receptionists create cards for new employees and visitors, but are not allowed to have access to the system settings. The people of surveillance must be able to read/execute all overviews and alarms. After all, the system administrators must be able to go into everything.
Note: When installing the package, one system user has always been created. This is Root. This system user is not visibly connected to a particular user group, but does have all the rights throughout the package. There are certain changes and additions that you can only make when you're logged in as a system user Root. It is therefore not possible to remove or modify this system user. However, we recommend that you change the default password for Root as soon as possible.
The new password must be equipped with a minimum of 1 Capital, 1 digit and at least 6 characters long.
Only if you are logged in as ROOT is it possible to create user groups and define rights. As a Root it is also possible to change forgotten passwords.
When you've determined which user groups are needed, see what rights each user group gets. This can be determined superficially, but also in detail. It is possible in iProtect™ to determine per table and even per column (database) which action a user group can perform. This is called vertical database security.
If you choose to permissions per column and per table, please note that updates from iProtect™ may contain new tables and columns. After an update, always check for the rights granted per user group. There is a real chance that changes will be needed.
You can indicate which action the user group is allowed to perform. It concerns the following actions:
Create new records
Delete existing records
View content from existing records
Change content from existing records
For each action, you can determine whether it is Allowed or Not Allowed. This includes the rule that Not Allowed goes above Allowed. Furthermore, for certain tables, the Read action should always be allowed, otherwise the user interface will not be accessible. We therefore recommend that you at least put the Read for all tables on Allowed. You can always shield certain tables/columns from 'see' later. Because: Not Allowed goes above Allowed.
Creating user groups
Sign in as user Root.
- Go to the menu Installation | Authorization.
- Click the User Group option, and in the left frame, press the right mouse key.
- Fill in a description of the user group.
- Save the record.
- Defining rights per user group
It is possible to determine the permitted actions per column and per table. However, if you have determined this in detail, there is a good chance that you will be allowed to re-enter it at the next update of the package. We always choose to keep the rights structure fairly superficial and to further restrict the rights through the menu structure. Of course, due to the links between tables, this is not always possible.
Because Not Allowed is always above Allowed, we recommend always putting all tables and columns on Allowed first. Then, you can start by table and column to determine what is not allowed.
Data column authorization
- Press the plus for the user group you want
- Go to Data column authorization
In this window, you determine which actions are or are not allowed per column and table. If you don't select a column but do select a table, the actions apply to all columns in the table. If you don't select a table, no column, the actions apply to all tables throughout iProtect.
- We recommend that you provide yes to the rights of the database. The different tables/columns can still be closed.
- After saving the settings, return to the left frame.
- In the left frame, click Data column authorization, and then press the right mouse key.
- By selecting the Person table at Table and at Column HomeAddress, by placing the rights of reading and writing to No, one can avoid seeing or changing the data. In the same way, this can be done for the postcode, place of residence and the telephone number
- The personal data is protected from the user group. The reader groups are put on reading only.
- Now it is chosen to select only the Table and not the Column. This allows the entire field to be shielded.
- The result then looks like this: