Security Overview

Introduction
The security system in Application Server is a global function that applies to every
object in the Galaxy database. It is a relationship-based security system between
users and the objects and functions of the Galaxy.
The security system allows system administrators to easily define users and assign
the operations they can perform. Security permissions are defined in terms of the
operations users can perform using automation objects. It also supports multi-user
environments, in both development and runtime.

Authentication Modes
Security for the Galaxy is enabled in the System Platform IDE. When enabling Galaxy
security, the following authentication modes are available:
 Galaxy: Uses local Galaxy configuration to authenticate users. All security for
the Galaxy is specified and contained at the Galaxy level. When the user logs
on, security credentials are checked, and access to areas and activities is
granted at the Galaxy level.
 OS User based: Uses the user authentication system of the operating
system on an individual user level. All security for the Galaxy is specified and
contained in the operating system on a user-level basis. When the user logs
on, security credentials are checked, and access to areas and activities is
decided at the OS-user level.
 OS Group based: Uses the user authentication system of the operating
system on a group basis. All security for the Galaxy is specified and
contained in the user-to-roles mapping created in the operating system to
assign security. When a user logs on, security credentials are checked and
verified at the OS group level. OS groups are mapped to security roles in
the Galaxy to allow access to areas and activities in the Galaxy.
 Authentication providers: Uses the AVEVA Identity Manager (AIM) to
create a unified security management infrastructure across your local
System Platform nodes and Azure VMs by leveraging operating system
security and Azure Active Directory (AD). Refer to your System Platform
documentation for more information about the AVEVA Identity Manager
and configuring Azure AD as an identity provider.

Security Users
With OS User Based and OS Group Based authentication modes, operating system
users with local accounts are added as authorized users for the Galaxy. If OS Group
Based is selected, the local account must exist on each node in the Galaxy for
successful authentication of users on any computer in the Galaxy.

Two users are defined by default: Administrator and DefaultUser. These cannot be
deleted in an open security setting and both are associated with default roles.
Security Roles
You can create and manage user roles that apply to your organization’s processes
and work- based authorities. Two roles are defined by default: Administrator and
Default.
Roles are listed with an assigned Access level, which is an integer from 0 to 9999.
Access level can be used in graphic animations for security purposes, and to
configure navigation item security in a ViewApp.

General and Operational Permissions

You can specify General and Operational permissions for each role:
 General permissions relate to application configuration and administrative tasks.
 Operational permissions relate to security groups listed on the Security Groups page.
By default, the Administrator and Default roles have all permissions. All users belong to
the Default role and this relationship cannot be changed. Therefore, it is highly
recommended that you remove all permissions from the Default role.
General Permissions for Industrial Graphics Management
The list of General permissions includes the permission “Graphic Management
Permissions,” which is specific to industrial graphics.

Security Audit Trail

The Galaxy generates events for user actions, such as users logging in or logging off
an application, successful and failed attempts to write to an attribute, and others.
Event messages are logged to history blocks or the Alarms and Events database
through Historian Server and can be retrieved for future analysis and reporting.
 ViewApp Security

Introduction
A ViewApp has built-in security that is integrated with Galaxy security. Industrial
graphics can be shown or hidden during runtime in the ViewApp, based on current
logged in user information. For example, you can use the current logged in user
information as a condition to configure the visibility animation for a specific graphic
element. If the condition is true, the graphic will display at runtime.
During runtime, ViewApp navigation items can be shown or hidden based on the
access level assigned to, and/or user roles selected for, the navigation items. The
navigation item will be visible only to logged in users who satisfy each of these
conditions, if configured. Using access levels and user roles to control the display of
content in a ViewApp is an effective way of preventing access to a ViewApp's
sensitive controls from unauthorized users.

Before you implement security in a ViewApp, the following must be completed:

 Security must be enabled for the Galaxy with an authentication mode of
Galaxy, OS User Based, or OS Group Based. Additionally, roles and users
must be created and configured with the proper Operational permissions.
 Based on the authentication mode you select, ViewApp users must be
