When a new user object is created in a ClearSCADA database it needs to be added to the Access Control List (ACL) where specific user permissions may be configured. Otherwise the user inherits permissions from the user group Everyone. In most applications, the user group Everyone has either very limited permissions or is excluded from the ACL completely for security reasons. This article provides details about the ACL(s) in ClearSCADA and steps to configure the ACL(s). Please use ClearSCADA Help for additional information.
Each object in a ClearSCADA database has its own ACL. The ACL settings from each object may be accessed by right clicking the object from the database tree and selecting Edit Security. By default, each object's ACL settings are inherited from the group the object resides in. Each group, in turn, inherits its ACL settings from the higher level group it resides in etc. Eventually, all objects inherit their ACL settings from the Root object. In this case the ACL setting may be configured on the Root object only and this configuration will propagate to other objects that inherit permissions from the Root object. When objects inherit permissions from their parents, the ACL settings on each object appear disabled to highlight the fact that the ACL settings need to be configured at the parent.
It is possible to break the chain of inheritance for a particular group or an object by deselecting the "Inherit Permissions From Parent" option from the group's or the object's ACL settings.
Once the user object is created, it needs to be added to the ACL of the Root object and to the ACLs of objects that do not inherit permissions from the Root. If the user is a part of user group(s), it is sufficient to make sure the user groups which the user a part of have been added and configured in the ACLs. There is no need to add the user directly to the ACLs if it is a part of user groups that have already been added and configured in the ACLs.
Each object in a ClearSCADA database has its own ACL. The ACL settings from each object may be accessed by right clicking the object from the database tree and selecting Edit Security. By default, each object's ACL settings are inherited from the group the object resides in. Each group, in turn, inherits its ACL settings from the higher level group it resides in etc. Eventually, all objects inherit their ACL settings from the Root object. In this case the ACL setting may be configured on the Root object only and this configuration will propagate to other objects that inherit permissions from the Root object. When objects inherit permissions from their parents, the ACL settings on each object appear disabled to highlight the fact that the ACL settings need to be configured at the parent.
It is possible to break the chain of inheritance for a particular group or an object by deselecting the "Inherit Permissions From Parent" option from the group's or the object's ACL settings.
Once the user object is created, it needs to be added to the ACL of the Root object and to the ACLs of objects that do not inherit permissions from the Root. If the user is a part of user group(s), it is sufficient to make sure the user groups which the user a part of have been added and configured in the ACLs. There is no need to add the user directly to the ACLs if it is a part of user groups that have already been added and configured in the ACLs.
Released for:Schneider Electric Canada
