Files
UA-.NETStandard/docs/SessionlessInvocation.md
T
Marc Schier 2836da7ec8 Fix sessionless ResultTransfer ownership bypass and other issues. (#4834)
# Description

Correct ownership, endpoint validation, policy propagation, subscription
delivery, file handling and generated-model behavior across the stack,
tools and samples. Add focused regression tests and update the
corresponding guides and sample documentation.

### Previously included corrections

- Require an active, matching session to generate or access transient
ResultTransfer file handles. Cover both sessionless generation and reads
against a handle owned by an active session, using live session owners
in the Machinery tests.
- Keep physical filesystem operations within their configured mount and
apply the same confinement checks throughout file operations.
- Validate LDS semaphore paths consistently during server registration
and registration-store maintenance.

### Individual issues addressed

| # | Component | Issue and correction |
|---|---|---|
| 1 | AI jobs and transfers | Jobs and transfers did not consistently
retain their creator's identity and session. Apply ownership checks to
descendants, file handles, subscriptions and execution, and recheck
deployment permissions before dispatch. |
| 2 | Password-management client | Password-bearing calls could use
signing-only channels or follow a replacement connection. Capture an
encrypted transport generation and keep dispatch bound to it; preserve
ordinary non-password edits. |
| 3 | GDS and certificate-push clients | Connections omitted hostname
verification. Validate the original configured DNS name or IP address
before session activation. |
| 4 | Certificate push | Private-key uploads could use signing-only
calls. Require an encrypted, generation-bound dispatch while preserving
certificate-only updates and restoring the caller's identity afterward.
|
| 5 | MQTT client | The .NET Framework custom-trust callback could
discard TLS hostname, certificate-availability and usage errors. Retain
those checks while supporting configured issuer trust. |
| 6 | DTLS handshake | Certificate trust was not tied to the configured
peer address. Match the certificate's DNS or IP identity to the intended
endpoint. |
| 7 | Replicated address spaces | Serialized nodes lost per-node and
descendant permission metadata. Preserve role permissions, user-role
permissions and access restrictions, including updates to existing
replica nodes. |
| 8 | MCP PubSub imports | Imports without groups skipped checks on the
effective broker destination. Check the actual endpoint before resolving
credentials or activating the connection. |
| 9 | Reference-server accounts | A disabled username account could
authenticate again with its previous roles. Reject disabled accounts
during fresh authentication. |
| 10 | Console reference client | The sample disabled hostname checks
when connecting to an otherwise trusted peer. Retain the original
requested host and validate it before activation. |
| 11 | Capture replay and export | Replay and raw export could accept
non-capture files or include key material. Require complete PCAP/PCAPNG
containers and exclude key sidecars and decryption-secret blocks. |
| 12 | PubSub adapter fallback | The fallback client configuration
automatically accepted peer certificates. Apply normal trust and
hostname validation before activation or reads. |
| 13 | Kafka transport | Explicit TLS enablement was checked but did not
reach both final Confluent configurations. Use the same effective
protocol for validation, producers and consumers. |
| 14 | PubSub actions | Configuration rebuilds could widen a
connection-local action handler's scope. Preserve its original
connection association and reject mismatched dispatch. |
| 15 | PubSub readers | Reader-level message-protection settings were
accepted but ignored. Apply the effective group and reader settings
before accepting and publishing received values. |
| 16 | PubSub key groups | Different `SecurityGroupId` values could
share one connection-wide key context. Reject mixed groups on a
connection and require separate connections for distinct groups. |
| 17 | MCP session registrations | Session-name replacement or reuse
could retain another registration's credential bindings. Bind access to
the registration, caller and authenticated endpoint, and preserve that
identity when borrowing sessions. |
| 18 | Viewer HTTP host | Requests reached the viewer's OPC UA session
without consistent Host, Origin and port checks. Validate the request
destination and browser origin before using the session, while retaining
supported local MCP clients. |
| 19 | Vision file operations | File operations did not consistently
apply protected-file checks, and remote handles lacked caller and
connection context. Apply the shared checks and use host-side opaque
handles bound to caller, target and generation. |
| 20 | DTLS record integrity | The integrity-only MAC used a truncated
sequence number. Authenticate the full reconstructed sequence number and
epoch so records remain distinct across rollover. |
| 21 | AMB client sample | Connection setup omitted hostname validation.
Preserve the originally requested host and verify the peer identity
before activation. |
| 22 | Robot sample writes | The R2 `SpeedOverride` callback could
target R1 state. Bind each callback to its own robot and apply that
robot's write policy. |
| 23 | AI result properties | Optional result children inherited
remotely writable defaults. Preserve their declaration restrictions and
keep server-produced results read-only. |
| 24 | WSS peer-trust updates | Existing channels did not consistently
respond to peer-trust changes. Revalidate complete chains for forward
and reverse WSS channels and close only those that no longer validate. |
| 25 | GDS revocation checks | Caller-provided certificates could cause
issuer retrieval from embedded URLs. Resolve validation from configured
local trust, issuers and CRLs without fetching caller-provided
locations. |
| 26 | GMS observations | Published correction observations retained
writable model defaults. Reject remote writes while preserving
publisher-side updates. |
| 27 | Production-dataset monitoring | Subscription admission and
delivery could use the reporter's context instead of each subscriber's
permissions. Evaluate the subscriber at admission and on every delivery,
including cancellation and disposal paths. |
| 28 | WoT MQTT destinations | Hostless MQTT forms could imply a
localhost destination before loopback checks. Reject them before
credential lookup or connection attempts and validate the effective
endpoint. |
| 29 | XRegistry opaque reads | Content-ID reads and notifications did
not consistently honor encrypted-read requirements or the currently
accepted transport. Recheck the bound endpoint and reject transport
downgrades before rebinding, including when protected values are already
queued. |
| 30 | PubSub capture dissection | Key loading did not consistently
check the configured capture-root boundary. Check each actual key path
immediately before opening it. |
| 31 | PubSub publication queues | Imported WriterGroup queues were not
fully checked against publish-topic grants. Check the destination
actually used by each group. |
| 32 | MCP PubSub mutations | A caller-supplied mode could select
subscribe grants for an operation that publishes. Derive the required
direction and parent context from the actual mutation. |
| 33 | Generated write masks | Model import and generation could widen
an explicit `UserWriteMask`. Preserve it through import, copy, merge,
inheritance and dependency metadata. |
| 34 | Generated method flags | An explicit `UserExecutable=false` could
be lost. Preserve its specified state and resulting method behavior
through the same model paths. |
| 35 | Generated role identifiers | Unresolved role identifiers could
cause permission entries to be omitted. Preserve namespace-qualified
role IDs and report a diagnostic when a policy cannot be represented. |
| 36 | Aggregation-server defaults | The `localhost` default did not
reliably constrain listener binding. Use numeric loopback for the
default endpoint and command-line fallback. |
| 37 | Certificate-validation cache | Cached results could skip current
leaf or issuer validity checks. Recheck validity windows on cache hits
and keep hostname validation independent of cached chain trust. |
| 38 | Software-update folders | Revision names and marker contents
containing dot segments could select paths outside the software root.
Normalize and check every derived path against that root. |
| 39 | USDA arrays | Array elements were not encoded for their string or
asset context. Escape them as data and preserve valid composition and
round-trip behavior. |
| 40 | Adapter hot reload | A changed dataset definition with the same
name could keep old fields, subscriptions or cached values active.
Compare complete immutable definitions and retire old state before
replacement. |
| 41 | Adapter index ranges | Subscription publication could ignore
`IndexRange` and return the complete value. Preserve the requested
projection and its status and timestamps; reject unsupported range
providers. |
| 42 | PubSub metadata and targets | Metadata from one connection could
change another connection's target mapping. Scope metadata to its
connection and provenance, and resolve targets using actual typed field
IDs rather than field names or unintended positional fallback. |
| 43 | Scales product locks | Product locks were not applied across
every remote mutation path. Apply them consistently to value writes,
filling calculations and related recipe/controller operations while
retaining permitted updates. |
| 44 | Event permission caching | Cached event decisions could outlive
identity, role or node-policy changes. Revalidate the current
subscriber, event type and source permissions instead of reusing a stale
decision. |
| 45 | WoT Modbus destinations | Hostless Modbus forms could imply
localhost before loopback checks. Reject them before connecting and
validate the effective endpoint. |
| 46 | MCP local PKI tools | Peer-trust mutations did not consistently
require the caller's `CertificateAdministration` grant. Check the
capability before trust and untrust operations. |
| 47 | Robot-control HTTP bridge | The bridge lacked consistent Host,
Origin and port validation and caller-specific session grants. Apply
those checks before borrowing the OPC UA session and retain supported
local clients. |
| 48 | Subscription transfers | Transferred subscriptions could retain
cached notifications after the destination's permissions changed.
Require authorization continuity between source and destination
identities and roles, invalidate stale retransmission data when
continuity fails, and preserve retransmission behavior for compatible
transfers. |

### Compatibility notes

- Replication uses the versioned NSRP v1 policy envelope. Upgrade peers
together and re-encode or reseed legacy topology from the authoritative
model; missing permission metadata is not inferred from old records.
- Integrity-only DTLS peers must be upgraded together for the full
sequence/epoch MAC. AEAD behavior is unchanged.
- Distinct PubSub key groups require separate connections.
- Custom sessions that cannot capture the actual encrypted transport,
and subscription providers that cannot honor a requested range, are
rejected rather than silently changing the requested behavior.
- Subscription transfers retain retransmission data only when the
destination authorization remains compatible with the source snapshot;
otherwise the old sequence numbers and cached data are invalidated.

## Related Issues

No separate tracking issue is linked. The individual corrections are
listed above.

## Checklist

_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._

- [ ] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [x] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [ ] I have added all necessary documentation.
- [x] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.
2026-10-21 05:37:29 +02:00

213 lines
9.9 KiB
Markdown

# Session-less Service invocation
OPC 10000-4 [§6.3](https://reference.opcfoundation.org/Core/Part4/v105/docs/6.3)
lets a Client invoke a subset of the Services without CreateSession and
ActivateSession. The request then carries either an Access Token in
`RequestHeader.authenticationToken`, or no token at all. This page shows how
to enable it on a server built with this stack.
## Contents
- [Which Services](#which-services)
- [Enabling it](#enabling-it)
- [Caller identity](#caller-identity)
- [Answers without the feature](#answers-without-the-feature)
- [Limiting concurrent requests](#limiting-concurrent-requests)
- [Taking over completely](#taking-over-completely)
- [Calling the server](#calling-the-server)
## Which Services
Session-less invocation is limited to the Service Sets §6.3.1 names:
| Service Set | Services |
| --- | --- |
| View | Browse, BrowseNext, TranslateBrowsePathsToNodeIds (not RegisterNodes / UnregisterNodes) |
| Attribute | Read, Write, HistoryRead, HistoryUpdate |
| Method | Call |
| NodeManagement | AddNodes, AddReferences, DeleteNodes, DeleteReferences |
| Query | QueryFirst, QueryNext |
Every other Service, for example CreateSubscription or Publish, needs a
Session and is answered with `Bad_SessionIdInvalid` without one.
`SessionManager.IsSessionlessService(RequestType)` returns the same decision.
A request without a Session has no Session state to keep continuation
points in: Browse returns none, and BrowseNext reports every continuation
point as invalid.
## Enabling it
With dependency injection:
```csharp
services.AddOpcUa()
.AddServer(options => { /* … */ })
.AddSessionlessInvocation() // OPC 10000-4 §6.3
.AddJwtIssuer(options => { /* … */ }); // validates the Access Tokens
```
`AddSessionlessInvocation` registers `SessionlessInvocationOptions`. The
hosted server applies them to the session manager it uses, including one
created by `AddSessionManager(...)`, unless that manager was configured
already.
Without dependency injection, set the options on the session manager:
```csharp
var sessionManager = (SessionManager)server.CurrentInstance.SessionManager;
sessionManager.SessionlessInvocation = new SessionlessInvocationOptions();
```
## Caller identity
| Request | Identity | Option |
| --- | --- | --- |
| `authenticationToken` is a String NodeId | The Access Token, validated as an issued JWT token (OPC 10000-6 §7.6.5.2.3) by the server's identity registry, the authenticators ActivateSession uses | `AcceptAccessTokens` (default `true`) |
| no `authenticationToken` | An anonymous user | `AllowAnonymous` (default `false`) |
- The roles of the identity are mapped as ActivateSession maps those of a
Session: the roles granted by the `IRoleManager` identity-mapping rules,
including the configured Access Token claims and the built-in
AuthenticatedUser role, are added to the identity before the request runs.
This also applies to the identity a `ValidateSessionLessRequest` handler sets.
A request without a Session has no client application certificate, so it is
not granted the TrustedApplication role and no application-based mapping.
- §6.3.1 requires encryption for the Access Token. It is only accepted over
a SecureChannel with `SignAndEncrypt`, or over HTTPS. On any other channel
the request is rejected.
- A token no authenticator accepts is answered with the authenticator's
error, or `Bad_IdentityTokenRejected`.
- A request without a token is answered with `Bad_IdentityTokenInvalid`
unless `AllowAnonymous` is set.
- With `AllowAnonymous` the request has to meet what the endpoint demands of
CreateSession and ActivateSession; see
[Anonymous requests and the channel](#anonymous-requests-and-the-channel).
- Session tokens are UInt32 or ByteString NodeIds. A token of that kind that
names no Session stays `Bad_SessionIdInvalid`, which is what a Client
whose Session expired needs to see.
- A valid Access Token authenticates a session-less request, but does not
create a UA Session. In the built-in DI software-update and xRegistry
implementations, file-transfer upload handles require a Session and their
allocation/open or handle operations return `Bad_SessionIdInvalid` to a
session-less caller. Use a Session for those workflows; the general
session-less `Call` allowance does not override a method's stateful
ownership requirements. See [Software Update](SoftwareUpdate.md) and
[xRegistry](XRegistry.md).
Override `SessionManager.ValidateSessionlessRequestAsync` for different
rules.
### Anonymous requests and the channel
§6.3.1 lets a Server skip the Access Token and assume an anonymous user "if
application authentication through the SecureChannel is sufficient". A request
that `AllowAnonymous` admits therefore runs only if its channel authenticates
the application the way the endpoint demands for CreateSession:
| Endpoint | The request needs | Otherwise |
| --- | --- | --- |
| opc.tcp or opc.wss with a security mode or policy other than None | the client certificate of the SecureChannel, which opc.tcp has validated while it opened the channel | `Bad_SecurityChecksFailed` |
| HTTPS (REST, binary or JSON) with a security mode or policy other than None, or with `HttpsMutualTls` set | the TLS client certificate, which the HTTPS listener has validated during the TLS handshake | `Bad_SecurityChecksFailed` |
| HTTPS without `HttpsMutualTls`, SecurityMode None | nothing | |
| any, with user token policies that include no Anonymous policy | an anonymous user token policy on the endpoint, as ActivateSession requires it | `Bad_IdentityTokenRejected` |
| unknown (no endpoint on the channel) | an endpoint | `Bad_SecurityModeInsufficient` |
The endpoints of an HTTPS listener without `HttpsMutualTls` offer no Anonymous
user token policy, so on them an anonymous Session-less request is rejected
as an anonymous Session is.
HTTPS clients are not required to present a certificate (OPC 10000-6 §7.4.1),
and HTTPS authenticates the application when a Session is created. With
`HttpsMutualTls` set, a Client that wants an anonymous Session-less call
presents its application certificate in the TLS handshake. A request that
carries an Access Token does not need the client certificate: the token
authenticates the caller, and HTTPS keeps it confidential.
## Answers without the feature
Without `AddSessionlessInvocation` and without a
`ValidateSessionLessRequest` handler, a request that carries no
`authenticationToken` is answered with `Bad_ServiceUnsupported`, as §6.3.1
prescribes for a Server that does not support session-less invocation.
Requests with a token that names no Session stay `Bad_SessionIdInvalid`.
## Limiting concurrent requests
A request of a Session is accounted for by its Session. A session-less request
has none, but it still occupies a worker and keeps its channel active. The
[resource isolation](ResourceIsolation.md) of the server limits channels,
queued requests and incomplete messages. Session-less requests share these
queue and execution stages with the requests of Sessions. `AddSessionlessInvocation`
adds a ceiling on the number of Session-less requests that run at the same
time. The ceiling does not reserve any capacity: it neither keeps a share of
the queue or the workers free for Sessions nor gives Session-less requests a
share of their own, so Session-less requests below the ceiling still compete
with the requests of Sessions for the shared stages:
| Option | Default | Limits |
| --- | --- | --- |
| `MaxConcurrentRequests` | 64 | Session-less requests that run at the same time, over all channels |
| `MaxConcurrentRequestsPerChannel` | 16 | The same on one channel |
```csharp
services.AddOpcUa()
.AddServer(options => { /* … */ })
.AddSessionlessInvocation(options =>
{
options.MaxConcurrentRequests = 128;
options.MaxConcurrentRequestsPerChannel = 32;
});
```
- Zero does not limit. A negative value is rejected.
- A request counts from the check of its identity until its Service has
completed, failed or was cancelled. A request that is rejected while its
identity is checked, for example because its Access Token is not accepted,
returns its place at once.
- A request over a limit is answered with `Bad_ServerTooBusy`: "The Server does
not have the resources to process the request at this time." The client can
retry the same request later. Nothing was executed.
- The channel of an opc.tcp request is its SecureChannel. The HTTPS bindings
have no SecureChannel per connection, so their requests are grouped by the
network address of the peer. Callers behind one address, such as a proxy,
share the limit.
- Requests that carry a Session token, and requests the feature does not
accept (see [Which Services](#which-services)), are not counted.
- The limits are read for every request, so changing the options applies to the
next request. Requests that run keep their place.
## Taking over completely
A handler on `ISessionManager.ValidateSessionLessRequest` decides before the
built-in handling. It receives the token and the request type and sets the
identity or an error. The Service Set limit above applies before the
handler is called. When `AddSessionlessInvocation` is used as well, the
request limits above apply before the handler too. A handler without
`AddSessionlessInvocation` runs without a request limit.
## Calling the server
Over opc.tcp, any client channel without a Session works, for example a
`SessionClient` on a channel from `ClientChannelManager`:
```csharp
var client = new SessionClient(channel, telemetry);
ReadResponse response = await client.ReadAsync(
new RequestHeader { AuthenticationToken = new NodeId(accessToken, 0) },
0,
TimestampsToReturn.Neither,
[new ReadValueId { NodeId = VariableIds.Server_ServerStatus_State, AttributeId = Attributes.Value }],
ct);
```
Over the [REST binding](WebApi.md) the token is a String NodeId in the JSON
request header:
```json
{
"RequestHeader": { "AuthenticationToken": "s=<access-token>" },
"NodesToRead": [ { "NodeId": "i=2259", "AttributeId": 13 } ]
}
```