Example Security Configuration

In the following example, we will create Profile objects in the Access Model to demonstrate how different permissions can be granted to different Profile objects. Security references are then applied to objects in the models to grant the object level access for the profiles.

In order for the example to work correctly, you must ensure that your system has no previously created permissions or security references. Therefore we recommend starting this example on a fresh system (perhaps on a VM). We also recommend that you have added a Connector in the I/O Model and connected to a OPC Classic or OPC UA Datasource that has some I/O items.

Grant Permissions for a single Profile

This section will explain how to configure permissions to individual objects for a single Profile and the implicit upward inheritance of the permission to enlist children.

When creating new Access Model Profile objects, it is normally necessary to be logged in to DataStudio using an account with Administrator privileges such as the "so" system owner account.

Create a Profile "Group A"

A How to guide for creating Profile objects is also available in the DataStudio documentation here

Login to DataStudio using a administrator profile (default is "so") and open the Access Model. Right-click anywhere in the Access Model (apart from on an existing Profile) and select New Profile from the context menu.
In the Create Object wizard, first enter "Group A" as the name then open the General Authorization and Model Authorization property compounds and select the DataStudio and I/O Model checkboxes.

Figure 1. Create Profile Wizard - Common Properties
Click Next to go to the Profile Credentials page of the wizard and enter a password for the Profile (these credentials will be used to login into the system later using the Profile Credentials authentication method). Make sure that the Available checkbox is also selected.

Figure 2. Create Profile Wizard - Profile Credentials
Click Create to create the Profile in the Access Model.

Figure 3. Group A Profile in the Access Model
Open a new instance of DataStudio and login to the Core using the new "Group A" Profile name and Password (Remember to select Profile Credentials as the Authentication Method). Select a new workspace and then look at the I/O Model Panel and the other Model Panels. They should all be empty.

Figure 4. Empty Model Panels

Although the "Group A" Profile was created and authorization for the I/O Model was configured, no permissions were set to list/read any object in the I/O Model tree. To do this, we must create a Security Reference which is covered in the next section.

Create a Security Reference

Return to the DataStudio instance that is logged in as "so" (or another Administrator Profile) and open the Access and I/O Model side by side. Drag and drop the Profile “Group A” to an I/O Item below an OPC Datasource in the I/O Model tree (information on how to connect to and browse an OPC Datasource can be found here or here).

Figure 5. Drag and Drop Profile to I/O Item
The Set Permissions dialog will open. Select the List and Read checkboxes (see here for descriptions of all permissions).

Figure 6. Set Permissions - Group A
Click Apply to close the dialog and then look at the I/O Model. The I/O item to which the security reference was made will now have a lock icon by it.

