ANSI C Based OPC UA Client/Server/PubSub SDK
1.9.3.467
|
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 five authentication modules available:
To activate a module, the according define has to be set to OPCUA_CONFIG_YES when compiling the SDK. 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 its 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.
The 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, the SHA1 hash is expected in hexadecimal representation. If the username contains spaces, it has to be enclosed in quotation marks.
This is a sample configuration. It should never actually be used in a productive system. The passwords of the sample users are:
The sample configuration also contains users ctt_usrT, ctt_ca1I_usrT and ctt_ca1T_usrT necessary for the OPC Foundation compliance test tool. These do not have passwords and are authenticated through user certificates.
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. Users ctt_usrT, ctt_ca1I_usrT and ctt_ca1T_usrT included in sample configuration for the OPC Foundation compliance test tool can be used as examples for this.
The InternalEx authentication module reads its authentication information from a file that is defined in the uaserver_config.h file, UASERVER_AUTHFILE_PASSWD. This file contains the usernames, hash algorithms, hash iterations, salt values and the hashes of the combination of the salt value and the corresponding password.
The 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, GroupId and UserName columns have to contain valid values, even if they are used only in connection with Authorization.
UserId
and GroupId
are expected to be positive integers.UserName
must not contain quotation marks and must be enclosed in quotation marks if it contains spaces.Algorithm
can be one of sha1, sha224, sha256, sha384, sha512, PBKDF2sha1, PBKDF2sha224, PBKDF2sha256, PBKDF2sha384, PBKDF2sha512
.Iterations
is expected to be a positive integer equal to or larger than 1. For the sha*
group of algorithms, this value must be 1. For the PBKDF2*
group of algorithms, this is the number of iterations for the PBKDF2 algorithm.Salt
can be any string without quotation marks or spaces.Hash
is expected in hexadecimal representation.PBKDF2*
group of algorithms is only supported for OpenSSL >= 1.1.0This sample configuration is delivered with the UA ANSI C SDK. It should never actually be used in a productive system. The passwords of the sample users are:
The sample configuration also contains users "ctt_usrT", "ctt_ca1I_usrT" and "ctt_ca1T_usrT" necessary for the OPC Foundation compliance test tool. These do not have passwords and are authenticated through user certificates.
New entries in the passwd file can be created as follows:
UserId
and GroupId
UserName
sha*
group of algorithms:sha*
algorithms and write it in the Algorithm columnsecret
, salt E1C658D4E8604472846CB2A90832ED1C
and algorithm sha256 that would be the sha256 hash of E1C658D4E8604472846CB2A90832ED1Csecret
, which is 9F86858245078AB26EAC5B4EFE902EF54E15C1ABBE18194A971B26263AA43085
)PBKDF2*
group of algorithms:PBKDF2*
algorithms and write it in the Algorithm columnsecret
, salt E1C658D4E8604472846CB2A90832ED1C
, 1000 iterations and algorithm PBKDF2sha256 that would be 9C5345F67BA72A1EBC3ED94E9B21B021D4382E85F62D842C225DAD21B9FCD9FB
)The InternalEx authentication module can also be used to authenticate users by using X509 certificates. This feature is enabled by default when the InternalEx 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. Users ctt_usrT, ctt_ca1I_usrT and ctt_ca1T_usrT included in sample configuration for the OPC Foundation compliance test tool can be used as examples for this.
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 and the PAM development package has to be installed (usually named “pam-devel”).
More information on PAM can be found under http://www.linux-pam.org/.
The PAM authentication module can also be used to authenticate users by using X509 certificates. This feature is enabled by default when the PAM 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. Users ctt_usrT, ctt_ca1I_usrT and ctt_ca1T_usrT included in sample configuration for the OPC Foundation compliance test tool can be used as examples for this.
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 and the SASL development package has to be installed (usually named “sasl-devel”).
The SASL authentication module can also be used to authenticate users by using X509 certificates. This feature is enabled by default when the SASL 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. Users ctt_usrT, ctt_ca1I_usrT and ctt_ca1T_usrT included in sample configuration for the OPC Foundation compliance test tool can be used as examples for this.
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.
The Win32 authentication module can also be used to authenticate users by using X509 certificates. This feature is enabled by default when the Win32 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. Users ctt_usrT, ctt_ca1I_usrT and ctt_ca1T_usrT included in sample configuration for the OPC Foundation compliance test tool can be used as examples for this.