UA Ansi C Server Professional
1.3.0.225
|
The server allows to authenticate users by username and password when a session is activated. The user's credentials are then verified with one of the available authentication modules. Only one module can be activated at the same time.
There are four authentication modules available:
To activate a module, the according define in the uaserver_config.h file has to be set to OPCUA_CONFIG_YES. After this step, the chosen module can be set after the UaServer has been initialized:
Additionally, the server's endpoint has to be configured to accept UserName UserIdentityTokens. If no anonymous logon should be allowed, the Anonymous UserIdentityToken has to be disabled. Following code shows how to enable the UserName logon only:
As an alternative, the UaServer_UserAuthType can be set to UserAuthType_User. Then the third parameter of the UaServer_SetUserAuthenticationTypeEx method expects a pointer to a callback function that handles the authentication.
The internal authentication module reads it's authentication information from a file that is defined in the uaserver_config.h file, UASERVER_AUTHFILE_PASSWD. This file contains the usernames and the SHA1 hashes of the according passwords.
Following example shows the layout of the file. The first line just denotes the contents of the single columns, it must not appear in the actual file. Also, the UserId and GroupId columns have to contain valid values, even if they are used only in connection with Authorization. The UserId and GroupId are expected to be positive integers, the username can be any string without whitespaces, the SHA1 hash is expected in hexadecimal representation.
This sample configuration is delivered with the UA ANSIC SDK. It should never actually be used in a running system. The passwords of the sample users are:
The internal authentication module can also be used to authenticate users by using X509 certificates. This feature is enabled by default when the internal authentication module is enabled, only the endpoint has to be configured to allow X509IdentityTokens (TokenType OpcUa_UserTokenType_Certificate).
The folder containing the accepted certificates is set by the define UASERVER_USERCERTS_DIR, the folder for storing certificate revocation lists belonging to the certificates is set by the define UASERVER_USERCRL_DIR.
If authorization is enabled, the 'Subject Common Name' is used as user name for looking up the authorization information in the passwd and group file. Hence, in this configuration these files have to exist and be filled with reasonable values.
The PAM authentication module uses the PAM library for validating the user's credentials. The service name passed to the PAM library is 'opcua', so a '/etc/pam.d/opcua' PAM configuration file is expected to be existing. The service name can be changed in the uaserver_auth_pam.c file if necessary. The following shows the content of a sample 'opcua' PAM configuration file that uses the shadow mechanism for authentication:
If PAM is configured to use the shadow mechanism, the server has to be running in the context of a user who has read access to the /etc/shadow file.
If this module is used, the application needs to be linked against the 'pam' library.
More information on PAM can be found under http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/.
The SASL authentication module uses the saslauthd daemon on the local machine for validating the user's credentials. The saslautd daemon is expected to listen on '/var/run/sasl2/mux' for incoming connections, this value can be changed in uaserver_auth_sasl.c if necessary. The service passed to the saslauthd daemon is 'imap', this can also be changed in the same file.
If this module is used, the application needs to be linked against the 'sasl2' library.
The Win32 authentication module validates the user's credentials against the windows logon provider. If the user is in a domain, the domain name can be passed together with the user name. There are two notations available that are recognized by the Win32 authentication module:
For these notations, username and domain are split at the separator automatically and are passed to the windows logon provider separately.