added to the security system with a user name and password. The user
should be associated with a role in the security authentication system with
a defined Access Level.

Major tasks for implementing security for ViewApps include the following:
 Implement login security within the ViewApp by using the security-related
method ShowLoginDialog(), for example, in an action script of a button.
Additionally, the TitleBarApp has an optional Login button, which the user
can use to login, switch users, and logout of the running ViewApp.
 Implement visibility or disable animations using security-related
attributes within the symbols that are going to be used as content of
the ViewApp. For example,
[Link] can be used.
 Configure the Access Level property for a navigation item in the
ViewApp, which determines whether the navigation item and its
referenced hierarchy are accessible in runtime.
Navigation Item Security Properties
Security properties can be configured to implement various types of navigation item
security. The Access Level property specifies the access levels associated with a
navigation item. The User Roles property specifies one or more user roles
associated with the navigation item. If both the Access Level and User Roles
properties are configured, both conditions must be satisfied for the navigation item to
be visible to the logged-in user at runtime.

Security Item Property

Security Security Item Visibility Requirements
Configurations
No security Access Level = Not Configured Navigation item always visible
User Roles = Not Configured
Access Level Only Access Level = Integer <N> Security must be configured in the Galaxy.
security in the range 0-9999
User must log in to the ViewApp.
User Roles = Not Configured
Logged-in user must have an access level
equal to or higher than the specified value
<N> of the Access Level property.
The logged-in user can belong to any role.
User Roles Only Access Level = Not Configured Security must be configured in the Galaxy.
security
User Roles = Role1,Role2,Role3 User must log in to the ViewApp.
Logged-in user can be assigned any access
level.
Logged in user must be a member of at
least one of the specified user roles.
Access Level and Access Level = Integer <N> Security must be configured in the Galaxy.
User Role security in the range 0-9999
User must log in to the ViewApp.
User Roles = Role1,Role2,Role3
Logged-in user must have an access level
equal to or higher than the specified value
<N> of the Access Level property.
Logged in user must be a member of at
least one of the specified user roles.

When a navigation item is selected in the ViewApp Editor, the Access Level and
User Roles properties are available in the Security category on the Properties tab.
They are set to “Not Configured” by default.
 To configure the Access Level property, click the down-arrow to the right of the
Access Level property and select an access level from the drop-down list. The list
includes access levels assigned to security roles in the Galaxy. Selecting an access
level from the list automatically selects access levels greater than or equal to the one
selected. The following example shows the result of selecting the 0 (Default) access
level.

Or, you can click the Access Level field, enter a numerical value, and press Enter. The
following example shows an Access Level value entered as 5000.
To configure the User Roles property, click the down-arrow to the right of the User
Roles property, and select one or more user roles. The following example shows two
user roles selected: Cloud\Application Administators and Cloud\Plant Operators 1.

Note that if a parent navigation item is not visible during runtime because the logged
in user does not meet the requirement based on the security settings for this
navigation item, then all child navigation items are also hidden from this user,
regardless how the security configurations of the child items are configured.

Security-Related Functions
A typical login interface includes a login button and a logout button. The login button
displays an interface to allow a user to enter their user name and password to gain
access to the ViewApp. The logout button logs the user off the ViewApp. Additionally,
information about the logged-in user can be displayed in the ViewApp at runtime.
The following Action Script functions can be used to show a login dialog box and to
log a user out of the ViewApp:

Function Description
ShowLoginDialog() Shows a login dialog box with fields to enter a user name and password.
LogOff() Logs a user off of a ViewApp.
Security Namespace and Security-Related System Attributes
Security-related system attributes operate in the [Link] namespace.
The names of the security attributes are specified with the prefix
[Link]. For example, you might use
[Link].attribute_name.

Note: The security-related attributes described below are predefined and available
only for Operations Management Interface ViewApps. They cannot be included in an
InTouch application.

The following security-related attributes can be used in Value Display animations

to display information about the user logged in to a running ViewApp:

