Permissions

Permissions determine which
users
 can perform which
actions
 on specific
resources
 in the system from which
computers
.
Allow and Deny permissions
Set two kinds of permissions on resources:
  • Allow
     permissions grant users permission to perform actions on resources from all computers or from only certain computers on a network. For example, in a
    FactoryTalk
     network directory, for a resource such as an area containing various servers, assign
    Allow
     permission to a
    Read
     action for a group of users named Designers from All Computers. This allows members of the Designers group to view the contents of the area from any computer on the network.
  • Deny
    permissions prevent users from performing actions on resources from all computers or from only certain computers on a network. In a
    FactoryTalk
     local directory, security permissions apply to only the local computer. In a network directory, for an area containing various servers, assign
    Deny
     permissions to a
    Write
     action for a group of users named Designers from All Computers to prevent members of the Designers group from modifying the contents of the area.
Remove all permissions from an object by clearing both
Allow
 and
Deny
. This allows the object to inherit permissions assigned at a higher level. For example, remove all permissions from an area located in an application, the area then inherits permissions from the application.
If no permissions are assigned to a resource at any level, Deny is implied.
Product policies
 do not inherit security settings. When specifying permissions for product policies, clearing both
Allow
 and
Deny
 does not allow the policy setting to inherit security. Instead, clearing both denies access to the product feature.
Inherited and explicit permissions
By default, resources inherit permissions automatically from their parent resources. For example, if assigning security to an area in an application, all of the items in the area inherit the security settings of the area, and the area inherits security settings from the application. The top of the hierarchy is the network directory or local directory.
Networks and devices that are referenced by logical names, rather than by network relative paths, inherit permissions differently than other resources.
Override inherited permissions two ways:
  • Set up explicit permissions
     for resources at a lower level of the hierarchy. For example, if an area inherits permissions from an application, override the inherited permissions by specifying permissions explicitly for the area.
    Explicit permissions are permissions assigned deliberately to the resource, for users, groups, or computers, and actions. Explicit permissions take precedence over inherited permissions.
  • Break the chain of inheritance
     at a level in the Network Directory or Local Directory tree. For example, stop an area from inheriting permissions from the application in which it is located by selecting
    Do not inherit permissions
     when setting up security for the area. When breaking the chain of inheritance, specify whether to remove all permissions from resources below the break (which then implies Deny permission), or whether to use the permissions that are inherited by the resource at the break as explicit permissions.
The principle of inheritance allows setting permissions at as high a level as is practical, and then introducing exceptions at lower levels where necessary. If permissions are not assigned at any level, Deny is implied. When the system evaluates the level of access provided to a user, computer, or group, Deny permissions are evaluated before Allow permissions, explicit permissions override inherited permissions, and where conflicting permissions exist, Deny takes precedence over Allow.
Categories of permissions for actions
The actions that users can perform on resources are grouped into categories. The Common category is common to all
FactoryTalk
 products. Create action groups to assign security permissions to all of the actions in the group in one step, rather than assigning permissions to each action separately.
Effective permissions
To find out what actions a user or group can perform on a resource, view the permissions in effect (effective permissions) for the resource. The effective permissions are shown in the
Effective Permissions
 tab of the
Security Settings
 for the resource.
Effective Permissions
 shows the permissions that are granted to the selected user, computer, or group. When calculating effective permissions, the system takes into account the permissions in effect from group membership, as well as any permissions inherited from the parent object.
If a check mark appears for an action, permission is allowed, whether explicitly or by inheritance. If a check mark does not appear, permission is denied, whether explicitly or by inheritance. If a category (for example, Common) shows a gray check mark, one or more – but not all – of the actions inside the category is allowed. Expand the category to see which permissions within it are allowed or denied.
Provide Feedback
Have questions or feedback about this documentation? Please submit your feedback here.
Normal