ABB Ability™ History provides three authorization mechanisms for controlling what users are able to see and do. These are access control lists, Unix-style ownership, and flags. Access control lists are the preferred authorization mechanism as they are the most flexible. Unix-style ownership can be used for simple cases. Flags are the most performant mechanism, but their configuration is tedious.

In case multiple models are used simultaneously for defining the security of an object, the matching “Owner” or “Group” will be used first, then ACL, and finally the “Other” field. Rights granted by Flags are then ANDed with these permissions to get final access rights, so the user can never get permissions for an operation by just a set of flags.

This page contains conceptual documentation of authorization in ABB Ability™ History. For more practical examples, see the authorization how-to guides.

Protection levels

History controls access on three levels:

• Class (table)
• Property (column)
• Instance (row)

The class level controls access to all instances of a class. For example, if a user has read access to the Pump class, then they are able to see all the instances of the Pump class.

The property level controls access to a specific property of a class. TODO: putting Deny to property definition only hides the definition, not the property values

The instance level controls access to a specific instance of a class. For example, consider a user who has read access to the Pump class, but has been denied read access to a specific instance named Test pump 1. The user can't see Test pump 1 or read any of its properties. The user can, however, see all other pump instances.

Inheritance

When resolving security settings for an object, the system checks the following rules in the corresponding order:

1. If an instance has a Parent instance, it inherits the security settings from the parent instance.
2. If an instance does not have a Parent instance, it inherits the security settings from its class.
3. If a class has a Base class, it inherits the security settings from the base class.
4. If a class does not have Base class, it inherits the security settings from the Class class.
5. If the name of the class is Class, it does not inherit security settings.

Start of the checking depends on, e.g. for instances, the checking is started from rule 1. For classes, the checking is started from rule 3.

We can make a few observations from the above rules. For instances, the first place to check for inheritance is from their parent instances. This means that security settings propagate downward in the hierarchy. For example, consider our Example equipment model instance hierarchy:

Example site
├── Tank area
│   ├── Source tank
│   └── Target tank
├── Pipe
├── Flowback pipe
└── Pump section
    └── Pump

Tank area is the parent instance of both Source tank and Target tank. If we give a user write permission to Tank area, the user will also gain write permission to Source tank and Target tank due to rule 1.

The Class class is at the top of the inheritance hierarchy. All other classes inherit their security settings from Class and Class itself doesn't inherit its setting from anywhere. By default, everyone has read access to Class.

Instances and instance properties inherit their security settings from their respective class.

If an instance has a Parent instance, the security settings are inherited from the parent instance. This way, entire branches in a hierarchy can be controlled by editing only the settings on the branch instance.

If an instance doesn't have a Parent instance but has a Base class, the security settings are inherited from the base class. In other words, if the instance is not placed in a hierarchy, the class-based inheritance will be used to inherit the security settings.

Security definitions using flags are never inherited.

User and Group names

All user and group names must be defined in format DOMAIN\UserName. If the user is defined in the local machine syntax, \UserName can also be used, which will then be treated like %COMPUTERNAME%\UserName, where %COMPUTERNAME% is the name of the local computer. This syntax is especially useful in redundant systems where security definitions are done separately to each redundant node, instead of a domain controller.

Permissions

History supports the following permissions:

• Read
  -- If the user does not have read access to a certain object, he/she has no way of finding out the object's existence at all.
• Write
  -- Required to modify contents of a property or instance.
• Execute
  -- Special flag, required for all objects passed as parameters for a command class.
  -- Required for reading properties associated with the User Interface tree node.
• Create
  -- Required to be set for class or parent objects for creating new instances or committing a command class object.
• Delete
  -- Required for deleting an instance.
• Special

Example permissions required for operations

Access control lists

Access control lists (ACL) is the most flexible of the authorization mechanisms provided by History. On the other hand, it produces some overhead, which can in some cases turn into a performance issue.

ACL Security definitions are placed as instances of the UIAccessControlLists class and provide a Windows ACL -like security model, where any number of groups or users can be granted a different set of permissions, which are inherited from the parent object unless overridden. In addition to this, each ACL entry can contain a start and end time to limit the time that the definition is active for. This provides, for example, a way to grant a user or group access to certain history data in January 2012, but not at other times.

ACLs can protect equipment types, equipment instances, instance property values, and history values.

Owner-Group-Other

Owner/Group/Other security is defined in each class instance by one or more optional properties with special names:

• Owner - string containing the account or group using OwnerPermissions. If null, the Owner is inherited from the parent object.
• Group - string containing the account or group using GroupPermissions. If null, the Group is inherited from the parent object.
• OwnerPermissions - contains a permission mask to be used for any account or group matching the Owner field.
• GroupPermissions - contains a permission mask to be used for any account or group matching the Group field.
• OtherPermissions - contains a permission mask to be used for accounts and groups that do not match the Owner or Group fields.

Flags

If a class has an 8-64 bit integer property named “RequiredFlags”, the flag checking for instances of that class is activated. Whenever the user tries to access an instance, it is checked that he/she has all the flags specified by the “RequiredFlags” property for the corresponding operation. There are different sets of flags for all the operations, so the user can have a different set of flags for reading and writing, for example. The set of flags the users and groups have is defined by the UIPermissions class, which contains properties specifying the granted masks for each operation. If there are multiple matching instances in the UIPermission class, the flags granted by different instances are ORed together. The UIPermissions class also has a property “Negate” that can be used for specifying negative flags that are also ORed together, and finally removed from the user’s set of flags. This provides a way for denying some flag from a group or a user that otherwise would get the flag.