Files
f6b27025a6 Classify sensitive log parameters with Microsoft.Extensions.Compliance data classification (#4864)
## Proposed changes

Fixes #4857. The stack's log messages wrote network addresses (endpoint,
discovery and reverse connect URLs, host names, IP addresses, ports),
application and user identities, file paths and exception texts as plain
parameters. Applications had no reliable way to keep them out of
general-purpose logs.

This PR replaces the stack's own redaction mechanism with the standard
.NET [data classification and
redaction](https://learn.microsoft.com/dotnet/core/extensions/data-redaction)
packages. Each sensitive `[LoggerMessage]` parameter is classified. The
application decides per classification what reaches its logs: erase it,
replace it with an HMAC token so entries stay correlatable, or pass it
through.

### Taxonomy
`Opc.Ua.Redaction.OpcUaDataClassifications` defines the `OpcUa` taxonomy
and one attribute per classification:

| Classification | Used for | Parameters |
|---|---|---|
| `[NetworkAddress]` | URLs, host and domain names, IP/MAC addresses,
end points, ports | 120 |
| `[ApplicationIdentity]` | certificates, subject, issuer, thumbprint,
ApplicationUri | 103 |
| `[FilePath]` | file, directory and certificate store paths | 67 |
| `[SensitiveText]` | exception or remote-supplied text passed as a
parameter | 55 |
| `[UserIdentity]` | user names, token subjects | 7 |

Correlation ids (`ChannelId`, `SessionId`, ...), status codes and
NodeIds stay unclassified.

### Pipeline and defaults
- Opc.Ua.Core now references
`Microsoft.Extensions.Telemetry(.Abstractions)` 10.11.0, so every
project above Core uses the `Microsoft.Gen.Logging` generator.
Opc.Ua.Client already did, through Http.Resilience. The packages ship
net462 and netstandard2.0 builds, so net48 is supported.
- **A plain `ILoggerFactory` logs `(null)` in place of classified
values.** Classified values are only written by the redaction-aware
logger.
- The new `ILoggingBuilder.EnableOpcUaRedaction()` turns that logger on.
It is `EnableRedaction()` with the discriminator off; otherwise every
unredacted value gets `:ParamName` appended.
`AddOpcUa().AddLogging(...)` and `DefaultTelemetry.Create(...)` call it,
as do the samples, so they log the same information as before until
redactors are registered.
- `services.AddOpcUa()` alone does not change the host's logging.
Generic-host apps call `builder.Logging.EnableOpcUaRedaction()`. This is
documented as a behavior-breaking change in
`docs/migrate/2.0.x/telemetry.md`.

### Obsolete API
`Redact`, `RedactionWrapper<T>`, `IRedactionStrategy`,
`RedactionStrategies` and `SimpleRedactionStrategy` are `[Obsolete]`.
They still work, but the stack no longer uses them.

### Not classified
- The `Exception` passed to a log call. Applications can drop exception
messages with `LoggerEnrichmentOptions.IncludeExceptionMessage`.
- Exception and `ServiceResult` message texts.
- `ServiceResult`/`StatusCode` parameters and logged data values.
- The few log calls whose level is decided at run time.
- `Opc.Ua.Vision.OpenUsd`, which references only Opc.Ua.Types and cannot
see the attributes.

### Generator behavior differences
These are visible to log consumers and to tests:
- `IFormattable` values such as `NodeId` are stored in the structured
state as invariant strings, not as objects.
- The generated log state is a thread-local object that is cleared after
the call.
- Classified values are pooled redactor objects, valid only during the
`Log` call.

Tests that inspected log state after the fact now capture it during the
call. The shared `RecordingLoggerProvider` snapshots classified values.

## Related Issues
- Fixes #4857

## Types of changes
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] Enhancement (non-breaking change which adds functionality)
- [ ] Test enhancement (non-breaking change to increase test coverage)
- [x] Breaking change (fix or feature that would cause existing
functionality to not work as expected; plain logger factories drop
classified values)
- [x] Documentation Update (if none of the other choices apply)

