Extensions for user databases
Requirement: TwinCAT 3 Build 4024.8 or higher The functions described below require at least TwinCAT 3 Build 4024.8. |
Directory for storing user databases User databases must be stored in the following directory in order to be used in the TwinCAT Engineering: C:\TwinCAT\3.1\CustomConfig\UserDBs |
Allow operating system access for authorized users only The content of the user database is protected against manipulation with a signature. The names of groups, object protection levels and users are not encrypted and could be read. Access to the IPC should be restricted to authorized users via the operating system. |
Introduction
From Build 4024.8 onwards, the TwinCAT Software Protection supports extension files for the user database, so-called "User DB Extensions".
- A user database can be extended with these "extensions".
- An extension is an additional XML file that is the same as the main user database in terms of structure, but can only be used together with the main user database. An extension is therefore not usable on its own without the main user database.
- An extension can contain only the definition of users, but not the definition of groups or Object Protection Levels.
- An extension does not have its own administrator. The signing administrator of the main user database is also the signing administrator of the associated extension.
- An existing extension file can be added or removed at file level. This does not require configuration in the associated main user database (i.e. administrator rights are not required).
- The extensions are placed in a subdirectory with the name of the main user database (below the directory that contains the main user database): C:\TwinCAT\3.1\CustomConfig\UserDBs\<UserDB name>.
- An extension is usually limited in time.
- A user database can have any number of extensions.
Application:
- The main user database stores static information (such as definitions of groups or Object Protection Levels).
- The extension stores time-limited information (users), such as for service purposes.
A user database can easily be replaced by another version (with the same name and user DB key) at file level. To make changes in the user database tamper-proof (protection against being replaced by an older version without the changes), a completely new user database (with a different User DB key) would have to be created and linked to the project again. However, this is often not feasible in practice. This can be solved easily and elegantly with extensions of the user database:
- The main user database (with static information such as definitions of groups or Object Protection Levels) is permanently linked to the project.
- The (time-limited) extension contains all the information (users) that could change over time.
Scenarios with different user groups / Object Protection Levels are simpler to realize with extensions. For example, in-house developers can be summarized in their own extension, which is simply not copied to the target system during delivery. This allows areas (or individual users) to be added or removed as needed without having to adapt the entire user database.
This also enables a significant simplification of the versioning of a user database.
Sample application from the service area
- The Main User DB contains only the most necessary information (signing and changing administrators, definition of OPLs and groups).
- The extension is created specifically for the service assignment and contains only the service employee as the user. The extension is time-limited for the period of the service assignment.
- The service employee brings the extension with him on the service notebook (or a USB stick).
Time limitation of a user database / extension A tamper-proof time limitation requires a tamper-proof time reference! |