Introduction to System Security

The security configuration options provide a number of options for system administrators to control access to the system. This section will introduce some of the security concepts including the available authentication methods and the object classes used in the system.

Authentication Methods

Two authentication methods are supported:

  • Windows Authentication - This utilizes Windows user/Group accounts (either Windows Active directory or local Windows accounts) as authentication to either login to the system using DataStudio or to access the system using the Web API or Lua API. These are represented by the User and UserGroup objects created in the Access Model (see below).

  • Profile Credentials - This is an system authentication system that corresponds to inmation Profile objects created in the Access Model (see below). Can be used as authentication to either login to the system using DataStudio or to access the system using the Web API or Lua API.

Introduction to Security Objects

Security permissions are based on the following objects that can be created in the Access Model of DataStudio.

  • Profile: Profile objects are the highest level object in the Access Model and the objects to which security permissions are directly assigned. They specify how the system can be accessed and which parts of it are accessible. The Profile Credentials authentication method uses Profile objects for authentication.

  • User: User objects are created below Profile objects and thereby assigned to a particular profile (and therefore assigned the permissions of that profile). The User object represents a Windows Active Directory or local Windows user/group account for Windows authentication.

  • UserGroup: UserGroup objects are created below Profile objects and thereby assigned to a particular profile (and therefore assigned the permissions of that profile). The UserGroup object represents a Windows Active Directory group account for Windows authentication.

  • Script Profile: Script Profile objects specify how Lua Scripts running on system objects can access other system objects.

Permissions

Permissions are granted to any object in a model tree by using Profile objects from the Access Model. Different Profiles can be assigned to the same Windows Active Directory or local Windows user/group account by creating User objects for the same account underneath all the respective Profile objects (directly or indirectly underneath Group objects).

To assign a Profile to an object, a Security Reference is created by dragging & dropping a Profile object onto the specific object (e.g. an IO Item). In the following dialog the permissions for this object/Profile combination are specified.

Permissions that can be granted are:

  • List: Object will appear when listing the parent’s children.

  • Read: All object properties can be read.

  • Write: The current value of the object can be written.

  • Modify: All object properties can be written.

  • Execute: The object’s methods can be called.

  • Inheritable: The explicitly set permissions are inherited to all child objects.

When permissions are specified, all permissions which are NOT granted are effectively revoked.

If an object itself has a Security Reference granting permissions to the object, these permissions are referred to as Explicit Permissions. Permissions which are not specifically set for an object but inherited from an ancestor object (to which the Inheritable permission is granted) are called Implicit Permissions. Also, if the List permission is granted to an object, this permission is also implicitly granted to all its ancestor objects, up until the System object.

Explicit Permissions always overrule Implicit Permissions! For example, if the permission settings of an object explicitly prevents listing, the object itself as well as all its child objects can not be listed by all other users - no matter if one of the further descendants has the List permission or one of the ancestors has the List AND Inheritable permissions granted.

In this example, the parent object, Object A, has a Security Reference explicitly setting LRW––I permissions. Due to the Inheritable permission being granted, these permissions are passed on to its descendants - as shown in Object B, Object B1, Object E and Object E1. For these objects, these are implicit permissions.

Object C would also inherit the permissions from Object A but has a Security Reference on its own, setting –R–––I permissions explicitly. This Security Reference replaces all implicit permissions which otherwise would have been inherited from the parent object. Due to the Inheritable permission being granted, the new permissions for Object C are again passed on to its descendants, here Object C1.

Object D also has its own Security Reference. In this case, Read and Write permissions are explicitly granted, all other permissions being effectively revoked. Since the Inheritable permission is not granted, the descendants of Object D are cut off from any heritage provided by their ancestors.

Object E, being a descendant of Object A with no Security Reference on its own and no object in between affecting the permissions, inherits the permissions from Object A.

Permission Inheritance

Legend

Security References are exclusive! Once such a Reference is created for an object, only the referenced User (or Group) can access this object - according to the granted permissions. For other Users (Groups) to be able to access the same object, additional Security References need to be created on this object explicitly.