About the Security module
The Security module is crucial for any control system or industrial application. It provides robust security measures to prevent unauthorized access, data breaches, system downtime, and other security-related issues. The module offers tools such as user authentication and access control features that allow system administrators to manage user accounts, assign specific rules and permissions based on their responsibilities and job functions, and restrict access to sensitive data and critical actions on the system.
The Security module provides high granularity access control during the product configuration phase, allowing multiple users to work on the same project safely and coordinate teamwork. It also manages user authorization and access control when the project runs, ensuring only authorized accesses can modify the configuration.
Additionally, the Security module ensures that only identified logger client users can open Displays, execute allowed commands, read or write specific Tags, and perform predefined behaviors. This creates a secure and controlled environment, giving users peace of mind knowing their system is protected from security threats.
The Security module was created to implement technical requirements for critical infrastructures and regulated process automation, including FDA 21 CFR Part 11.
For more information, refer to FDA 21 CFR 11 Compliance.
On this page:
Key Concepts and Terminology
Users
Anyone accessing the project, either on the engineering or runtime mode, is a User.
Guess access
Permissions
The Permissions concept ensures that users access only the necessary functionalities and data for their job, reducing the risk of security breaches and unauthorized activities. The group-based Permissions allow configuring which functions users can access while editing or during the project runtime.
Policies
The Policies enable the management of the requirements on User Identification and Session control. For instance, you can setup a Policy for minimum of 8 letters passwords (Identification Policy) and an automated LogOff after 8 hours of usage (Session Policy). Then, you setup which Users will be required to follow that Policy.
Runtime Users
It is a very common Project requirement to dynamic add and remove Users. Instead of modifying the Project every time, the platform allows the concept of Runtime Users which are dynamically created and retried from an external encrypted SQL database, but other Identification server can be integrated.
The combination of the Runtime Users and the ones defined at the SecurityUsers table are called Project Users.
The main difference between the two is that engineering users can access the software's engineering mode, allowing them to design and configure the project. In contrast, runtime users only can use the application, they cannot change the project configuration or design since they don't have access to the engineering mode.
How the Security module works
Content
Security features highlights
Content
Protecting access to Project Configuration
Content
Allowing role security for Operators Interfaces
Content
Security integrations
Windows AD Integration
Instead of validating the Users again, the credentials in the Project configuration and the identification of the User connection can be automatically executed using our native Windows Active Directory integration. This functionality in only available for the Users connecting from Windows operating systems.
AD/LDAP Server Integration
When the integration with Windows AD is not available, it is still possible for an automated identification using the business server to define an LDAP server to be used by the project.
Configuring the Security module
Configuration Workflow
| Security module configuration workflow | ||
|---|---|---|
| Action | Where | Comments |
| Edit Users | Security → Users | |
| Set users permissions | Security → Permissions | |
| Define security Policies | Security → Policies | |
| Manage RuntimeUsers | Security → RuntimeUsers | |
Creating, editing and managing users
The Named Users with authorization to access the Project are defined in the SecurityUsers table on Security → Users.
To add or edit users
- Go to Security → Users.
- Enter or select information, as needed.
Pre-defined users
The following user names are configured by default:
Pre-built Users | |
|---|---|
Administrator | Built-in user that controls the Security System. No password is configured by default. You should set a password for this user. |
| Guest | Used by default to access and when you log off as another user. No password is configured by default. |
| User | Used as a generic login user. No password is configured by default. |
You can not delete the Guest user, neither add a password to it. The Guest user must be available as the default user when you log off as another user. You may want to change the Guest user permissions, so that Guest users do not have access to any resource.
Guest User is used for anonymous login and does not have password assigned to it.
Removing Users
You have three ways to disable users:
- Blocking: Use to block the user’s access. You may want to use this for users who are no longer in your company.
- Flagging as deleted: Use to block the user’s access and flag the user as deleted, without deleting the user. You may want to use this for users who are no longer in your company.
- Deleting: Removes the user completely from the system.
The method used varies according to the Security requirements on managing users for your application.
Defining Permissions and Policies
The project Permissions are defined in the SecurityUsers table on Security → Permissions.
To configure Permissions
- Go to Security → Permission
- Edit the fields in the table
The project Policies are defined in the SecurityUsers table on Security → Policies.
To configure Permissions
- Go to Security → Policies
- Edit the fields in the table
Connecting Users with Permission Groups
At the Security → Users table, the column Permissions can be updated to include all Permission Groups authorized to each user. Select multiple rows, right-click to edit the combined rows, when applying same settings to more than one user.
Runtime users
Content
Applying Security on Project Configuration
Content
Applying Security on Displays and User Interface
Content
Working with the Security module
Runtime Execution
Content
Customizing Login Procedures
Content
Security module integrations
Content
Managing users with scripts
Content
Advanced features and options
Dive deeper into the Security module's advanced features and options
Troubleshooting and best practices
By exploring the following sections, you will gain a deeper understanding of the Security module's capabilities and learn how to leverage its full potential to improve your industrial processes, increase efficiency, and drive sustainable growth.
Common issues and solutions
You'll be able to familiarize yourself with common problems that may arise when using the Security module and learn effective troubleshooting techniques to resolve these problems quickly and efficiently.
Diagnostics information about the Security module execution is located in the Security troubleshooting page.
Best practices and recommendations
Benefit from the knowledge of experts and experienced users by following our curated list of best practices and recommendations. These guidelines will help you ensure the successful implementation of the Security module and maximize its impact on your industrial operations.
Please take a look at Security's best practices and recommendations.
Security module runtime attributes
Content
NEW ORGANIZATION
About the Security Module
Key Concepts and Terminology
* Users
* Permissions
* Policies
* Runtime Users
How the Security Module Works
Features Highlights
Protecting Access to Project Configuration
Allowing Role Security for Operators Interfaces
Integrates with Active Directly, LDAP or other systems
FDA 21 CFR 11 Compliance
Configuring the Security Module
* Configuration Workflow
* Creating and Managing Users
** Pre-defined Users
** Runtime Users
* Defining Permissions and Policies
* Applying Security on Project Configuration
* Applying Security on Displays and User Interface
Working with the Report Module
* Runtime Execution
* Customizing Login Procedures
* Integration with Other Modules
Managing Users with Scripts
* Advanced Features and Options
Troubleshooting and Best Practices
* Common Issues and Solutions
* Best Practices and Recommendations
* Security Module Runtime Attributes
This page provides information about the Security module. Here you can learn about user authentication and access control features, including managing user accounts and assigning specific permissions to different users based on their responsibilities and job functions. Check how to ensure the protection and privacy of your system, prevent unauthorized access and data breaches, and maintain the highest security levels in your project. Consider this page an essential resource to help you extract the full potential of the Security module.
User Settings
The Named Users with authorization to access the Project are defined in the SecurityUsers table on Security → Users.
To add or edit users
- Go to Security → Users.
- Enter or select information, as needed.
Pre-defined Users
The following user names are configured by default:
Pre-built Users | |
|---|---|
Administrator | Built-in user that controls the Security System. No password is configured by default. You should set a password for this user. |
| Guest | Used by default to access and when you log off as another user. No password is configured by default. |
| User | Used as a generic login user. No password is configured by default. |
You can not delete the Guest user, neither add a password to it. The Guest user must be available as the default user when you log off as another user. You may want to change the Guest user permissions, so that Guest users do not have access to any resource.
Guest User is used for anonymous login and does not have password assigned to it.
Users Properties
Security Users properties | |
|---|---|
Field/Column | Description |
Name | Enter a user name. The system allows you to know if the name is not valid. |
Permissions | Select the permission group to be used by this user. See Configuring Permissions. |
Password | Enter a password for the user. The system allows you to know if the password is not valid. You can configure password requirements. See Configuring Policies. |
PasswordHint | Enter information that can help you remember the user’s password. |
Policy | Select the policy settings to use for this user. See Configuring Policies. |
Blocked | Select to block the user’s access. You may want to use this for users who are no longer in your company. |
Deleted | Select to block the user’s access and flag the user as deleted, without deleting the user. You may want to use this for users who are no longer in your company. |
Profile | Enter the user’s email address, phone number, and full name. |
Removing Users
You have three ways to disable users:
- Blocking: Use to block the user’s access. You may want to use this for users who are no longer in your company.
- Flagging as deleted: Use to block the user’s access and flag the user as deleted, without deleting the user. You may want to use this for users who are no longer in your company.
- Deleting: Removes the user completely from the system.
The method used varies according to the Security requirements on managing users for your application.
Permissions Settings
The project permissions are defined in the SecurityUsers table on Security → Permissions.
To configure Permissions
- Go to Security → Permission
- Edit the fields in the table
Security Permissions properties | |
|---|---|
Column | Description |
Name | Enter a name for the group. |
Edit | Select the modules users in the group can access when editing a project.
|
Run | Select the modules users in the group can access when using the runtime.
|
Description | Enter a description for the Permission group. |
Edit permissions
Edit Permissions properties | |
|---|---|
Property | Description |
Unrestricted | Select to allow all Edit Permissions |
EditTags | Select to allow tag editing. |
Historian | Allow edition in Historian module. |
Security | Select to allow for the Security module access. |
Alarms | Select to allow for the Alarms module access. |
Scripts | Select to allow for the Script module access. |
Datasets | Select to allow for the Datasets module access. |
Displays | Select to allow for the Displays module access. |
Reports | Select to allow for the Reports module access. |
Startup | Select to allow Startup. |
Publish | Select to allow Publish. |
Settings | Select to allow for the Settings access. |
Notes | Select to allow for the Notes access. |
CreateTags | Select to allow tag creating. |
Run permissions
Run Permissions properties | |
|---|---|
Property | Description |
Unrestricted | The user gets permission to do everything. |
Test | Once selected, the user can run a Test. |
Startup | Once selected, the user can run a Startup with all the modules. If not, the modules script, datasets, devices, and reports will not start. |
Shutdown | Once selected, the user is able to shutdown the application |
ClientStart | Once selected, the user is able to run all the modules in a startup. If not, the modules displays and devices will not start. |
ClientShutdown | Once selected, the user is able to shutdown the application as a client. |
StartTools | Once selected, the user can run the diagnostics tool, such as: property watch, trace window and module information. If it is not selected, the user is unable to start these tools. |
ToolsSetValues | Once selected, the user gets the read-only permission in the diagnostics tool, such as: property watch, trace window and module information. |
CreateUsers | Once selected, the user is able to create new user for the project. |
SwitchApplication | If it is not selected, the user can not switch application, the taskbar disappears. |
WebAccess | When the user has this permission, he can access the Web Client through the URL found in the Info → Redundancy → Web Client URL. If this option is not selected, the user cannot use the Web Client. |
Pre-defined Security groups
The platform comes with a few predefined Permission groups that you can use, or you can create your own.
Security groups | |
|---|---|
| User | The User group has access to the system and can view specific information, such as displays or tags, without the ability to make changes. |
| Guest | The Guest group has limited access to the system and can only view specific information, such as displays or tags, without the ability to make changes. |
| Engineering | This Security Group has high-level access to system configuration settings, such as tag configuration and project settings. They may also have permission to perform system modifications and create new projects. |
| Administrator | The Administrator group has full access to all functionalities and settings within the system, including creating and modifying users, security policies, and other system settings. |
| Supervisor | The Supervisor group has access to a broader range of system functionalities, such as the ability to create and modify displays, tags, and alarms. They may also have access to reports and other system settings required for their job function. |
| Maintenance | The Maintenance group can access maintenance functionalities, such as creating, modifying, and deleting tags, alarms, and trends. They may also have access to specific displays or other system settings required for their job function. |
| Operator | The Operator group can access specific functionalities like opening displays, executing commands, and viewing data. They may also have limited access to modify detailed settings required for their job function. |
Connecting Users with Permission Groups
At the Security → Users table, the column Permissions can be updated to include all Permission Groups authorized to each user. Select multiple rows, right-click to edit the combined rows, when applying same settings to more than one user.
Disabling Windows Applications Switch
When Task Switch is disabled, the following actions/keys will be inhibited for that User:
- Access to the Start button and the Task Toolbar
- Windows Logo button
- Ctrl + Alt + Del
- Ctrl + ESC
- Alt + Tab
- Alt + F4
- Windows Logo + L
Setup to use Application Switching disable feature
This configuration applies to RichClients and SmartClients. The file DisableTaskSwitchProtection.bat must be run from the installation directory in order to install the keyboard driver necessary to implement this feature.
Policies Settings
You can configure settings that you can apply to users.
The platform comes with a few predefined policies that you can use, or you can create your own.
To configure Policies
- Go to Security → Policies.
- Edit the fields in the table.
Security Policies properties | |
|---|---|
Column | Description |
Name | Enter a name for the policy. The system allows you to know if the name is not valid. |
Identification | Select the password rules for both editing a project and accessing the runtime.
|
Esign | For runtime only. Select to enable a timeout for the runtime login. Enter the timeout period in minutes.
|
Session | For runtime only. Use to enable a timeout for the runtime session. Select what will cause an automatic logoff, then enter the appropriate values for InactivityMinutes and DurationHours. This setting only logs the user off. The application continues to run.
|
Description | Enter a description for the policy. |
Identification properties
Security Identification properties | |
|---|---|
Property | Description |
AllowPasswordChange | Allows password changes. |
PasswordMinLength | Sets the minimum password length. |
BlockOnInvalidAttempts | Defines the maximum number of invalid attempts before blocking. |
AllowShareUser | |
UserNameMinLength | Sets the minimum length of the user name. |
PasswordHistory | |
MinPasswordAge | |
MaxPasswordAge | |
BlockAging | |
Esign properties
Security Esign properties | |
|---|---|
Property | Description |
Enableed | |
TimeoutMinutes | |
Session properties
Security Session properties | |
|---|---|
Property | Description |
AutoLogOff | |
InactivityMinutes | |
DurationHours | |
Applying Policies to Users
The policies you create are available to be used on SecurityUsers tables, at the column Policy
Runtime Users Security Management
When running the application, the Login procedure will accept all users defined in the Project Configuration, but additional users defined dynamicaly during the runtime execution can be included.
The Runtime Users are stored in the default database, defined on Datasets → Dos → RuntimeUsers. You can customize the databased used to that storage at the Module Datasets. You can populate that database directly before starting the runtime, or after the project is running, you can create or modify the users with the methods in the Security Namespace
To create a Runtime Display to mange the Users, there is platform Plugin with a template application.
Go to Project → Plugins and import the Plugin named UserManagement. It will create the names SecurityAccounts and ChangePass to assist in the User management.
Adding Runtime Users
Below you can find more details regarding the available RuntimeUser methods in the Security namespace.
@Security.NewRuntimeUser(string name, out int errorCode) // Creates a new RuntimeUser // name: User Name // errorCode: Error code (output) // Returns: String containing the error message (if error) or empty (if not error) @Security.AddRuntimeUser(string name, string permissionsStr, string password, string passwordHint, string policyStr, string profilePhone, string profileCompleteName, bool oneTimePassword) // Add Runtime User // name: User Name // permissions Str: Permissions // password: Password // passwordHint: Password hint // policyStr: Policy // profileEmail: Profile email // profilePhone: Profile phone // profileCompleteName: Profile complete name // oneTimePassword: flag (true or false) to set a One Time Password setting. If true, a password change is required after first login // Returns: String containing error message (if error) or empty (if not error)
Customizing Login Procedures
The Login page is editable. You just need to select the display with name LogOn to edit its layout. As you can see in the code behind of that display, it calls the method Security.Logon() to do the validation of the user. If you want to perform any other user validation, you just need to modify that logic calling your own validation system, and then calling the LogOn method, according to the results of your validation.
Another way to customize the logon is to put your own custom logic on the ClientStartup script task. The script is executed on any computer that is connected to the server application. You can perform verifications based on computer IP, computer name, Windows Active-Directory Logged user, or any other criteria to specify if the user is allowed to start the application and which should be their credentials. After that, you can either call client.Shutdown to terminate the application if it was an unauthorized access or Security.Logon() with a user that matches the selected security profile.
By default, when starting the application on a client computer, instead of requesting a login, we start the system with the user GUEST. The user Guest is equivalent to an anonymous login. If you do not want that on your application, just replace the startup page with a page requesting the Logon information.
The Security Namespace
The namespace Security has all the runtime information regarding the security system.
The Client object has information about the current user logged at that client station:
| Examples | |
|---|---|
Client.Username | The property is the name of current logged user. |
Client.CurrentUser | Reference to a data structure with all the information of the currently logged-in user. |
Programming reference on runtime objects
See Namespaces Reference for the complete list of properties and available methods.
In this section...