OPC UA Endpoint Selection: Match Security Policy, Mode and User Token Policy
Select an OPC UA endpoint by intersecting the complete EndpointDescription with the client’s capabilities and deployment policy. The required transport, message-security mode, channel SecurityPolicy and UserTokenPolicy must all be compatible. Choosing the first familiar URL or the highest securityLevel can still leave the client unable to authenticate the intended user.
This guide pins OPC UA Part 4, Services, version 1.05.07, sections 5.5.4, 5.7.2.2, 7.14, 7.40 and 7.41. It provides an endpoint-selection qualification procedure, not certificate provisioning or a recommendation of particular cryptographic algorithms. A reduced selection fixture was executed with abstract labels; no credentials, SecureChannel or server were used.
Treat each description as a complete candidate
A server can return several EndpointDescriptions with the same physical URL but different security configurations. Part 4 says clients should treat these as distinct endpoints. Deduplicating discovery results by URL can discard the only compatible user-token configuration.
Record the URL, server application context, certificate information, transportProfileUri, securityMode, securityPolicyUri and the complete userIdentityTokens list. Keep these fields associated with the same candidate rather than assembling a synthetic endpoint from convenient pieces of different records.
The transport profile determines more than a socket address, including mapping details such as message encoding and protocol support. A client that recognizes a SecurityPolicy name still needs the corresponding transport implementation and cryptographic capability.
Resolve the user-token policy separately
UserTokenPolicy identifies a token type such as username, certificate, anonymous or issued token. Its policyId is the server-assigned value the client uses when constructing the chosen UserIdentityToken. Preserve that exact value from the selected policy; do not invent it from the token type or reuse one cached for another server.
The token policy can specify a SecurityPolicy for encrypting or signing the user token. If its securityPolicyUri is null or empty, the policy of the selected SecureChannel endpoint applies. An empty token-policy URI therefore does not mean “unencrypted token.”
For issued tokens, the issuedTokenType and issuer information are also part of compatibility. For certificate user tokens, support for the application’s channel certificate does not automatically establish support for the user’s certificate algorithm and token-signing requirements.
Use the SDK’s supported token construction and proof-of-possession path. The endpoint selector should verify capability, not implement ad hoc password encryption or signature formatting.
Keep deployment policy ahead of ranking
Write explicit allowed modes and policies into the product configuration. If no candidate satisfies them, fail with the rejected dimensions. Do not repair a failed secure connection by silently trying a weaker mode or anonymous identity.
securityLevel compares EndpointDescriptions for the same server. A higher number indicates a server-reported stronger option, while zero marks a backward-compatibility option that is not recommended. It is not a cross-vendor algorithm rating or permission to override local policy.
The exact standard also contains constraints between token policy, channel mode, public-key algorithm and server certificate. Check those combinations through the selected stack and supported profile. A policy URI being recognized is necessary but not sufficient for constructing a usable token.
An original candidate matrix
The hypothetical product requires transport T, server context S, SignAndEncrypt, approved channel policy P and a username token protected under P. P, T and S are abstract fixture labels, not actual OPC UA policy URIs or authenticated identities.
| Candidate | Distinct property | Decision |
|---|---|---|
| A | All requirements match; token policy empty; level 10 | Eligible: token policy inherits P |
| B | Sign only; level 255 | Reject required-mode mismatch |
| C | Certificate token only | Reject intended-token mismatch |
| D | Username token explicitly requires unsupported Q | Reject token-policy mismatch |
| E | All requirements match; level 5 | Eligible, ranked below A |
The executed selector admitted A and E and chose A. B’s high level could not bypass the mode requirement. Additional cases rejected the wrong transport and server-context label, and an all-ineligible set produced no selection.
This tests the policy intersection only. Matching S in a dictionary does not authenticate a real server; certificate and endpoint-identity validation still belong to the security stack.
Verify discovery consistency during Session creation
GetEndpoints does not itself require message security, so its response must not become unquestioned authorization to trust a new identity. Perform the normal certificate and endpoint validation before sending a user token, including when a server certificate is used specifically to encrypt it.
When discovery selected the security options, CreateSession returns serverEndpoints that the client must compare with the discovery information under section 5.7.2.2. The comparison is scoped to matching transport profiles and the prescribed fields. When security options are explicitly configured, the client follows that configuration instead.
Let the SDK implement the exact comparison where supported. A convenient application comparison of URL alone misses changes in mode, policy or accepted user tokens. Report mismatches distinctly from a wrong password or unavailable transport.
Produce actionable rejection evidence
- Capture a redacted endpoint inventory with full candidate associations.
- Apply expected-server and transport checks, then allowed channel-mode and policy checks.
- For every surviving candidate, enumerate usable user-token policies and resolve inherited security policy.
- Verify the exact policyId and required algorithms are supported by the installed SDK configuration.
- Rank only eligible candidates according to deployment preference and server-relative level.
- Run discovery/CreateSession consistency checks and establish the Session through the supported security path.
Log categorical rejection reasons without passwords, tokens or private keys. In an isolated qualification setup, test a compatible endpoint, unsupported token policy, missing token type, changed discovery record and no eligible endpoint. Acceptance means the selected tuple explains both channel establishment and user authentication, while a failure identifies the incompatible dimension without reducing security automatically.
