ANSI C UA Server SDK  1.7.0.354
 All Data Structures Functions Variables Typedefs Enumerations Enumerator Modules Pages
Authorization

The authorization module can be used to control a user’s access to nodes in the address space.

Configuration

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.

passwd File Layout

The UASERVER_AUTHFILE_PASSWD file contains four columns:

<UserId>
A unique positive integer used to identify a user
<GroupId>
A unique positive integer used to identify the user’s group
<UserName>
The logon name of the user
<SHA1 hash of password>
Hexadecimal representation of the SHA1 hash of the user’s password (only for Internal Authentication Module)

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.

<UserId> <GroupId> <UserName> <SHA1 hash of password>
0 0 root e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4
1 1 anonymous 0000000000000000000000000000000000000000
2 4 joe 21298df8a3277357ee55b01df9530b535cf08ec1
3 5 john 4f26aeafdb2367620a393c973eddbe8f8b846ebd
4 6 sue e122d28c768ab44ceafe00d71adedc80a535cdf1
5 7 "jane doe" da882eab5e403421ac24258a5f7d5f965c29c849
Note
The SHA1 hash of the user’s password must only be set if the Internal Authentication Module is used, otherwise the SHA1 hash column has to be omitted.

group File Layout

The UASERVER_AUTHFILE_GROUP file contains three columns:

<GroupId>
A unique positive integer used to identify the group
<GroupName>
The name of the group; has to be enclosed in quotation marks if it contains spaces
<Users>
A comma separated list of users that belong to the group; has to be enclosed in quotation marks if it contains a username containing spaces

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.

<GroupId> <GroupName> <Users>
0 root root
1 anonymous anonymous
2 operators joe,john
3 users "joe,john,sue,jane doe"
4 joe joe
5 john john
6 sue sue
7 "jane doe" "jane doe"

Anonymous User

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:

UaServer_UserCtx anonymousUserCtx;
anonymousUserCtx.uid = 0;
anonymousUserCtx.gid = 0;
anonymousUserCtx.numgroups = 0;

Usage

The access control is realized with UaServer_iNode structures that work similar to linux inodes:

typedef struct _UaServer_iNode
{
OpcUa_UInt16 mode;
OpcUa_uid_t uid;
OpcUa_gid_t gid;
#if UASERVER_SUPPORT_INODE_LIST
struct _UaServer_iNode *pNextInode;
#endif
} UaServer_iNode;

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:

OpcUa_BaseNode *pVariable;
OpcUa_UInt16 mode;
UaServer_CreateNode(pAddressSpace, (OpcUa_BaseNode **) &pVariable, ...);
// The node's user has full permissions for this node; users of the node's group may only
// read its value and attributes, and they may browse its children. Other users have no
// access to the node.
UaServer_UserMgt_SetPermissions(pVariable, // the node to modify
3, // as in passwd example above, user 'john'
2, // as in group example above, group 'operators'
mode); // the access permissions

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.