Attribute Data Type Type Description

AutoLogOff Boolean Read/Write Returns True or False to indicate if a user
will be logged off after a period of inactivity.
When set to True, the user is logged off from
the ViewApp when the inactivity period is
exceeded. The default value is False.
AutoLogOffRemainingTime Integer Read Only Returns the remaining length of a user’s
inactivity period in seconds.
AutoLogOffTimeSpan Integer Read/Write Specifies the length of the inactivity period in
seconds a logged in user is allowed. The
default value is 600 seconds.
AutoLogOnCurrentUser Boolean Read/Write Returns True or False to indicate if users can
log on automatically to a ViewApp with their
Windows credentials. The default value is
True.
LoggedInAccessLevel Integer Read Only Access level of the security role assigned to
the user logged in to ViewApp.
LastSuccessfulLogin Date Time Read Only UTC time stamp of the most recent
successful log.
LoggedIn Boolean Read Only Returns True or False, indicating if a user is
currently logged into a ViewApp or not.
LoggedInUserName String Read Only User name specified by the user logged in to
a ViewApp.
LoggedInUserRoles String Read Only User roles assigned to the logged-in user, in
CSV format.

Single Sign-On Security for the ViewApp

If security is enabled in the Galaxy with an authentication mode of OS User Based or
OS Group Based, the current Windows user will log on automatically to the ViewApp
when the ViewApp starts.
 If the current Windows user is a valid user of the Galaxy, it will log on
the ViewApp successfully.
 If the current Windows user is not a valid user of the Galaxy, it will fail to log
on the ViewApp, which will leave the ViewApp running without a logged in
user. Other users can log on manually.
Note that the first time the Preview session is launched from the ViewApp Editor, the
current Windows user will automatically attempt to log on the Preview session.
The Single Sign-On feature can be enabled or disabled by setting the
AutoLogonCurrentUser attribute of the Security namespace to True or False.

Single Sign-On Security for OMI Apps

OMI Apps that use the Single Sign-On feature (SSO) will run in the context of the
logged on ViewApp user. Messages will appear if the current logged on ViewApp
user is not a valid user for the OMI Apps, or does not have enough permissions to
access the functions of the OMI Apps.
For example, the InSightApp is an OMI App that uses the single sign-on service of
the ViewApp. More information about the InSightApp is provided in Module 10.

Credential Management for ViewApps

Additional security credentials may be needed for some ViewApps to gain access to
third-party data and applications that do not support standard authentication
methods, such as Windows OS credentials, Active Directory, or OpenID Connect.
You can add these credentials on the Credentials tab in the Configure Security
dialog box.
Refer to the documentation that came with your product for details about managing credentials.
Lab – Implementing Security in a ViewApp

Introduction
Until now, your Galaxy has had security disabled and you have been able to perform
configuration and runtime actions without having to log into the System Platform IDE
or the ViewApp.

In this lab, you will enable security in the Galaxy to use operating system user groups
(OS Groups) as the authentication mode. You will configure permissions for a default
role, as well as for roles added from domain user groups. As part of the configuration
for the roles, you will assign access levels to the roles and configure operational
permissions.

User Group Name Access Level Operational Permissions User Name Full Name
Student Training Student
Application
9999 All operational permissions Jamess James Smith
Administrators
Maryl Mary Lee
Michaelj Michael Jones
Plant Supervisors 1 5000 Can Verify Writes
Karent Karen Turner
Johnj John Johnson
Plant Operators 1 2000 Can Modify “Operate” attributes
Lisay Lisa Young
Robertw Robert William
Plant Operators 2 2000 Can Modify “Operate” attributes
Nancyk Nancy King

In your ViewApp configuration, you will apply access levels and user roles for navigation items.
When testing your ViewApp, you will log into it as different users and see the
impact on the navigation items.

Objectives
Upon completion of this lab, you will be able to:
 Configure the Access Level property for navigation items
 Configure the User Roles property for navigation items
 Use TitleBarApp to login and logout
 Verify runtime security in a ViewApp
