Security Models Wonderware Intouch

Security Models Wonderware InTouch

Explain InTouch security Establishing Security Wonderware intouch :-https://youtu.be/GB3p2DjusYI

Define security models  

This module provides an overview of three security models available to the InTouch developer.   

The focus is on the InTouch-based Security model.       

This module provides an overview of three security models available to the InTouch developer (the None option is self-explanatory). The focus is on the InTouch-based Security model.   

All InTouch security methods are configurable with application granularity, meaning that you can operate two applications with different security settings on the same computer.   All three security methods are compatible with Network Application Development (NAD) distribution of applications. InTouch- based security works with NAD as it did in pervious versions of InTouch. For more information on NAD, see Network Application Development in the InTouch Users Guide.   

The InTouch developer can select between three security models:   

ArchestrA Security: ArchestrA-based security for Industrial Application Server (IAS) is centralized regardless of whether NAD is used or not.  

IAS Securityrelated activities are configured externally in the Integrated Development Environment (IDE). For more information on the IDE, see the Wonderware ArchestrA Integrated Development Environment (IDE) Guide.   

After selecting ArchestrA authentication and authorization, the Change Password, LogOn, Configure Users and LogOff options on the Special…Security menu are unavailable.   The details for features available with the Industrial Application Server are covered in a separate course.   

InTouch Security: By applying security to your application, you can control specific functions that an operator is allowed to perform by linking those functions to internal tags. Audit trails can be created that tie the operator to all alarms/events that occur during the time he/she is logged on to the system.   

Security is based on the concept of the operator logging on to the application, typing his/her name and password. You must configure a user name, password, and access level for each operator.   

There is no association between Microsoft operating system security and InTouch security.

Operating System Security:
If the authentication mode is operating system-based, user names will be the Windows Domain Name/User name pairs. User names can be chosen from the list of users associated with a Windows Network Domain/Workgroup. Each user name has an assigned access level that determines the user’s authorization for a given activity.   

Since the operating system manages the passwords internally, InTouch will not store passwords. Operating system-based security uses the InTouch script function AddPermission to maintain a list of users and their corresponding access levels. This list, created after the execution of the AddPermission() call, is written to disk. The file containing the authentication details of users will not be copied to the NAD client machines.

The operating system security scheme allows InTouch to meet security requirements in regulated industries. These specifications are established by the Food and Drug Administration (FDA) in CFR 21 Part 11.   

InTouch Security

Securing an InTouch application means different things to different people: Application Developers may want to secure the operating system, audit operators’ actions, or secure the InTouch application itself. To accommodate the different needs, the InTouch security scheme includes various options for a variety of applications.   

In some cases the top security concern is to limit the operator’s access to other Windows applications or the operating system on the local node.   

Script functions are available to lock the use of keys like <ALT> or <TAB>. There are ways to configure WindowViewer (View) to always run it maximized or to hide its menu so that operators can’t close it.   

In other instances security can include auditing the operator’s actions (keeping track of what was done and when it was done). InTouch events and inactivity system tags can track these actions.   

In other cases security would mean restricting features of the application based on privileges set forth for the current user (like a User ID) or the group the user belongs to (like Roles). This functionality is accomplished by setting a visibility or disable link to the object with limited access (for example, a push button to open another window).   

InTouch retains the traditional InTouch security based on a binary file containing a list of users of the application with passwords and access levels. InTouch includes additional security script functions
 and system tags.     

InTouch Application Security   

Implementing security in an InTouch Application means that users must be created, and those users must be given a way to login to the application window.   

When a new application is created, the user name is set to None with an access level of 0 (which allows no access to security commands) by default. This level prevents access to the Configure Users command in both WindowMaker and WindowViewer.   

Therefore, you must configure a user name for the System Administrator with an access level equal to or greater than 9000 in order to access the security user list later.   

Once an operator logs on to the application, access to any protected function will be granted upon verification of the operator’s password and access level against the value specified for the internal security tagname linked to the function.   

For example, you can control access to a window, the visibility of an object, and so on by specifying that the logged on operator’s “Access Level” must be greater than 2000.  

Note: The operator can log on to the application by executing the Special / Security / Log on command in WindowViewer (if the Special menu is displayed) or by creating a custom log on window with touch-sensitive input objects linked to internal security tags.     

The commands used to establish security on an application are located under the Special / Security command in both WindowMaker and WindowViewer. The security commands are used to log on and off the application, change passwords and configure the list of valid user names, passwords and access levels.   

Security Features in InTouch   

Three major aspects of security must be considered when using InTouch:   Securing the Operating System   Auditing   Securing the Application     

Securing the Operating System Security Models

Many InTouch applications require an operator to constantly monitor processes running 24/7. In these cases it is often desirable to have InTouch as the only Windows application that operators have access to. The operating system task bar, system files, and other Windows applications (like Solitaire) are inaccessible if View is configured properly.

