UA Server SDK C++ Bundle  1.4.1.271
 All Classes Namespaces Functions Variables Typedefs Enumerations Enumerator Friends Groups Pages
User Authentication and Authorization

OPC UA requires also a user authentication from the Client user in the Server application during the establishment of an application session. The following sections are explaining the configuration options for user identity types and the implementation necessary to apply the user authorization and authentication.

The demo server provides a complete example for user authentication.

User authentication means that a user identity is verified during the creation of an application Session. If the user is not known or the user has no rights to create a Session, the user is not able to connect to the server.

User authorization means that an authenticated user that has already access to the server and has successfully created a Session is checked for having the right to execute the requested action like reading or writing data.

User Authentication

There are different aspects for configuration and implementation of user authentication.

A user can be verified using the user management of the operating system. This option avoids an application specific user management but may make assignment of detailed access rights difficult.

A user can be verified using an OPC server specific user data base. This option allows tailoring of the authorization to any features that should be provided by the server but it requires a user data base implementation and an application specific configuration of the users.

A user can be verified using the user management of the underlying system. This is the typical implementation if the underlying system provides a user management and the requirements for the OPC UA interface as external interface are fulfilled.

Configuration of User Identity Types in the Server

OPC UA supports different user identity token types like Anonymous, User Password and Certificates. The concept is extensible to other token types. The SDK is prepared to handle the token types Anonymous and User Password but it can be extended to more token types in the future without changing the interfaces of the SDK.

The OPC UA client requests the possible token types with the service call GetEndpoints. The returned EndpointDescriptions are indicating the allowed user identity token types. The SDK requests the supported types by calling the method ServerConfig::getUserIdentityTokenConfig().

If the default XML implementation of the ServerConfig interface is used, the following XML element contains the settings for the user identity token type.

<!--Configuration for supported user identity tokens-->
<UserIdentityTokens>
<!--Enable anonymous logon true/false-->
<EnableAnonymous>true</EnableAnonymous>
<!--Enable user/password logon true/false-->
<EnableUserPw>true</EnableUserPw>
</UserIdentityTokens>
<!--User identity token configuration end-->

User Authorization

If a user is connected, a server must check if a requested action can be performed based on the user rights.

Typical configuration options are

  • General settings regarding whether a user is allowed to execute a certain action like reading or writing of data
  • Configuration of which parts of the address space can be accessed by a user
  • Configuration of visibility and access for single variables or pieces of information

It makes sense to implement these options based on user roles or user groups where the different options are assigned to groups or to the Anonymous access.

Session Object as Key to User Authentication and Authorization in the Server

User authentication and authorization is application specific and cannot be provided in a generic way by the SDK. But the SDK provides all means necessary to implement the application specific functionality.

The key to this feature is the Session object. It is passed to all actions that request access to the underlying system encapsulated by the server like browse, read, write, call and monitoring of data changes and events. The information necessary to verify whether the user is allowed to execute the requested operation needs to be stored in the Session object. Since this information is specific to each implementation, the application needs to provide a class derived from UaSession that stores the necessary information like user name or user role. It is recommended to store the information necessary to check the access right instead of storing the original identity.

The SDK provides methods to create the application specific Session class. If the ServerConfig interface is implemented directly, this is done through the method ServerConfig::createSession(). The user logon is done by implementing the method ServerConfig::logonSessionUser().

The demo server example provides full sample code using the utility classes from the examples. See for full User Authentication Example.