Figure 7. [Object Security Reference set in I/O Model
Select the I/O Item and look at the Object Properties panel. The Security tab (the lock icon) is now available for selection and will display the Profiles with security references to the object and their respective permissions.

Figure 8. Security Tab - Profile references and permissions

Explicit and Implicit Permissions are shown together in the security tab. For profiles for which the permissions regarding the object have been explicitly granted, the checkboxes are 'clear' while they are 'greyed out' for implicitly granted permissions. The implicit permissions for the 'so' profile is shown because this is the administrator profile, which is currently in use.

For all hierarchical objects in the I/O Model which are on the branch from the root object ('System') to the object for which the permissions have been explicitly granted ('Int1'), the 'List' permission for "Group A" was granted implicitly. Here is an example:

Figure 9. Implicitly Set List Permission for Superior Level Objects
Login again to your second DataStudio instance using the "Group A" Profile Credentials and refresh and open the I/O Model. You should now be able to see the hierarchical path to the I/O Item that has the security reference.

Figure 10. I/O Model view - Group A Profile

The ancestor objects higher up in the tree hierarchy are visible due to the granted List permission being implicitly applied.
Select the I/O Item in the tree and look at the Object Properties Panel. The set Read permission allows the Group A Profile to see the properties of the I/O Item.

Figure 11. I/O Item Read Permission - Group A Profile
Select an object higher in the tree however and you will see that "Access is denied" when the Object Properties panel is viewed. This is because the Read permission only applies to the object to which the security reference was created and not other objects further up in the tree hierarchy.

Figure 12. Access Denied - Group A Profile

Grant Permissions for a 2nd Profile (Group B)

Return to the DataStudio instance that you are logged into as "so" or another administrator profile. Create a second Profile in the Access Model named "Group B" the same as described earlier for "Group A" (grant authorization for DataStudio and I/O Model). The Access Model should now contain both the profiles you created.

Figure 13. Access Model - Group A and B
Open a third DataStudio instance and login using the "Group B" Profile. You should see that the Model Panels are empty, as was the case for "Group B".

Figure 14. Empty Model Panels

Create a Security Reference for Group B

Return again to the DataStudio instance that you are logged into as "so" or another administrator profile.
This time, drag and drop the "Group B" Profile in the Access Model to an object that was on the same hierarchical path as the I/O Item used in the earlier steps but is higher up in the tree. For example the parent I/O Node.

Figure 15. Drag and Drop - Security Reference for Group B Profile
In the Set Preferences dialog, select the List, Read and Inheritable checkboxes.

Figure 16. Set Permissions - Group B
Click Apply to close the dialog and then look again at the I/O Model. The I/O Node and I/O Item both now have lock icons by them indicating that they both have security references to Profiles.

Figure 17. [Both Object Security References set in I/O Model
Return to the DataStudio instance that you are logged in to using "Group B" and refresh the I/O Model. The tree should show the hierarchical path to the I/O Node that has the "Group B" Profile security reference.

Figure 18. I/O Model view - Group B Profile
As with the "Group A" example, selecting objects higher in the tree will display "Access is denied" in the Object Properties panel. However, the descendent children objects of the I/O Node with the security reference to the "Group B" Profile.

The descendant children objects are visible to the Inheritable permission implicitly applying all permission downwards in the tree hierarchy.

Because the Read permission was also granted, the children of the I/O Node are also accessible for reading now for the "Group B" Profile due to the permission inheritance downwards in the tree hierarchy.

Figure 19. Read permission for children objects - Group B Profile

In the above picture one might have noticed that the I/O item which Group A has been given explicit permission for, is not visible for Group B, although or siblings are. This is explained in the next section Effective Permissions

Effective Permissions

The Effective Permission granted for a Profile is based on:

Explicit permissions (for example Read, Write, Modify or Execute permissions granted directly to an object)
Implicit permissions (through List and Inheritable permissions)

List permissions are implicitly granted to all hierarchical objects (e.g. folder objects) on the branch from the root object of the tree (the System object) to the object for which the List permission has been explicitly granted - unless this prevented by such an object which has an explicit set of permissions where the List permission is not enabled.
Inherited permissions are granted to all descendants - until inheritance is interrupted by an object which has an explicit set of permissions where the Inheritable permission is not enabled.

This section will explain how to make use of Effective Permissions and illustrate the behavior described in the box above.

Rules for Effective Permissions

The system determines the permissions for each object using the following rules:

ANY EXPLICITLY GRANTED PERMISSION RULES OUT ALL IMPLICITLY GRANTED PERMISSIONS.
EXPLICIT AND IMPLICIT PERMISSIONS ARE NOT MERGED IN ANY WAY.
PERMISSIONS ARE DETERMINED FROM TOP TO BOTTOM IN THE MODEL TREE.

This will be demonstrated using the "Group A" and "Group B" Profiles from the above example.

Open up two DataStudio instances, and login with "Group A" and "Group B". Expand the I/O Model and examine the tree hierarchy in each instance.

Figure 20. Effective Permissions for Group A and Group B Profiles

"Group B" is not able to see the I/O Item that "Group A" has explicit Read permissions for.
"Group A" can no longer see the I/O Item or the parent I/O Node, only the folder hierarchy above the parent I/O Node.

This can be explained via the rules stated above if we look at the permissions for each object granted through the applied security reference.

Open a new DataStudio instance and login using a Profile with administrator privileges. Expand the I/O Model and click on the I/O Item with the security reference from "Group A" profile and open the security tab in the Object Properties panel.

Figure 21. Explicit and Implicit Permissions for Group A Profile on I/O Item

This object has a set of explicitly granted permissions (Group A), so all permissions which have been implicitly granted, no longer apply to this object. Therefore, Group B cannot see the object in the model tree anymore.

Now click on the I/O Node with the security reference from "Group B" profile and open the security tab in the Object Properties panel.

Figure 22. Explicit Permissions for Group B Profile on I/O Node

Since "Group B" has explicitly granted permissions on a ancestor node, which are inherited by all its decendents, the "Group A" Profile does not have access anymore beyond this point in the tree hierarchy.

The Effective Permissions for the "Group A" and "Group B" Profiles as detailed above might not be as the administrator first intended, especially as the configuration of the "Group B" Profile permissions had a subsequent effect on the Effective Permissions for the "Group A" Profile.

Now that the rules are understood we will complete the configuration of permissions for the "Group A" and "Group B" Profiles to fix the permissions.

Completing Permissions - Group B Profile

We can complete the permissions for "Group B" so it can view all the children items of the originally selected I/O Node.

Use the DataStudio instance that is logged in with Administrator privileges and create a security reference for the "Group B" Profile by dragging and dropping it onto the same I/O Item that has a "Group A" security reference.
In the Set Permissions dialog, check the Read, List and Inheritable checkboxes and click Apply
The I/O Item object now shows two explicitly set Security References in the Security tab of the Object Properties panel.

Figure 23. Security References for I/O Item
Now go to the DataStudio instance logged into with the "Group B" profile and refresh the I/O Model. The missing I/O Item should now be visible.

Figure 24. Group B Profile - Completed Permissions

Completing Permissions - Group A Profile

We can complete the permissions for the "Group A" Profile so it can once again view and read the originally selected I/O Item.

Use the DataStudio instance that is logged in with Administrator privileges and create a security reference for the "Group A" Profile by dragging and dropping it onto the same I/O Node that has a "Group B" security reference.
In the Set Permissions dialog, check the List checkbox only and click Apply
The I/O Node object should now have two Security References visible in the Security tab of the Object Properties panel.

Figure 25. Security References for I/O Node
Now go to the DataStudio instance logged into with the "Group A" profile and refresh the I/O Model. The originally selected I/O Item should now be visible as well as the hierarchical path leading to it.

Figure 26. Group A Profile - Completed Permissions