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

To use a Windows Authentication to login to DataStudio,
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 a security references to the object and their respective permissions.

Figure 8. Security Tab - Profile references and permissions
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 9. 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 10. 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 11. 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 12. 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 13. 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 14. Drag and Drop - Security Reference for Group B Profile
In the Set Preferences dialog, select the List, Read and Inheritable checkboxes.

Figure 15. 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 16. [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 17. 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 18. 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 Inherit permissions)

This section will explain how to make use of Effective Permissions and what to watch out for when using them.

Rules for Effective Permissions

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

EXPLICITLY GRANTED PERMISSIONS OVERWRITE 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 19. Effective Permissions for Group A and Group B Profiles

"Group B" is not able to see the I/O Item than "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 20. Explicit Permissions for Group A Profile on I/O Item

The explicitly granted permissions of Group A on the single I/O Item object overwrite the implicitly granted ones and therefore, Group B cannot see the object in the model tree.

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 21. Explicit Permissions for Group B Profile on I/O Node

The explicitly granted Read permissions of "Group B" on the parent node overwrite the implicitly granted List rights of "Group A", therefore 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 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 should now have two Security References visible in the Security tab of the Object Properties panel.

Figure 22. 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 23. 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 24. 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 25. Group A Profile - Completed Permissions