• Security

• ArchestrA security is designed to prevent users from performing unauthorized activities. This includes users of:

• Other future ArchestrA utilities.

• View (or other GUI client applications) when performing runtime operations including monitoring, control and data entry functions.

• The System Management Console (SMC) when performing maintenance and system administration functions.

• The ArchestrA IDE when configuring and deploying objects.

• The ArchestrA Security Model

Security: General	→	[Does not exist in run-time
permissions		environment]
Security: Operational	→	Run-time permissions to
permissions		acknowledge alarms and
		modify attributes

• Security Groups are simply the grouping of objects that you want to behave in the same way with respect to security. Every AutomationObject belongs to exactly one Security Group. By default all new objects belong to the Default Security Group, which cannot be removed. Roles generalize Users function, such as Intake Operator or Dispatcher. Roles are granted permissions onto a number of Security Groups. If, for instance, a Role is granted Tuning access to a Security Group, then that role has write permissions to all object attributes with a security classification of Tuning (but none other). Roles are also granted utility functions-based permissions, such as Deploy or Can Edit.

• Authentication Mode 

• On the Authentication Mode page, choose the mode of Galaxy security:

• None: The default setting for new Galaxies, this mode is considered Open Security. It leaves all functions open to all users. No authentication is provided for any operations in the ArchestrA configuration or runtime environment. No login dialog boxes are displayed for operating Application Server utilities or runtime processes.

• When you switch to None from another Authentication Mode and click OK, the ArchestrA IDE is shut down.

• Galaxy: This mode uses local galaxy configuration to authenticate the user. Use this setting to create a user security system controlled by the Galaxy database.

• When Galaxy authentication is selected, each user must provide a user name and password in a login dialog box. The security system authenticates the user's credentials against Galaxy user data. Access to all operations in the ArchestrA IDE and anywhere in the ArchestrA environment are granted based on the logged in user's associated roles and permissions. The ArchestrA IDE customizes the user interface to the user's previous preferences (for instance, which Application Views are shown). The logged in user's name is shown in the status bar of the ArchestrA IDE.

• OS Group Based: This mode enables the Authorization for users based on which OS Groups they have been assigned to. Use this setting to take advantage of the operating system's user authentication system, on a group basis. 

• When OS Group Based authentication is selected, each user must provide a domain, user name and password in a login dialog box. The security system first ensures that the user is authorized to use the ArchestrA IDE. Then the system authorizes the user's credentials against operating system groups mapped to security roles in the Galaxy.

• OS User Based: This mode enables the Authorization of individual OS users. Use this setting to take advantage of the operating system's (NT) user authentication system, on an individual user basis.

• When OS User Based authentication is selected, each user must provide a domain, username and password in a login dialog box. The security system ensures that the OS user is authorized to use the ArchestrA IDE.

• Attribute Security Classifications

• Attribute SecurityClassifications classify Attributes of AutomationObjects (like the previously discussed Command attribute) from a security perspective. They are:
• FreeAccess – Any User can write to these attributes to perform safety or time critical tasks that could be hampered by an untimely logon request (for example halting a failing process). This does not require the user to have any privileges.
• Operate – Operators write to these attributes during normal day-to-day operations. These include Attributes such as Setpoint, Output and Control Mode for a PID Object, Command for a Discrete Device Object, etc. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write.
• Secured Write – Operators write to these attributes for normal interaction with a highly secured object forces re-authentication. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write. The AutomationObject will reject the write requested via the return status and the user must re-enter the login details.
• Verified Write – Operators write to these attributes for normal interaction with a very highly secured object. This is similar to Secured Write, however it also requires a second user authentication. The second user must also be assigned to the Security Group of this AutomationObject, to allow the write.
• Tune – Writing to these attributes is considered a tuning activity. Examples are attributes that adjust alarm setpoints, PID sensitivity, etc. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write.
• Configure – Writing to these attributes is considered a significant configuration change. For example, a PLC register that defines a Discrete Device input. This requires the user to be assigned to the Security Group of this AutomationObject, to allow the write. It also requires that the Object is currently OffScan.
• Read-Only – The attributes are never written to at runtime, regardless of the user's permissions.
• There are two other situations where an Attribute's Security Classifications are specified:
• When a User-Defined Attribute is configured.
• When an Engineer overrides the Attribute Security Classification within a Template editor.