## Checklist
- [x] I have read the CONTRIBUTING doc.
- [x] I have signed the CLA.
- [x] I ran tests locally with my changes, all passed.
- [x] I fixed all failing tests in the CI pipelines.
- [x] I fixed all introduced issues with CodeQL and LGTM.
- [x] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [x] I have added necessary documentation (if appropriate).
- [ ] Any dependent changes have been merged and published in downstream
modules.

## Further comments
New tests:
- `LogClassificationCoverageTests` (Tools.Tests) scans all 104 stack
assemblies and fails if an address, identity or path parameter of a
`[LoggerMessage]` method is unclassified.
- `DataClassificationLoggingTests` (Core.Tests) pins erasing and HMAC
redaction, pass-through, the plain-factory drop, and both stack
defaults.

Local results on net10.0:

| Suite | Passed | Failed |
|---|---|---|
| Core.Tests | 6,489 | 0 |
| Client.Tests | 3,231 | 0 |
| Tools.Tests | 7,210 | 0 |
| PubSub.Tests | 1,536 | 0 |
| Core.Diagnostics.Tests | 571 | 0 |
| Configuration.Tests | 241 | 0 |

- **Server.Tests:** the full run predates the final test fixes and had
12 failures. All 12 were in the fixtures fixed afterwards, which now
pass: RoleStateBinding (45/45) and the FileDirectory and
compatibility-logging fixtures (74/74 in total). The full Core.Tests and
Server.Tests runs were not repeated after those fixes.
- **Builds:** `UA.slnx` builds with 0 errors for net10.0 and net48, and
the whitespace check passes.
- **NativeAOT:** not confirmed locally, because the machine has no C++
linker. A trimmed publish of `Opc.Ua.Aot.Tests` reported no trim or AOT
warnings from the stack, the new packages or the generated logging code;
its only errors come from the TUnit test framework (`FSharp.Core` not
found). The `aot-test` CI job has to confirm the native build.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>
2026-10-21 09:47:07 +00:00
..

OPC 40223 Pumps samples

Two console applications that show the Opc.Ua.Pumps* libraries end to end: a server that publishes pumps with the fluent builders, and a client that discovers and reads them with PumpsClient.

Sample What it does
PumpsServer Serves a duty/standby pair of cooling-water pumps and simulates them once a second
PumpsClient Discovers every pump, prints the whole pump, then streams live values and supervision changes

The Pumps developer guide explains every API used here.

Run

In two terminals:

dotnet run --project samples/Pumps/PumpsServer -- --port 62547
dotnet run --project samples/Pumps/PumpsClient -- --insecure --seconds 30

--insecure makes the client accept the server's self-signed certificate; never use it in production. The client also takes --url <endpoint> (default opc.tcp://localhost:62547/PumpsServer) and --seconds <n> (how long to stream, 0 to skip).

The client prints something like:

Pump CoolingPump_A  (ns=1;i=3788608060)
  Acme Pumps CW-80, serial CW80-0042, built 2024/3 in DE
  location: Plant 1 / Cooling skid
  Design:
    ClockwiseRotation                  True
    MaximumAllowableContinuousSpeed    3000 1/min
    MaximumAllowableWorkingPressure    1.6E+06 Pa
  Implementation:
    PumpBestEfficiency                 78 %
    RatedFlow                          25 kg/s
    RatedSpeed                         2900 1/min
  SystemRequirements:
    Fluid                              Cooling water
    MaximumFlow                        32 kg/s
    MinimumFlow                        6 kg/s
  Measurements:
    BearingTemperature                 27.92 °C
    DifferentialPressure               367831 Pa  [0 … 1600000]
    MassFlow                           21.58 kg/s  [0 … 32]
    NumberOfStarts                     0
    PumpEfficiency                     75.08 %  [0 … 100]
    PumpPowerInput                     9.64 kW
    Speed                              2821.17 1/min  [0 … 3000]
  Measurements/DriveEndBearing:
    OverallVibrationVelocityRMS        2.88 mm/s  [0 … 11.2]
    ReferenceStandardForVibrationMeasurement ISO 10816-3
  Signals:
    PumpOperation                      True
    StandBy                            False
  MultiPump: role Master, mode RedundancyOperation, 1 of 2 pumps in operation
  supervision: no active signals
  maintenance: OperatingState, Level1, failure False, operating time 12480 h
  port Suction: InletConnection, direction In, DN100 PN16 flange
  port Discharge: OutletConnection, direction Out, DN80 PN16 flange
  port Motor: Drive, direction -, no category
  Motor/Measurements:
    MotorCurrent                       18.84 A
    MotorTemperature                   35.92 °C
  document OperationManualLink: https://pumps.example.com/manuals/cw-80.pdf
  document TechnicalDataLink: https://pumps.example.com/datasheets/cw-80.pdf

