You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 74 Next »

Introduction to the Security module

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

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.

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

Securing Project Settings

Content

Securing Runtime

Content


Configuring the Security module

Configuration Workflow

Security module configuration workflow
ActionWhere 
Edit UsersSecurity → Users
Set users permissionsSecurity → Permissions
Define security Policies Security → Policies
Manage RuntimeUsersSecurity → 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. See Users properties to explore the default properties in detail.

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.

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

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. See Permissions properties to explore the common properties in detail.

Pre-defined Security groups

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

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

Using Policies and e-sign

Defining Policies

The project Permissions are defined in the SecurityUsers table on Security → Policies. See Policies properties to explore the common properties in detail.

Pre-defined Policies

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

  • 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

For in-depth security runtime understanding, please explore the Security Runtime Execution.

Monitoring Clients Connections

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. Please refer to the Monitoring Client Connections for a comprehensive client connections understanding.

Customizing Login Procedures

The Custom Login Procedures 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

The User Management on Displays and Scripts enables you to regulate user access and interactions within displays and scripts, promoting a secure and efficient work environment. To acquire an in-depth understanding of user management on displays and scripts, please consult the Managing Users on Displays and Scripts.

Security Module Runtime Attributes

The Security namespace 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.UsernameThe property is the name of current logged user.
Client.CurrentUserReference 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

Troubleshooting and Common #Issues

The Security module may encounter some issues in its operation. Here are some common issues and their solutions:

#Issue

Solution

Best Practices and #Recommendations

To ensure the smooth operation of the Security module, follow these best practices:

#Best practice

Recommendation



In this section...


  • No labels