Operating system security is configured from the WindowViewer Properties – Windows Configuration tab (Special / Configure / WindowViewer).

InTouch includes the script function EnableDisableKeys() that enables/disables the ALT, TAB, or WIN keys in Runtime. Disabling these keys prohibits users from switching between windows applications or accessing the taskbar. This function, combined with WindowViewer settings to Always Maximize and hide the Menu bar and Windows control options, will effectively secure the operating system.   

Another common practice to hide/show the menu bar in View is to create a popup-style window with its X,Y coordinates set to 0,-38 with a height of 38 pixels and a width equal to the display resolution (e.g. 1024). This example uses the Microsoft Windows Server 2003 Operating System, with a screen resolution of 1024 x 768. Values will differ depending on the Operating System and resolution used. Values will be -48 and +48 if XP look and feel are applied.       

Auditing  

Keeping track of what the operators do doesn’t make an InTouch application more secure but it is an important aspect of security in InTouch.   

When users and groups (or roles) are created to be used in an InTouch application, audit trails can tie operators to all alarms/events that occur during the time that they are logged onto the system. Alarms and events are very similar in nature since both require that a condition has occurred and should be logged. The difference between the two is that events, unlike alarms, do not require an
acknowledgment.

The ActiveX Alarm Object contains links to OS/ArchestrA security tags. The Distributed Alarm Object does not.   

Securing the Application   InTouch provides a number of System tags and script functions that enable InTouch developers to configure security for the individual application.     

Note: Applying security to your application is optional. The default security setting for InTouch applicationis None.     

However, by applying security to your application, you can control specific functions that anoperator is allowed to perform by linking those functions to internal tagnames. Once a use is validated and logged on to the InTouch application, the $ Operator and $AccessLevel system tags contain information about the user and their access level.   

To log on to an InTouch application, users can click on Special / Security / Logon, call a script function to display a logon dialog box (standard), or log on via a custom logon window.     

Note: See the InTouch Reference Guide for a complete documentation on System Tags and script function$AccessLevel is the tag used to secure InTouch applications. It is the main system tag to modify what a user ($Operator) can and cannot do during Runtime. For example, to disable a pushbutton just set a “disable” or “visibility” type link to it with an expression like $AccessLevel < 9000.   

ouch Authentication Schemes

When users are authenticated against a binary file (password.bin) that contains information about users, passwords, and access levels, this is known as InTouch authentication. In addition to that mode, InTouch programmers can use operating system authentication, ArchestrA authentication, or no authentication at all.   

The commands used to establish security in an application are accessible by selecting Special / Security on the main WindowMaker menu. The security commands are used to log on and off the application, change passwords and to configure the list of valid user names, passwords and access levels.   

You can also link a User Input – Discrete button to the $ConfigureUsers tag to allow an authorized operator with an access level of equal to or greater than 9000 to display the Configure Users dialog box. The dialog box is used to edit the security user name list.

When the operator clicks the button, the value of the $ConfigureUsers tagname is set to 1 and the Configure Users dialog box appears. When the operator closes the dialog box, the system resets the value to 0 (This is a system discrete tag intended for write-operation only).   

If the Special menu will not be displayed in WindowViewer, you can create a custom logon window (see below) that the operator uses to log on to the application.   

You can also link a User Input – Discrete button to the $ ChangePassword tagname to show the Change Password dialog box and allow the operator to change his/her password. When the operator clicks the button, the value of the $ChangePassword tagname is set to 1 and the Change Password dialog box appears.   

When the operator closes the dialog box, the system resets the value to 0 (This is a system discrete tagname intended for write operation only.)   

The None and Administrator names are reserved. Only the password of the Administrator may be changed. Once you have configured user names for your application, you should change the Administrator name’s password since it will more than likely become known to most users of the system. The Administrator default access level (9999) is the highest and allows access to everything including the Configure Users menu command.         

Creating a Custom Security LogOn Window   

$OperatorDomainEntered, $OperatorEntered, and $PasswordEntered are the three tags to be used in case a custom logon dialog box is required. Create a popup-type window and set user touch links (user input string) to these tags. If the provided credentials are validated, $Operator, $AccessLevel, $OperatorName, $OperatorDomain will update accordingly.

Note: The $OperatorDomainEntered tag is for OS Security only.     

If the Special menu is not displayed in WindowViewer, a custom log on window can be created for the operator to log on to the application.   

Link the $OperatorEntered, $PasswordEntered and $OperatorDomainEntered system tagnames to user input objects or use them in a QuickScript to set the User Name, Password, and Domain Name. These are internal message type tagnames that are intended for write operation only.   

For example:   

