Security References

In order to set the permissions for a profile, the object level security must also be configured. The profile can be assigned access permissions to any level in the Model panel and the assigned permissions can then extend to any item below this object level.

The object level security can be configured for an object in any model panel using the Object Lens panel.

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

In order for the example to work as described, it is important to ensure that the system has no previously created permissions or security references.

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 Profile objects in the Access Model, it is normally necessary to be logged in to WebStudio using an account with administrator privileges.

Create Profile

  1. Login to WebStudio using an administrator profile and open the System Config App.

  2. Then, open the Access Model in the Object Model panel.

  3. In the Access Model, create a Profile Group object. Right-click on the Node Delegate object and click Admin  New to open the Create Object dialog. Select Profile Group from the left-hand panel.

  4. In the Common property compound, set the Object Name and click Create to create the object.

    Security References - Profile Group: Access Model

  5. Right-click on the newly created Profile Group object and select Admin  New to open the Create Object dialog. Select Profile from the left-hand panel.

  6. In the Common property compound, set the Object Name as "Profile-A".

    For the General Access Rights property, select the checkbox for External API and for the Model Access Rights property, select the I/O Model checkbox.

    Security References - Create Profile-A: Name and Access Rights

  7. In the Profile Credentials property compound, ensure that the Available checkbox is enabled to allow the newly created Profile to be used to login Assign a Password to the profile.

    Security References - Create Profile-A: Profile Credentials

  8. Click Create to create the Profile object in the Access Model.

    Security References - Create Profile-A: Profile-A in Access Model

  9. Open a new instance of WebStudio and login using the new "Profile-A".

  10. In the Config App, look at each of the models in the Object Model panel. They should all be empty.

Security References - Profile-A: Empty Model Panels

Although the "Profile-A" profile was created and access to the I/O Model was configured, no permissions were set to list/read any object in the I/O Model panel.

Changes made to the Profile Access Rights will not be automatically applied if there is an active connection to WebStudio for the corresponding Profile. To apply these changes, a new connection must be established.

Set Security Reference

  1. Return to the WebStudio instance that is logged in using an administrator profile and open the I/O Model in the Object Model panel.

  2. Expand the IO-Home tree node, then select any object in the Process Data folder and open the Object Lens panel.

    Profile-A: Object in I/O Model

  3. Now, open the Access Model and drag the "Profile-A" object to the References property compound in the Object Lens. This property compound will be highlighted indicating that the object can be dropped there.

    Profile-A: Drag-Drop Profile to I/O Item in Object Lens

  4. This will open the Security References table, which contains an entry for the "Profile-A" object.

  5. For this entry, ensure that only the List and Read checkboxes are enabled. Select/deselect the checkboxes as required.

    Profile-A: Set Permissions in Security References Table

  6. Click Apply to apply the changes then click Ok to close the dialog.

  7. Look at the I/O Model. The object that the security reference was added should now have a lock icon by it.

    Security References - Profile A: Object with Permissions Lock

  8. In a separate browser window, login to WebStudio using the "Profile-A" profile credentials and refresh the I/O Model panel. You should now be able to see the hierarchical path to the item that has the security reference.

    Security References - Profile-A: I/O Model Panel
    The ancestor objects higher up in the tree hierarchy are visible due to the granted List permission being implicitly applied.

  9. Select an object higher in the tree however and you will see no details about this object in the Object Lens. This is because the Read permission only applies to the object to which the security reference was created and not other objects further up the tree hierarchy.

Grant Permissions for another Profile

  1. Connect to WebStudio using an administrator profile.

  2. In the Access Model, create a second Profile under the Profile Group created earlier. Right-click on the Profile Group and select the to open the Create Object dialog. Select Profile from the left-hand panel.

  3. In the Common property compound, set the Object Name as "Profile-B".

    For the General Access Rights property, select the checkbox for External API and for the Model Access Rights property, select the I/O Model checkbox.

    Security References - Create Profile-B: Name and Access Rights

  4. In the Profile Credentials property compound, ensure that the Available checkbox is enabled to allow the created Profile to be used to login. Assign a Password to the profile.

    Security References - Create Profile-B: Profile Credentials

  5. Click Create.

  6. In the Object Lens panel, both profiles should now be visible in the Access Model.

    Security References - Profile-B in Access Model

  7. Open a third WebStudio instance and login using the "Profile-B" profile credentials. Again, you should see that the Model panels in the Config App are empty, as was the case for "Profile-A".

    Security References - Profile-B: Empty Model Panels
Changes made to the Profile Access Rights will not be automatically applied if there is an active connection to WebStudio for the corresponding Profile. To apply these changes, a new connection must be established.

Set Security References for Second Profile

  1. Return to the WebStudio instance that you are logged into using an administrator profile.

  2. This time, select an object in the same hierarchical path as the item used earlier but is higher up in the tree. For example, the parent Folder object.

  3. Select the Access Model and then drag the "Profile-B" object to the References property compound in the Object Lens. This property compound will be highlighted indicating that the object can be dropped there.

    Security References - Profile-B: Drag-Drop Profile to Folder in Object Lens

  4. This will open the Security References table containing an entry for the "Profile-B" object.

  5. For this Profile, ensure that the List, Read and Inheritable checkboxes are enabled. Select/deselect the checkboxes as required.

    Security References - Profile-B: Set Permissions in Security References Table

  6. Click Apply to close the table and apply the changes.

  7. In the I/O Model, the "Process Data" folder and the "DC4711" I/O Item both now have lock icons by them indicating that they both have security references to Profiles.

    Security References - Profile-B: Object with Permissions Lock

  8. Return to the WebStudio instance where you logged using the "Profile-B" profile credentials and refresh the I/O Model. The tree should show the hierarchical path to the Folder object that has the "Profile-B" security reference.

    Security References - Profile-B: I/O Model

  9. As with the "Profile-A" example, when selecting objects higher in the tree, no details about the selected object will be shown in the Object Lens panel. However, the descendant children objects of the Folder object with the security reference to the "Profile-B" object are visible.

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

    As the Read permission was also granted, the children of the Folder are also accessible for reading now for "Profile-B" due to the permission inheritance downwards in the tree hierarchy.

In the last image, you may have noticed that the object which "Profile-A" has been given explicit permissions for, is not visible for "Profile-B", although its siblings are. This is explained in the next section on Effective Permissions.

Effective Permissions

The Effective Permission granted for a Profile is based on:

Rules for Effective Permissions

  • Any explicitly granted permission will override all implicitly granted permissions

  • Explicit and implicit permissions are not merged in any way

  • Normal implicit permissions will override ancestral implicit permissions.

  • Permissons are determined from top to bottom in the model tree.

This will be demonstrated using the "Profile-A" and "Profile-B" profiles from the above examples.

Open two WebStudio instances, and login with "Profile-A" for one instance and "Profile-B" for the other instance. Open the Config App in both instances, then expand the I/O Model and examine the tree hierarchy in each instance.

Security References - I/O Model for Both Profiles

  • "Profile-B" is not able to see the object that "Profile-A" has explicit Read permissions for.

  • "Profile-A" can no longer see the object or parent node, only the folder hierarchy above the parent 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.

  1. Open a new WebStudio instance and login using a Profile with administrator privileges. In the Config App, expand the I/O Model in the Object Model panel.

  2. Select the object with the security reference from "Profile-A" and open the Security Reference table in the References property compound.

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

  3. Click on the object with the security reference from "Profile-B" and open the Security References table in the References property compound.

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

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

Now that the rules are understood, we will complete the configuration of permissions for the "Profile-A" and "Profile-B" profiles.

Completing Permissions - Profile-B

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

  1. Using the WebStudio instance that is logged in with administrator privileges, we will create a security reference for the "Profile-B" profile.

  2. Select the object where the "Profile-A" profile has a security reference.

  3. In the Object Model panel, switch to the Access Model and drag the "Profile-B" object to the References property compound in the Object Lens for the selected object. This property compound will be highlighted indicating that the object can be dropped there.

    Security References - Profile B: Drag-Drop Completing Permissions

  4. This will open the Security References table which should now contain entries for both "Profile-A" and "Profile-B". For "Profile-B", ensure that only the Read, List and Inheritable checkboxes are selected for this entry. Select/deselect the checkboxes as required.

    Security References - Profile-B: Completing Permissions

  5. Click Apply to apply the changes and then click Ok to close the dialog.

  6. Return to the WebStudio instance logged into with the "Profile-B" profile and refresh the I/O Model. The missing object should now be visible.

    Security References - Profile B: Complete I/O Model

Completing Permissions - Profile-A

We can complete the permissions for the "Profile-A" profile so it can once again view and read the originally selected object.

  1. Using the WebStudio instance that is logged in with administrator privileges, we will create a security reference for the "Profile-A" profile.

  2. Open the Object Model panel and select the I/O Model. Then, select the object where "Profile-B" has a security reference.

  3. Now, switch to the Access Model and drag the "Profile-B" object to the References property compound of the selected object in the Object Lens. This property compound will be highlighted indicating that the object can be dropped there.

    Security References - Profile-A: Drag-Drop Completing

  4. This will open the Security References table for the selected object which should now contain entries for both "Profile-B" and "Profile-A".

  5. For "Profile-A", ensure that only the List checkbox is enabled. Select/unselect the checkboxes as required.

    Security References - Profile-A: Completing Permissions

  6. Click Apply to close the dialog and apply the changes.

  7. Return to the WebStudio instance which is logged into with "Profile-A" and refresh the I/O Model. The originally selected object should now be visible as well as the hierarchical path leading to it.

    Security References - Profile-A: Complete I/O Model