ANSI C Based OPC UA Client/Server SDK
1.8.4.410
|
The authorization module can be used to control a user’s access to nodes in the address space.
To activate the module, the define UASERVER_SUPPORT_AUTHORIZATION has to be set to OPCUA_CONFIG_YES in the uaserver_config.h file. Additionally, at least one of the Authentication modules has to be activated to be able to associate a session with a user.
The authorization module reads the user and group information from two files that are defined in the uaserver_config.h file, UASERVER_AUTHFILE_PASSWD and UASERVER_AUTHFILE_GROUP.
The UASERVER_AUTHFILE_PASSWD file contains four columns:
The following example shows the layout of the file. The first line just denotes the contents of the individual columns, it must not appear in the actual file.
The UASERVER_AUTHFILE_GROUP file contains three columns:
The following example shows the layout of the file. The first line just denotes the contents of the individual columns, it must not appear in the actual file.
If the anonymous logon (OpcUa_UserTokenType_Anonymous) is allowed, the user credentials of the anonymous user are set for sessions that use an anonymous user token. These credentials can be changed by the application as follows:
The access control is realized with UaServer_iNode structures that work similar to linux inodes:
The “uid” parameter defines the owner of the node, the “gid” parameter defines the group the node belongs to. The “mode” parameter defines the node’s access permissions for owner, group, and others. As, for example, a method is not writable and a variable is not executable, the permissions have different effects, depending on the node type:
Variable | Object | Method | |
---|---|---|---|
BROWSEABLE | Browseable Attributes Readable | Browseable Attributes Readable | Browseable Attributes Readable |
READABLE | Readable History Readable | Subscribe to Events | — |
WRITABLE | Writable | — | Executable |
ATTRWRITABLE | Attributes Writable | Attributes Writable | Attributes Writable |
HISTORYINSERT | History Insert / Modify / Delete | History Insert / Modify / Delete | History Insert / Modify / Delete |
We also use bits for different meanings in order to reduce the size of the “mode” member of UaServer_iNode. If the permissions should be split and distributed over more bits, the “Mode defines” section at the beginning of the uaserver_usermgt_types.h header can be modified to match your needs. For example, this would allow to have one bit for each of UA_HISTORYINSERT, UA_HISTORYMODIFY and UA_HISTORYDELETE for setting those permissions individually. When changing those defines, it is important to also change UA_NUM_PERM_BITS accordingly.
For setting permissions easily, there are defines for every permission in the uaserver_usermgt_types.h file that can be OR’d together.
Each OpcUa_BaseNode has a UaServer_iNode member that can be configured individually. The permissions of a single node can be set with UaServer_UserMgt_SetPermissions. Default permissions for single node types can be set with UaServer_UserMgt_SetDefaultPermissions, for all types at once with UaServer_UserMgt_SetDefaultPermissionsAllTypes. The following example demonstrates how to set permissions for a newly created node:
It’s the task of a provider to control access to nodes in the address space. The following functions are available to check a user’s permissions in the provider’s UA service callback functions:
The member UserIdentityData of the UaServer_PublicSession is a pointer to a UaServer_UserCtx that has to be provided to the functions above.