South s2opcua not working with Security None and User Authentication username
vamaffeis opened this issue · comments
Describe the bug
I've setup an OPC-UA server (KepServerEX 6) with the following security configuration:
- Security Mode: None
- User Authentication Policy: UserName
The South Service Security is configured as follows:
The south service is created, but the connection can't be established.
These are the debug logs before the connection fails:
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: WARNING: Not connected to OPC/UA Server: opc.tcp://opc.server.local:49320
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: ERROR: There are no endpoints that match the Policy Id username
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: ERROR: Failed to match any server endpoints with Security Mode 'None', Security Policy 'http://opcfoundation.org/UA/SecurityPolicy#None', Authentication policy 'username'
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0: 'username' != 'UserName' (1)
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0: checking user ID tokens
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: Endpoint 0 matches on security policy http://opcfoundation.org/UA/SecurityPolicy#None
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: Endpoint 0 matches on security mode None
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: Endpoint matching starting....
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: Requesting username authentication policy
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: Requesting Security Mode 'None', Security Policy 'http://opcfoundation.org/UA/SecurityPolicy#None'
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 0 - security policy Uri: http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 0 - issuer endpoint Url: (null)
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 0 - issued token type: (null)
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 0 - token type: 1
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 0 - policy Id: UserName
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 - transport profile Uri: http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 - security policy Uri: http://opcfoundation.org/UA/SecurityPolicy#None
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 - security mode: 1
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 - security level: 16
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: 0 - url: opc.tcp://opc.server.local:49320
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: OPC/UA Server has 1 endpoints
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: SOPCInit Start
Jan 18 16:25:58 e958aa5be2fe Fledge KepUserNone[61203]: DEBUG: Calling OPCUA::start
The issue seems to be happening only when the server is set up with Security Mode None + Authentication UserName, while setting it up with Security Mode Sign + Authentication UserName works correctly.
To Reproduce
Steps to reproduce the behavior:
- Set Up an OPC Server with Security Mode: None and User Authentication Policy: UserName
- Install s2opcua plugin
- Create a South Service reading a single tag, configuring the Security as shown in the previous image
Expected behavior
The South Service should connect to the OPC Server and start to read the values configured.
Additional context
To ensure that it was not a server configuration problem, I tested the same connection with the same parameter with the UAExpert client, which connected successfully.
I also changed the OPC Server from KepServer to Ignition Gateway UA Module, but the behaviour didn't change.
I thought it was related to this log line DEBUG: 0: 'username' != 'UserName' (1), and that the fact that in fledgeUI the Auth Policy is lower_case could be the culprit, even though it's only logged when Security Mode is None, while the match is done correctly with Security Mode Sign.
Thank you for bringing this to our attention. One of our developers will look into this issue and hopefully provide a fix or more details shortly.
We will research this but I wanted to point out that this configuration is not recommended for production environments. It means unencrypted passwords over the wire.
Summary: the S2OPCUA South plugin does indeed disallow username authentication with a Security Policy of None. We think this is correct behavior and will not be changing it. We will update documentation and debug log messages.
Details: Any OPC UA server must report a list of endpoints it is able to support. The information returned for each endpoint includes a Security Policy for creating a secure channel and a list of UserIdentityTokens the server is able to support on the endpoint. The UserIdentityToken includes its own Security Policy. The UserIdentityToken Security Policy defines how user credentials are to be encrypted and transferred. The OPC UA Specification Part 4, Section 7.36.4 defines these rules.
The OPC UA Specification allows the endpoint and the UserIdentityToken Security Policies to be different but they should be compatible. The S2OPC OPCUA Toolkit we are using does not offer this flexibility: it requires these two Security Policies to be identical. To make sure this happens, the S2OPCUA South plugin reads through all endpoint information to find an endpoint that matches the plugin's configuration and also a UserIdentityToken Security Policy that matches the endpoint's Security Policy. The Debug messages you have seen show the steps taken in this search.
It appears that Unified Automation's UA Expert does not implement this strict rule so it is able to connect. It may be frustrating that the S2OPCUA South plugin does not support username/password with a Security Policy of None but we will not change it. The OPC UA Specification points out that this configuration carries considerable risk, as it says (emphasis added): "If the SecurityPolicy is None then the password only contains the UTF-8 encoded password. This configuration should not be used unless the network is encrypted in some other manner such as a VPN. The use of this configuration without network encryption would result in a serious security fault, in that it would cause the appearance of a secure user access, but it would make the password visible in clear text."
You are correct that the debug messages that log the mismatches are misleading. These messages will be clarified. In addition, we will make an addition to the documentation to point out that username/password authentication must be combined with a Security Policy other than None.
Thank you for the detailed answer!