Page History

Key Concepts and Terminology

Users

Anyone accessing the project, either on the engineering or runtime mode, is a User.

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.

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

Creating, editing and managing users

The Named Users with authorization to access the Project are defined in the SecurityUsers table on Security → Users.

Pre-defined users

The following user names are configured by default:

RemovingUsers

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.

The project Policies are defined in the SecurityUsers table on Security → Policies.

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.

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.

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.

Pre-defined Users

The following user names are configured by default:

Users Properties

RemovingUsers

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.

Edit permissions

Run permissions

Pre-defined Security groups

The platform comes with a few predefined Permission groups that you can use, or you can create your own.

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

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.

Identification properties

Esign properties

Session properties

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:

In this section...