Security module introduction
The Security module plays a crucial role in ensuring the safety and integrity of your projects by managing user access, roles, and permissions. It allows administrators to control who can access, view, and modify project components, as well as manage runtime user interactions with displays and actions. This module also supports integration with external user authentication systems, such as Active Directory (AD) and LDAP, to streamline user management across your organization, and implements the technical requirements for for critical infrastructures and regulated process automation, including FDA 21 CFR Part 11.
In this chapter, we will explore the key concepts and terminologies related to the Security Module, its configuration process, and the application of security measures in your projects. By the end of this chapter, you will have a solid understanding of how to effectively manage users, roles, and permissions, and ensure a secure environment for your FactoryStudio projects.
On this page:
Purpose and Key Concepts
The Security module ensures robust protection and precise control over access to crucial system features and resources for proper management and operation. By implementing and managing security policies, permissions, and user information, organizations can safeguard their industrial automation environment, maintain confidentiality, and ensure compliance with security standards. Understanding the Security module is facilitated through key concepts such as Users, Permissions, Policies and Runtime Users.
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.
RuntimeUsers
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.
Understanding the Security module
Features highlights
Content
User roles management
Content
External Users Definitions
Content
Project Configuration protection
Content
Runtime protection
Content
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 | |
Users, Permissions and Policies
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:
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.
Do not create other Users with those names nor change the row ID of those users, as they are built-in platform objects.
The Administrator is the only user who can delete or block users and the only user who can define passwords for Database DB interfaces.
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
The project Permissions are defined in the SecurityUsers table on Security → Permissions.
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. |
Using Policies and e-sign
Defining Policies
The project Permissions are defined in the SecurityUsers table on Security → Policies.
Pre-defined Policies
The platform comes with a few predefined policies that you can use, or you can create your own.
Policies | |
|---|---|
| Default | |
| Enhanced | |
| Critical | |
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.
RuntimeUsers
Content
AD/LDAP 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.
For more information, see Windows AD / LDAP Server.
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.
For more information, Windows AD / LDAP Server.
Working with the Security module
Runtime Execution
Content
Monitoring Clients Connections
Content
Customizing Login Procedures
The Custom Login Procedures feature enables you to modify the login page, fine-tune user validation, and incorporate custom logic into the client startup process. This allows for a tailored login experience that suits your project's specific requirements. For a deeper understanding of how to customize login procedures and to examine detailed examples, please consult the Customizing Login Procedures.
Managing Users on Displays and Scripts
Content
Security module Attributes
The namespace Security has all the runtime information regarding the security system.
For general information on namespace and object concepts, go to the section Objects and Attributes.
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. |
See Namespaces Reference for the complete list of properties and available methods.
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.
In this section...
CONTEÚDO PARA USAR COMO BASE PARA A NOVA ORGANIZAÇÃO
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.
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
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.
Applying Policies to Users
The policies you create are available to be used on SecurityUsers tables, at the column Policy