Pump CoolingPump_B  (ns=1;i=1919434908)
  …

Polled 7 measurements with PumpReadOptions.ValuesOnly; MassFlow = 21.58

Watching 8 values for 45s (the pumps swap duty every 90 s; cavitation appears once a minute) …
  00:04:19  CoolingPump_A DriveEndBearing vRMS 2.91
  00:04:19  CoolingPump_A Cavitation       False
  00:04:19  CoolingPump_B PumpOperation    False
  00:04:19  CoolingPump_B Cavitation       False
  00:04:19  CoolingPump_A MassFlow         21.75
  00:04:19  CoolingPump_B MassFlow         0
  …
  00:04:56  CoolingPump_A DriveEndBearing vRMS 7.1
  00:04:56  CoolingPump_A Cavitation       True
  00:05:02  CoolingPump_A Cavitation       False

NodeIds and namespace indices are whatever the server assigned; only the browse names are stable.

What the server shows

File Shows
Program.cs AddPumps() and ConfigurePumps(...) on the generic host
PumpFleet.cs CreatePumpAsync, WithNameplate, every group builder (Design, Implementation, SystemRequirements, Measurements, Signals, Supervision(...), MultiPump, MaintenanceCategory(...), AddPort, Documentation), engineering units and ranges
PumpFleet.cs A vibration measurement from the <Vibration> placeholder with AddVibration, and the PumpUnit holder of the builders the simulation writes through
PumpSimulation.cs A BackgroundService driving values, a duty/standby exchange every 90 s, and a cavitation episode once a minute
PumpDatasheet.cs Static pump data and UNECE engineering units built per OPC 10000-8 §5.6.3

Runtime updates. The simulation writes through the builders it kept at configuration time. Every Set/SetAnalog/SetDiscrete publishes the change, so subscribed clients see each update without further code.

What the client shows

Code in Program.cs Shows
connection.Session.Pumps(telemetry) Creating the client; registers the OPC 40223 structured types
pumps.IsSupported Detecting whether the server publishes OPC 40223
EnumeratePumpsAsync Discovery from the DI DeviceSet and the Machinery Machines folder
ReadPumpAsync → PumpSnapshot The whole pump in one pass; each group has its own Read…Async too
PumpValueSet / PumpValue Values with engineering unit and range, AsDouble, AsString
PumpValueSet.Groups Nested groups such as the DriveEndBearing vibration measurement
PumpSupervisionStatus.ActiveSignals Only the raised supervision signals
PumpMaintenanceData StateOfTheItem, MaintenanceLevel, HasFailure
ReadMeasurementsAsync(…, PumpReadOptions.ValuesOnly, …) Cheap polling once the metadata is known
Streaming.SubscribeDataChangesAsync(value.NodeId, …) Subscribing to a reading; PumpValue.NodeId is the node that carries it, also for discrete signals

SampleSession.cs is the session setup. It keeps the ApplicationInstance alive until the session closes, because the instance owns the CertificateManager the session validates with.

Publish as NativeAOT

Both samples are NativeAOT-compatible on net10.0:

dotnet publish samples/Pumps/PumpsServer -c Release -f net10.0 -r osx-arm64

Troubleshooting

Symptom Fix
Client reports BadCertificateUntrusted Pass --insecure for the demo, or trust the server certificate in the client's PKI (under the local application data folder, OPC Foundation/PumpsClient/pki)
The server publishes no pumps. Wait for the server log line Materialised pump … before starting the client
Port already in use Start the server with --port <n> and the client with --url opc.tcp://localhost:<n>/PumpsServer