Authorization refers to determining which authenticated principals are allowed what kinds of access to data within a system. The authorization scheme for PI3 servers is described below:
Authorization for PI on Windows NT and UNIX (PI3)
PI3 defines a table called
DBsecurity that specifies the permissions for the server's internal databases (e.g. point -
PIPOINT, user -
PIUSER, and digital states -
PIDS). Once a connection is made, the settings in this table govern permissions at the global level. These settings are a precondition to
finer granularity security. For example, if
DBsecurity does not allow writing to the PIPOINT database except by its owner, settings in a point's attributes that specify anyone in the system can modify it are irrelevant.
In server versions prior to 3.4.380 each of the three tables has a setting for owner, controlling group, and access permissions. The access permission is a string of the format
o:rw g:rw w:rw
where the letter to the left of the colon indicates the user entity (owner, group, world) and the letters to the right of the colon indicate the permission (read, write). So if the PIPOINT database had an owner of piadmin, a group of piadmin, and a permission string of
o:rw g:r w:
the owner, piadmin could read and write the database, members of the piadmin group could read the database but not write to it, and no one else could even read the database. This would be highly restrictive. It is important to allow enough access to
DBsecurity so the finer granularity permissions can actually work.
With the release of PI-SDK 1.1, objects that represent these secured tables, now support a secondary interface, IPISecurity, which has a single method, IsWriteable. Calling this method allows a program to check for modification access on the corresponding table in the DBSecurity database on the PI Server. This is only applicable on PI3 servers. The IPISecurity interface is supported on the PIPoints, PIUsers, PIGroups, StateSets, PITransferRecordDB, PIBatchDB, PICampaignDB, and PIModuleDB. The interface is returned by the property, Security, on the objects PIAlias, PIAliases, PIBatch, PIBatches, PICampaign, PIHeading, PIHeadings, PIHeadingSet, PIHeadingSets, PIModule, PIModules, PIModuleVersionList, PIProperty, PIProperties, PISubBatch, PISubBatches, PITransferRecord, PIUnitBatch, and PIUnitBatches.
With PI Server version 3.4.380 an new form of access permission syntax is provided to support the wider range of authorization options available with that version. Descriptions of the access rights for a particular object, who can do what to the object, are called Access Control Lists (ACLs) and a particular entry in the list for the rules for one particular principal are called Access Control Entries (ACEs). A string syntax is used to describe these ACLs, providing a mechanism for ACLs to be displayed and configured. A complete description of this new syntax is provided in the Server documentation. An illustrative example would be:
Supervisors:A(r,w) | operators:A(r) | electricians:A(r) | visitors()
Here, 4 different PI Identities are listed (four different ACEs); supervisors, operators, electricians, and visitors. Following the identity name is a colon followed by an A standing for “Allow” and a parenthetical list of comma separated verbs that have been allowed. So here supervisors are allowed to (r)ead and (w)rite, operators can (r)ead but visitors are not allowed any access. The syntax allows for expansion to include “Deny” statements, as well as new verbs that could be multi-character. Defining such a string as the ACL for a particular object sets those permissions for the object. As this new syntax is richer than the previous (o: g: w:) syntax there are rules about moving in between the different ACL types described in the Server documentation. To support environments where both types of ACL are being used, objects that support ACL string properties are given additional properties so that old and new syntax are accessed separately.
PI3 provides security configuration for each point created on the PI System. The configuration is stored as part of the point's attributes.
Legacy point security consists of an owner, a controlling group, an access string for modification of the point's attributes (ptaccess), and an access string for modification of the point's values (event history). The format and interpretation of the
legacy access string is identical to that for the
DBsecurity table. This scheme allows fine grain control over a point (tag) in the system. A typical setting for a point might be
ptaccess o:rw g:r w:r
dataaccess o:rw g:rw w:r
This would allow the creator/owner of the point to control the modification of attributes on the point and would restrict writing values to the owner and members of the point's group. Anyone would be allowed to look at the values or configuration of the point. Note in the PI3 system any user may belong to multiple groups. If you wanted to allow a new user to write to this point you would simply add him to the point's group.
With the introduction of new ACL syntax with PI Server 3.4.380, new attributes are added to objects to provide access to these new strings. (ptsecurity and datasecurity for PI Points; security for other objects). Existing security attributes (ptowner, ptrgoup, ptaccess; dataowner, datagroup, dataaccess, for points; owner, group, access for other objects) remain. When a 1 to 1 mapping is possible between these representations, both are provided. When the older syntax cannot sufficiently describe the configured access, a substitute string is provide which can be parsed but indicates no access (“o: g: w:”). For a more complete discussion please refer to server documentation.