Enable and Configure Galaxy Security
First, you will enable Galaxy security with the OS Group based authentication mode.
You will configure permissions for the Default role, and add and configure additional
roles from domain user groups.
1. On both the Templates tab and the Graphics tab, ensure that all objects and
symbols are checked in.

Note: You cannot configure security if any objects or symbols are checked out.

2. On the Galaxy menu, select

Configure | Security. The Security
area appears.

3. On the Authentication Mode tab, select OS Group based, and configure the Login time as
5000ms.
4. On the Roles tab, in the Define security roles list, select the Default role.
5. In General permissions, uncheck all of the IDE Permissions and SMC
Permissions. You will need to scroll in the General permissions list to
see all of the permissions.
6. In Operational permissions, expand Default and keep Alarms and the permissions
beneath it checked, but uncheck all others.
You will need to scroll in the Operational permissions list to see all of the permissions

7. Click Add new Role to add a role from the domain user groups.
The Select groups dialog box appears.
8. On the right side of the Select from the list field, click the drop-down arrow and
select a domain.
The following example shows selecting CLOUD as the domain.

9. In Available OS groups, press and hold the Ctrl key, and select the following groups:
 <domain>\Application Administrators
 <domain>\Plant Operators 1
 <domain>\Plant Operators 2
 <domain>\Plant Supervisors 1
10. Click Add selected OS Group.
The selected groups appear in the Selected groups area.
11. Click OK to close the Select groups dialog box.
In the Security area, the new roles are added to the Define security roles list.
12. In the Define security roles list, select <domain>\Application
Administrators, and configure its Access level as 9999.
13. Ensure <domain>\Application Administrators is selected, and in General
permissions, check IDE Permissions and SMC Permissions.
This will grant all General permissions to the <domain>\Application Administrators role.
14. With <domain>\Application Administrators still selected, in Operational
permissions, check Default.
This will grant all Operational permissions to the <domain>\Application Administrators
role.
You can expand Default and Alarms to verify.
15. In the Define security roles list, select <domain>\Plant Operators 1, and configure its
Access level as 2000.
16. With <domain>\Plant Operators 1 still selected, in Operational permissions, expand
Default and check Can Modify “Operate” Attributes.
This will grant the permission to modify attributes with the Operate security classification.
17. Repeat Steps 15 - 16 to configure the <domain>\Plant Operators 2 role.
18. In the Define security roles list, select <domain>\Plant Supervisors 1, and configure its
Access Level as 5000.
19. In Operational permissions, expand Default and check Can Verify Writes.
This will grant the permission to provide an authentication signature for attributes with the
VerifiedWrite security classification.
20. Click Save to commit the configuration changes to
security. The Sign in to TrainingGalaxy dialog
box appears.
21. In the Sign in to TrainingGalaxy dialog box, enter the User name as
administrator, and then click Next.

22. In the Sign in to TrainingGalaxy dialog box, leave the Password field blank,
and click Sign in.

The System Platform IDE restarts.

In the following steps, you will verify that you are logged in to the System Platform
IDE as administrator.
23. In the System Platform IDE, click the profile icon to verify that the logged-in user is
administrator.
Notice that administrator is shown as the logged-in user.

24. Click the profile icon to close the logged-in user window.

Configure Security for Navigation Items

Now that security is enabled and roles are configured for the Galaxy, you will assign
access levels and user roles to navigation items in the ViewApp Editor.
25. On the Templates tab, in the Training \ ViewApps toolset, double-click $ViewApp_Training
to open it in the ViewApp Editor.
You can maximize the editor to optimize the view.
26. In the Navigation list, select Plant.
27. On the Properties tab, from the Security \ Access Level drop-down list, check 0 (Default).
Notice that when you check 0 (Default), the other access levels in the list
automatically become checked.
Selecting all the access levels for this navigation item ensures that Plant and its
navigation hierarchy will be available only when a configured user is logged into
the ViewApp.

