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.

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.

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.

Explicit and Implicit Permissions

In general, Security References grant permissions to the object for which they have been created. These permissions are referred to as Explicit Permissions.

Implicit Permissions are granted to descendant objects when the Inheritable permission is granted to an object. 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. This behavior can be restricted by setting opposing Explicit Permissions for descendant ('Inheritable') or ancestor ('List') objects.

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 granted.

This subject is further illustrated by the example on the following page.