Page History

Security

Users

This section describe the settings related to Security module.

is the summary for SecurityUsers configuration. For detailed information, see the Security Users page.

Pre-defined Users

The following user names are configured by default:

• 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.

Note
title Guess access
If the User did not execute any Log On or Identification procedure, it will be recognized as the pre-defined Guest User, which is equivalent to an anonymous access.

The Guest user is the default user for anonymous logins and does not have a password assigned. It cannot be deleted or have a password added. When you log off as another user, the Guest user must be availableis activated. To restrict access to resources, you may modify the permissions for the Guest user.

Avoid creating other users with the same names or altering the row IDs of these built-in platform objects. The Administrator is the sole user capable of deleting, blocking users, and defining passwords for database interfaces.

Default properties

Main Configuration Properties

Permissions Groups

This is the summary for Security PermissionsGroups configuration. For detailed information, see the Security Permissions page.

Pre-defined Security

Permissions Groups

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

• Administrator
• Guest
• User
• Engineering
• Supervisor
• Maintenance
• Operator

Edit

Permissions (Designer Restrictions)

It is possible to allow/deny a user to edit different project tabs in the Engineering Environment. The available options are shown in the image below.

Run

Permissions (Runtime)

It is also possible to allow/disallow a user to perform different actions during Runtime.

Security Policies

This is the summary for Security Policies configuration. For detailed information, see the Security Policies page.

On Security → Policies, there are three main configuration columns that can be important for CFR 11 compliance.

• Identification

• Esign

• Session

Pre-defined Policies

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

• Default

• Enhanced

• Critical

Identification Properties

Contains several password configuration options, detailed below: properties

Anchor
EsignProperties EsignProperties

Esign Properties

When enabled, a password will be requested for Action Dynamics with eSign. The password remains valid for a specified timeout time (in minutes).Esign properties

Session Properties

User can be logged off according to a determined Inactivity Time (in minutes) and/or after a maximum session duration (in hours).Session properties

Advanced settings

Runtime Execution

Content about Security Runtime Execution

To apply a created session configuration to a User, go to Security → Users (Policies Column), and select the desired option.

RuntimeUsers

The combination of the RuntimeUsers and regular SecurityUsers table are called Solutions Users.

→ Learn more at Security RuntimeUsers.

The Monitoring Client Connections empowers you to track and manage active connections. This functionality enables efficient troubleshooting and resource allocation for your project's needs.

During the launch of an application, the Login process accepts all users defined in the Project Configuration. Additionally, it is possible to dynamically add Runtime Users during runtime execution, and they are stored in a default database located in Datasets → Dos → RuntimeUsers. Customization of the database used for user storage is also possible in the Module Datasets. Furthermore, users can be created or modified using the Security Namespace's available methods. 

To simplify user management, a platform Plugin is available in the Security Module that provides a template application for creating a Runtime Display. The UserManagement Plugin can be imported by selecting the appropriate Plugin in Project → Plugins. Once imported, the Plugin creates names, such as SecurityAccounts and ChangePass, that aid in user management.

The Security Namespace offers a wide range of methods that can be used to create or modify Runtime Users before starting runtime execution or during project execution. The documentation provides detailed information on the available features and methods, allowing users to enhance their application's functionality and flexibility during runtime. By utilizing the Security Module's capabilities, users can effectively manage Runtime Users, increasing the overall security and functionality of their applications.

In the following, you can find more details regarding the available RuntimeUser methods in the Security namespace:

Adding Runtime Users
@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)

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.

In this section...