Page History

Key Concepts

and Terms

The Security Module defines the Users allowed to use or modify solution, and their Roles, Permission, and Security Policies. The definition of users can be created locally using the platform tools or executed in connection with external definitions such as Active Directory, LDAP servers, or external SQL databases.

Users

Anyone accessing the projectsolution, 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

in engineering (Designer Tool) or in runtime mode (Displays).

Permissions

Permissions are set levels of access for each user that determine what they can or cannot do within the solution.

Policies

Policies manage requirements on User Identification and Session Control.

RuntimeUsers

These users are created and retrieved 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

Security features highlights

Protecting access to Project Configuration

Allowing role security for Operators Interfaces

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 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 Security module

Runtime Execution

Customizing Login Procedures

Security module integrations

Security in-depth

Managing users with scripts

Advanced features and options

Troubleshooting and best practices

Common issues and solutions

Best practices and recommendations

Security module runtime attributes

NEW ORGANIZATION

About the Security Module

Key Concepts and Terminology

How the Security Module Works

 Configuring the Security Module

        * Configuration Workflow

        * Creating and Managing Users

Working with the Report Module

        * Integration with Other Modules

Troubleshooting and Best Practices

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.

or other identification servers.

Understanding the Security Module

What the Security Module Enables

User roles management

Managing user roles involves assigning a role to each user that defines their level of access to various components of the solution. Each role has its permissions, which can be customized to meet the security requirements of your organization.

Managing External Users (Runtime Users)

External Users in this context refers to users who are not part of the organization but need access to specific components of the project. This can include contractors, clients, or third-party vendors. These users are typically managed via RuntimeUsers or integration with Active Directory and LDAP.

Securing Solution Configuration

The platform provides several tools to secure the solution configuration itself.  By assigning Permissions and Policies, administrators can control which users have access to specific modules, editors and documents. This ensures that only authorized users can make changes on each part the solution configuration.

Securing Runtime Execution

Securing runtime involves managing user sessions in client displays by setting password requirements, session restrictions, and e-signature settings. The platform allows administrators to monitor client connections and manage active sessions.

Users, Permissions and Policies Summary

For a summary of the Security Configuration, go to Security Overview, which presents the basic configuration steps and properties for Users, Permission and Policies. 

The next section presents the configuration of those elements in further details.

Configuring the Security Module

Configuration Workflow

Each User is assigned to a set of Permissions and a to a Session Policy.

RuntimeUsers

Runtime Users are either defined in an external database or created dynamically using the CreateUser method. They can log in and use remote operation displays similarly to users specified in the solution configuration.

→ Read more about RuntimeUsers.

AD/LDAP Integrations

Windows AD Integration

The platform can automatically execute user credentials validation and user connection identification using native Windows Active Directory integration, available for users connecting from Windows operating systems.

→ Read more about Windows AD / LDAP Server.

AD/LDAP Server Integration

When Windows AD integration is unavailable, automated identification can still be achieved using a business server-defined LDAP server.

→ Read more about Windows AD / LDAP Server.

Working with the Security Module

Customizing Login Procedures

Modify the login page, fine-tune user validation, and incorporate custom logic into the client startup ScriptTask process for a tailored login experience.

Further User management can also be execute on Scripts.

→ Read more on Scripts, Handling Security

Applying Security to Displays

Regulate user access and interactions within displays, either by protecting the entire display, or specific commands or elements within each display.

Display Edit or Run Security

The configuration table Displays / List, has the columns EditSecurity and RunSecurity that allow to define the PermissionGroups allowed to configure, or open in runtime, each displays. 

Security within the Display

When drawing the solution User Interface, there is a Dynamic Property specifically to apply security to any Input the operator may do at the display.

→ Read more on Drawing User Interfaces / Dynamics and UI Elements, the Security Dynamic configuration. 

Security Runtime Attributes

The Securitynamespace contains all runtime information regarding the security system.

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:

Pre-built Users

Administrator

Users Properties

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

Image Removed

Run permissions

Image Removed

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

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

Image Removed

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

Image Removed

Security Esign properties

Property

Description

Enableed

TimeoutMinutes

Session properties

Image Removed

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.

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

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 Clientobject has information about the current user logged at that client station

.

→ Read more about Objects and Namespaces.

Anchor
BestPractices BestPractices

Best Practices and Troubleshooting

Best Practices and Recommendations:

• Regularly update your user list and their associated permissions to maintain security.
• Conduct periodic audits of user accounts and permissions, making necessary updates and removing inactive users.
• Enforce strong password policies to enhance security.
• Require complex passwords that include uppercase and lowercase letters, numbers, and special characters. Encourage regular password changes.
• Keep your system up-to-date with patches and updates.
• Regular updates often include security enhancements and fixes. Ensure your system is up-to-date to benefit from these improvements.

Troubleshooting and Common Issues:

• User Cannot Log In: Ensure the user is entering correct login credentials. Check if the user's account is active and not blocked or flagged as deleted. If the problem persists, contact your system administrator.
• Permission Denied Error: Check the user's assigned Permissions. Ensure they have the necessary access rights to perform the desired action. Update their Permissions or assign them to a different user group if necessary.

In this section: