Managing Datasource Permissions

This article will discuss how permissions can be specified for a datasource and its items.

If permissions have been set using security strings (either by property transform or PI/AF security synchronization), setting the access control list directly on the datasource will not work.

By default, newly connected datasources will offer write access to the Everyone Group. Users must have Read permissions on a datasource to see it and the associated permissions; administrators can directly update the datasource and associated permissions through the administration page.

Configuration

Navigate to the Administration page.
Go to the Datasources tab.
Expand the datasource you want to set the permissions on using the carrot button on the far right of the datasource card.
Click the Access Control button.
Set the permissions by adding individual users or groups with at least read access. Unselect the Everyone group if you do not want all users to have access to this datasource. Be sure not to remove the Agent API Key permissions.
Click Save. It may take a while to propagate permissions to all hosted items.

Security String Format

The most flexible way to specify permissions on each item from a datasource is to supply a Security String. A security string is a special property that a connector sets per item that tells Seeq what access control entries an item should have. Items with a security string may not have permissions altered from within Seeq itself.

The permissions visualized in the Access Control screenshot are the result of the below Security String:

CODE

Auth/Seeq/Everyone:r,rd|LDAP/SeeqAuth/Engineering:r,rd,w,wd|LDAP/SeeqAuth/Administration:r,rd,w,wd,m

Each representation of an access control entry is in the format of <identity>:<permissions> and is separated by the | character. Identities should be in the format <datasourceClass>/<datasourceId>/<dataId>. Permissions are comma-separated and may include r and rd for “Read” and “Read Data,” w and wd for “Write” and “Write Data,” and m for “Manage.” Currently, r,rd or w,wd must be specified jointly for the Read or Write permission to be granted within Seeq.

The identity that is performing the sync (“Agent API Key” in the example above) will always be given Read+Write+Manage permission so subsequent syncs can be performed.

Special Security String Values

The following security string values have a special meaning to the system:

An empty string ("") means only administrators will be able to access that item.
A null security string (or the property not being present) indicates no change should be made.
Setting a security string to "not used" will cause the permissions to revert to being manageable from within Seeq, but leave the permissions exactly as they were with permission inheritance being disabled.
Setting a security string to "inherit" will also cause the permissions to revert to being manageable from within Seeq and leave the existing permissions, but permission inheritance will also get enabled, meaning additional permissions might get inherited from a parent item.

Security String as a Property Transform

Using Transforms to Set Permissions

A security string can be added to any datasource by using a property transform in the connector configuration JSON file.

This simple example gives all users Read permission to all items from the datasource.

CODE

"Transforms" : [ {
    "Inputs" : [ {
      "Property" : "Name",
      "Value" : ".*"
    } ],
    "Outputs" : [ {
      "Property" : "Security String",
      "Value" : "Auth/Seeq/Everyone:r,rd",
      "UnitOfMeasure" : null
    } ],
    "Enabled" : true,
    "Log" : false
  } ]

This more complicated example does the following:

All Signals default to no access.
All Assets grant Read access to all Seeq users; Read and Write is granted to the Administration group.
All Signals whose name contains the word “Temperature” grant Read access to all Seeq users; Read, Write, and Manage is granted to the Engineering group.
All items whose name contains the word “Humidity” have their permissions managed from within Seeq.

CODE

"Transforms" : [ {
    "Inputs" : [ {
      "Property" : "Type",
      "Value" : "Signal"
    } ],
    "Outputs" : [ {
      "Property" : "Security String",
      "Value" : "",
      "UnitOfMeasure" : null
    } ],
    "Enabled" : true,
    "Log" : false
  }, {
    "Inputs" : [ {
      "Property" : "Type",
      "Value" : "Asset"
    } ],
    "Outputs" : [ {
      "Property" : "Security String",
      "Value" : "Auth/Seeq/Everyone:r,rd|LDAP/SeeqAuth/Administration:r,rd,w,wd",
      "UnitOfMeasure" : null
    } ],
    "Enabled" : true,
    "Log" : false
  }, {
    "Inputs" : [ {
      "Property" : "Type",
      "Value" : "Signal"
    }, {
      "Property" : "Name",
      "Value" : ".*Temperature.*"
    } ],
    "Outputs" : [ {
      "Property" : "Security String",
      "Value" : "Auth/Seeq/Everyone:r,rd|LDAP/SeeqAuth/Engineering:r,rd,w,wd,m",
      "UnitOfMeasure" : null
    } ],
    "Enabled" : true,
    "Log" : false
  }, {
    "Inputs" : [ {
      "Property" : "Name",
      "Value" : ".*Humidity.*"
    } ],
    "Outputs" : [ {
      "Property" : "Security String",
      "Value" : "not used",
      "UnitOfMeasure" : null
    } ],
    "Enabled" : true,
    "Log" : false
  } ]

Rollback permission transforms / Inherit permissions from the datasource

Removing or disabling such a transform does not restore the system to its initial state. This is because the 'Security String' will not be anymore sent after removal. To properly reset the permissions, you must first set the 'Security String' to an empty string (““) to remove the existing permissions.

CODE

        {
          "Inputs": [
            {
              "Property": "Name",
              "Value": ".*"
            }
          ],
          "Outputs": [
            {
              "Property": "Security String",
              "Value": "",
              "UnitOfMeasure": null
            }
          ],
          "Enabled": true,
          "Log": false
        }

Then, set it to 'inherit' to make the signals inherit the permissions from the upper levels (e.g., from assets or the datasource) again.

CODE

        {
          "Inputs": [
            {
              "Property": "Name",
              "Value": ".*"
            }
          ],
          "Outputs": [
            {
              "Property": "Security String",
              "Value": "inherit",
              "UnitOfMeasure": null
            }
          ],
          "Enabled": true,
          "Log": false
        }

Security String as a Property

A custom connector created using the Connector SDK can return items where the Security String property has been set using the format specified above. The AVEVA PI and AF connectors can automatically set this Security String if configured.