AFSecurity Class

This object is used to test and/or control the security access to the associated object. It can also be used to determine if the currently logged on user has read and/or write permission to the underlying database for the particular object. For example, a user may be attempting to add an AFElement to the server but may not have sufficient privileges to accomplish this. This object is designed to allow applications to check permissions before creating a series of interrelated objects, rather than trying each one and then trying to remove all the objects if one fails due to permissions.

Versions of the PISystem (PI AF Server) 2.7 or later support mapping Window user identities to an AFSecurityIdentity using the AFSecurityMapping object. This aligns the security model of the PI AF Server with that of the PIServer. Even though these new objects support the IAFSecurable interface, their permissions are defined by PISystem security and cannot be modified. The three built-in security identities Administrators, World, and Owner do not have Write or Delete permission because they cannot be modified. The Owner identity only supports allowing access permissions, it does not support denying any access permissions. The WriteData permission on an identity determines if security mappings can be added. All built-in identities have the WriteData permission except the Owner identity.

When adding a child AFElement, the child element will inherit the security of its parent element at the time of creation if it is added as a Strong or Composition reference. The security rights of an AFElement created at the database level will be calculated from the Element security item associated with the AFDatabase.

At the time of creation, the security access rights for an AFEventFrame that does not have a Strong reference parent are calculated from the AFElementTemplate if it was created from a template. If not created from a template, the security access rights are calculated from the EventFrame security item associated with the AFDatabase. The WriteData permission will control whether users can create, modify, or delete event frames. The ReadData permission will control whether users can read event frames. A child event frame will inherit the security of its parent event frame at the time of creation if it is added as a Strong reference.

For an AFTransfer, the security access rights are calculated from the AFElementTemplate if it was created from a template. If not created from a template, the security access rights are calculated from the Transfer security item associated with the AFDatabase. The WriteData permission will control whether users can create, modify, or delete transfers. The ReadData permission will control whether users can read transfers.

The security access rights for an AFCase are calculated from the AFAnalysis that owns the case. The WriteData permission will control whether users can create, modify, or delete cases. The ReadData permission will control whether users can read cases. The Execute permission will determine if a user can call the CollectElements, CollectInputs, CollectTransfers, Run, and Publish methods of the AFCase.

When an AFAnalysis is associated with an AFNotification, the security access rights for the two objects are synchronized. Similarly when an AFAnalysisTemplate is associated with an AFNotificationTemplate, the security access rights for the two objects are synchronized. This means that changing the security access rights of one object will also change the security access rights of the other associated object.

For all other types of objects, the initial security access rights are calculated from corresponding AFSecurityItem associated with the AFDatabase. For example, the database's NotificationRule security item is used to initialize the security access rights for an AFNotificationRule when it is created.

The following objects always have the Read permission regardless of their security settings: AFCategory, AFNotificationContactTemplate, AFNotificationTemplate, AFAnalysisTemplate, AFElementTemplate, AFEnumerationSet, AFReferenceType, and UOMDatabase. If the following objects have the ReadData, then they will also be granted the Read permission: AFElement, AFModel, AFNotification, AFEventFrame, AFTransfer, and AFCase. The PISystem requires that Read permission is configured in order to connect. However, the full list of PI Systems configured on a client machine is always available since determining the permissions requires an actual connection to be made. The PISystem also always has the Delete permission.

There are two security string formats supported by the SDK: Security Descriptor String Format defined by Microsoft, and the human-readable Security String Format. Each of these are described in the Security Formats topic.

AFSDK

Reference

Other Resources