_auth (Authorization)
The authorizations for changing data point attributes are managed in the "_auth" config. Authorizations can be specified for each config of a data point element, e.g. for the data point functions of a node, etc. - see figure below.
A manager runs under a user. The user has general user permissions (see Authorization levels and Groups). The user permissions specify the "general" required permission level such as write or read access or right to acknowledge alerts for a specific group and the users of this group. See also chapter WinCC OA Authorization Concept for an overview of the different authorization types in WinCC OA.
Read and write permission for a specific data point config can, however, be specified by using the _auth config. This means that if a user does not have a permission to write data point values in a WinCC OA system, the user could, however, write the value of a specific data point by using the _auth config and setting an authorization for the _original config (see figure below). Therefore, the _auth config specifies an additional authorization level for data point configs.
_auth Config - Two Authorization Types: User and Manager Authorization
The _auth config contains two authorization types: user and manager authorization. The authorizations are "OR"-linked. This means that when a user has neither write nor read permission but a manager possess write rights, the user still possesses write rights. The same also applies to read permission. You can find a list of the WinCC OA managers for which an _auth config can be specified further below.
By specifying an auth config for a data point and by using the "Owner Write" authorization, you specify that a manager running under a specific user may, e.g., write and change the value of a data point. By using "Owner Read" you specify that a manager running under a specific user may only read the value of a data point. You can find the authorization table describing the user and manager authorization further below.
Examples for how to use an auth config for a manager are, e.g., a UI Manager that sets a value via a script or a driver that queries or sets a value. For an example of the _auth config, see further below.
DPE
The data point element or the alias to which the authorization is assigned.
Owner
The manager identifier in the upper part of the panel consists of "Owner" (System number), manager type and manager number.
The manager type contains all manager types available in the system.
Config Name
The column "Config name" contains the data point configs. Configs comprise properties that data points can possess in WinCC OA. For more information see chapter Data point configs, basics.
Read, Write, Owner Read, Owner Write
A table lists the configs and their authorization levels. Click on a line in the table to assign an authorization level to a config.
The _auth config contains two authorization types: user and manager and four authorizations: Read, Write, Owner Read and Owner Write. The authorizations are "OR"-linked. This means that when a user has neither write nor read permission but a manager possesses write rights, the user still possesses write rights. The same also applies to read permission.
| Authorization | Description |
| Read | Read permission for a user. |
| Write | Write permission for a user. |
| Owner Read | Read permission for a manager. |
| Owner Write | Write permission for a manager. |
If a user has no write rights, a value of a data point cannot be set via the dpSet* functions or via the function alertSet. An error message is output in the log viewer. In order to acknowledge an alert, the acknowledgement authorization of the alert class is checked (not the _auth config) - see the description further below.
The _auth config is not evaluated for historical queries.
Watch out when adding authorizations to managers or users. If a manager or user does not have read permission, a manager cannot be started and read values of data points. Similarly, a user cannot read values of a data point!
The following bits (authorization levels) can be set for the different configs:
| Bit (Authorization level) | Description |
| Bits 1-32 | The user need this bit in order to edit or read the config. You can set one of the bits 1-32. |
| 0 | No limitation. The config can be edited or read irrespective of the bits. |
| - | Nobody can edit or read the config. |
| x |
The authorization level (bit) is inherited from the higher-level node or if an authorization level was not defined for the higher-level node, the authorization is inherited from the _System data point. x (inheritance) is the default setting. |
Note, that the _auth config specifies read and write rights for a data point config. The user rights (see chapters Authorization levels and Groups) again "general" read/write/acknowledgement rights for a user.
If an _auth config is not available for a data point, the authorization is inherited from the _System data point.
The set authorization does not have an effect on the user root.
The internal user management data points (Data point type: _Users) possess the auth config with the authorization bits set by default for the configs _address, _default, dp_fct and _original. For the user management you need the bit 3.
The config attributes can be found in the Appendix.
_Auth Config Example: UI User Authorization
In this example, the bit 6 for "Write" was set for the UI Manager with the number 1. This means that a UI Manager with the number 1 running under a user who possesses the bit 6, may change the original value of the data point ExampleDP_Arg1.
- The user JohnPublic possesses the bit 6 that was set for the _auth config. The bit 6 is needed to set the original value of the data point ExampleDP_Arg1.
- A UI with the number 1 that was specified in the _auth config for the data point ExampleDP_Arg1. is opened with the user JohnPublic.
- JohnPublic can set the original value of the data point ExampleDP_Arg1.
_auth Config Example: Manager Authorization
In this example only the driver manager can set the value of a data point. In other words only values from the PLC are accepted since the manager type is driver manager ("DRIVER_MAN").
- The _auth config was set for the data point ExampleDP_Arg1. for the manager type "DRIVER_MAN" with the number 1. The Write and read permissions for the manager were set to 0 (no restriction) and the write permission for the UI user to "Nobody" (-). Via these settings only values from the PLC are accepted.
_alert
The attribute _alert is an exception and not a "real" config. _alert contains the alert_hdl attributes of an alert instance that can be set or queried at runtime via the functions alertSet/alertGet e.g. _add_values
For all alert_hdl attributes, see chapter alert_hdl.
The configuration of an alert is saved in the config _alert_hdl (Alert handling). The attribute _alert only contains the runtime attributes of an alert and not the configuration.
CTRL Script Examples
This section contains examples of how to add an _auth config to a data point by using the CTRL language.
Examples
Only users with authorization level 3 may change an attribute of the "_default" config:
main(mapping event)
{
dpSet("System1:ExampleDP_Result.:_auth._default._write", 3);
}All users may configure peripheral addresses.
main(mapping event)
{
dpSet("System1:ExampleDP_Result.:_auth._address._write", 0);
}Authorizations for changing attributes of the "default" config of the element "dp.el1.el2" are inherited from the parent node "dp.el1". "x" is set for the "default" config in the "Write" column of the authorization config.
main(mapping event)
{
dpSet("dp.el1.el2:_auth._default._write", 255);
}
Authorization for alerts
Writing authorization (edit):
In order to write alert attributes for example, at runtime via alertSet() function with _add_values to set additional values or let an alert "come" and "go" by setting the alert_hdl attribute _event ( ":_alert_hdl.2._event", DPATTR_ALERTEVENT_CAME), the authorization set via the _alert attribute of the _auth config is checked.
To enable the authorization, set the _auth config for a data point as well as an authorization level for the config "_alert_hdl" of the _auth config (see figure below).
Note also that the set _auth authorization is checked for all alert_hdl attributes that can be set via the function alertSet(). This means that the _auth config is not only checked for the attributes "_add_values" and "_event" mentioned above but for all alertSet() attributes if the _auth config was set for a data point.
Acknowledgement rights:
In order to acknowledge an alert, the acknowledgement authorization of the alert class is checked. The authorization is set:
- In the alert handling configuration (_alert_hdl config) of the data point
-
The alert class set in the alert handling might request a certain authorization level to allow alert acknowledgement, see the alert class "040_warning" below as well as the second figure "Acknowledgement authorization in the internal alert class "warning" (alert priority 40)" below:
Figure 9. Data point "ExampleDP_arg2" and the config _alert_hdl - alert handling 
- In the internal alert class _AlertClass where the acknowledgement authorization for the alert class is specified.
The alert class "warning" with the alert priority 40 was used for the alert handling of the data point "ExampleDP_arg2" when the alert class 040_warning was selected. Therefore, the acknowledgement authorization of the internal alert class is valid for the data point "ExampleDP_arg2".
3 different authorization scenarios are available:
- You can set the _auth config. The _auth config is checked when alert attributes are written.
- You can set the acknowledgement authorization for an alert class and thus for the alert handling when the same alert class is used for an alert handling of a data point.
- You can set both the _auth config as well as the acknowledgement authorization.