You may need to click off the drop-down list to close it.
The Security \ Access Level property shows the selection as follows:
28. In the Navigation list, expand Plant \ Production, and select Line1.

29. On the Properties tab, from the Security \ User Roles drop-down list, check the
following roles:
 <domain>\Application Administrators
 <domain>\Plant Operators 1

You may need to click off the drop-down list to close it.
30. In the Navigation list, select Line2.

31. On the Properties tab, from the Security \ User Roles drop-down list, check the
following roles:
• <domain>\Application Administrators
• <domain>\Plant Operators 2
32. n the Navigation list, select Sys.
33. On the Properties tab, from the Security \ User Roles drop-down list, check
<domain>\Application Administrators.

34. Click Save to save the ViewApp template without closing the ViewApp Editor.
Test ViewApp Security in a Preview Session
Now you will test the security configured for the navigation items in the ViewApp. You
will log into the ViewApp as different users to see the impact on the navigation
items.
35. In the ViewApp Editor, click Preview.
Notice that the message for preview mode appears again, because you are
logged in as a different user (administrator).

36. Check Do not show this message again, and then click OK to dismiss
the message. The ViewApp preview session opens, navigated to Home.

Notice that the current Windows user is automatically logged into the ViewApp, if
the current Windows user is a member of any of the User Groups added as
roles in the Galaxy.

In this example, the current user is Cloud\Student, which is a member of the

Application Administrators group.
37. Open the left slide-in pane and expand Plant and Production Lines.
The current logged in user belongs to the Application Administrators group,
which grants access to all navigation items, including Line1, Line2, and
System.

38. Click the hamburger button to close the left slide-in pane.
39. On the title bar, click the name of the logged in user and
select Logout. In this example, Cloud\Student is the
name of the logged in user.

The logged in user is logged out of the ViewApp and no user is logged in.
40. Click the hamburger button to open the left slide-in pane and review the navigation tree.
Notice that with no user logged into the ViewApp, the entire Plant hierarchy is
missing from the list and cannot be accessed.
WebBrowser is available even when no user is logged in, because you did not
apply security settings to the WebBrowser node in the navigation.

41. Click the hamburger button to close the left slide-in pane.

42. On the title bar, click

Login. The Log In
dialog box appears.
43. Log in as <domain>\johnj and a password to log in. The following example uses cloud for the
domain
44. Open the left slide-in pane, expand Plant and Production Lines, and review
the navigation tree.

Notice that Line1 is listed under Production Lines, but Line2 is not. Also notice
that System is missing from the navigation list. This is because the current logged
in user is with the Plant Operators 1 user group, which does not have the access
to Line2 or System.

45. Click the hamburger button to close the left slide-in pane.
46. On the title bar, click the logged-in user name, and then select Switch User.
47. In the Log In dialog box, enter <domain>\karent and a password to log in.

48. Open the left slide-in pane and expand Plant.

Notice that Line1 and Line2 are not available under Production Lines. This is
because the current logged in user is with the Plant Supervisors 1 user group,
which does not have access to the child navigation items for Production Lines
or System.

49. Click the hamburger button to close the left slide-in pane.
50. On the title bar, click the logged-in user name, and then select Switch User.
51. Login as <domain>\nancyk.

52. Open the left slide-in pane and expand Plant and Production Lines.
The current logged in user is with the Plant Operators 2 user group, which has access to
Line 2. This user does have access to Line 1 or System
53. In the slide-in pane, select Line2.
The current logged in user has access to the content associated with this navigation node.

54. Click the hamburger button to close the left slide-in pane.
55. Switch users and log in as <domain>\jamess.
 Notice that the ViewApp remains navigated to Line2.
56. Open the left slide-in pane again.
Notice that Line1 and Line2 are both listed under Production Lines, as well as
System. This is because the current logged in user is with the Application
Administrators group, which has full access to the navigation in this ViewApp.

57. Click the hamburger button to close the left slide-in pane.
58. When you are finished testing, minimize the preview session and the ViewApp Editor