Security model for galaxies

Security settings in the IDE control access to:

• User and editor interfaces in the System Platform environment. The signed-in user remains authenticated across all editors and interfaces. The user does not have to sign in again when switching to a different editor, for example, when switching from the IDE to the Screen Profile Editor.

  Note: Regardless of the Galaxy security setting, a user must be a member of the aaConfigTools group to connect to a Galaxy from the IDE, or the user must launch the IDE using the "Run as administrator" option. Use the Windows Control Panel to add a user to the aaConfigTools group. Since aaConfigTools is an OS user group, you cannot use Galaxy Security Configuration to add a user to the group.

• Object attributes and the data they represent.

• Connection to the SQL Server database used for the Galaxy Repository.

  Note: For additional information about SQL Server security, see the section on SQL Server Rights Requirements in the System Platform Installation Guide.

• Credentials that allow a logged-in user in an AVEVA OMI ViewApp to access third-party resources used by the ViewApp.

Each Galaxy in the Galaxy Repository manages its own security model. The security schema managed in a Galaxy is a three-level configuration model to create and maintain the following:

• Users associated with specific roles

• User roles associated with specific system administration, configuration and run-time (operational) permissions, which map to security groups

• Security groups associated with specific objects in the Galaxy

The default Galaxy Security model includes:

• Two users: DefaultUser and Administrator, both with full access to everything.

  Important: Be sure to change the passwords for the Administrator and DefaultUser accounts after enabling galaxy security. We recommend that you use Microsoft Active Directory to implement your galaxy password policy because it is the easiest and most effective way to set the policy.

• One security group named Default.

• Two security roles: Default and Administrator, both with full privileges.

  Important: We recommend that you set the privileges for the Default role to the minimum level needed by all users.

The security matrix defines a cascading model of users associated with specific roles that are associated with specific security groups that are associated with specific objects. User run-time permissions can vary from object to object, action to action, and process to process. The security icons associated with object attributes map directly to control points in the security model.