Set the User Name string into ->$OperatorEntered Set the User Password string into ->$PasswordEntered The $OperatorDomainEntered is required only if the security mode is operating system-based. Also, if the security mode is operating system-based and the $OperatorDomainEntered value is null, it is treated as pointing to local machine.   

After an operator logs on to the application, access to any protected function will be granted upon verification of the operator’s password and access level against the value specified for the internal security tag will be linked to the function.   

Security-Related System Tags Security Models

Three internal security tags are used in buttons, in animation link expressions or QuickScripts, and so on. They are $Operator, $AccessLevel, and $OperatorName. These tags control whether or not the logged-on operator is allowed to perform specific functions.   

The following table lists all security-related system tags.

For example, to make an object become visible based on the logged on user’s access level, the following statement could be used in a Visibility animation link expression: $AccessLevel >= 2000   Or, a QuickScript can be bounded by an IF statement:   IF $Operator == “DayShift” THEN   Show “Control Panel Window”;   

{and other lines that only execute for the DayShift Operator} ENDIF;   You can also control an object’s touch functionality based on the value of an internal security tagname by using the Disable animation link. For example:  

If no one is logged on and the above expression is used, the object or button is secured from tampering.   

Configuring Security Levels   

Select Special / Security / Select Security Type / InTouch.

The first time you use security, you must logon as Name: Administrator and Password: wonderware.

Use Special / Security / Logon.   

Select Special / Security / Configure Users. The Configure Users dialog box appears:

User Name: Assign a name to the operator.   

Password: Enter a password (up to 32 characters).   

Access Level: Enter a value (lowest = 0 to highest = 9999).   

Click Add to add the user name to the security list.

To modify an existing user name, select the name.   

Enter your changes and then click Update to accept the changes.

To delete a user name, select it in the list and then click Delete.   Changing a LogOn Password   

Click Special / Security / Change Password.   

The Change Password dialog box appears
(asterisks appear when users and passwords are configured).  

Old Password: Enter the old password.   New Password: Enter the new password (up to 32 characters).   Verify Password: text field, enter the new password again.   Click OK. All information entered displays on the screen as asterisks.

Logging on to an Application

There are four topics pertinent to logging into InTouch’s security system.   Special / Security / Log On   QuickScript Function Post Logon Dialog (detailed in Appendix G, “Script Functions.”)   QuickScript Function Attempt Invisible Logon (detailed in Appendix G, “Script Functions.”)   SystemTags ($OperatorEntered, $PasswordEntered)   To Log On using the Special / Security / Log On method   Click Special / Security / Log On. The Log On dialog box appears:

Name: Enter your user name.  

Password: Enter your password.  

Click OK.     If the information is entered incorrectly or is invalid, a message box will appear indicating that log on failed. If log on is successful, the $AccessLevel tag will be set to its predefined value as configured in the security user list.        

Logging Off an Application

There are four topics pertinent to logging out of InTouch’s security system.   Special / Security / Log Off   Log Off   Automatic Log Off based on inactivity   QuickScript Function LogOff (detailed in Appendix G of this manual)   SystemTags ($OperatorEntered = “None”)

To Log Off using the Special/Security/Log Off method a. Click Special / Security / Log Off. When this command is executed, the User Name is reset to None with an Access Level of 0.   

You can configure the application to automatically log off the operator after a specified amount of time has elapsed with no activity by the operator.    

Automatic Log Off (Timeout Settings)

The warning and timeout settings can be used to configure your application to automatically log the operator off if there has been no activity for a specified period of time.   

a. Click Special / Configure / WindowViewer.  

Warning: Enter the number of seconds that can elapse with no operator activity (mouse clicks or keystrokes) before the system discrete tag $InactivityWarning is set to 1 (True).   

$InactivityWarning can be used in a Condition QuickScript to display a window warning the operator that he/she is about to be logged off the system.   

If the operator clicks the mouse, presses a key or performs an action using any other pointing device before the specified timeout elapses, $InactivityWarning and the timer are reset and the operator is not logged off.   

Timeout: Enter the number of seconds that can elapse with no operator activity (mouse clicks or keystrokes) before the system discrete tag $InactivityTimeout is set to 1 (True).   

When $InactivityTimeout is true, the system equates the logged on operator name to the reserved name “None” and sets the security tagname $AccessLevel to 0.     

You can use $InactivityTimeout in a Condition QuickScript to show a window telling the operator that he/she has been logged off the application.   

The Timeout feature can be used independently of the Warning feature. However, the Timeout value must be greater than the Warning value for proper use of both system tags.     

For example: Warning becomes true after 30 seconds of inactivity and Timeout becomes true after an additional 15 seconds (for a total of 45 seconds) of inactivity.

Also Read:-

• Delta Tutorials
• HMI Demo examples
• PLC Tutorials
• Rockwell Tutorials
• WinCC Siemens Tutorials
• Wonderware Intouch Tutorials