mirror of
https://github.com/OPCFoundation/UA-.NETStandard.git
synced 2026-10-22 01:26:20 +08:00
5899354441
# Description Remove stock phrasing and correct misleading or inconsistent technical documentation. The initial two passes covered 367 Markdown files, followed by an interactive review of 169 editorial flags. The U5 interpretation originally deferred in that review has since received the upstream Mantis answer recorded by #4843; remaining server/spec follow-ups stay explicit in the CTT log. - Correct package responsibilities, migration steps, API names, ownership, protocol descriptions and links. Keep bundled migration guides synchronized. Preserve historical conclusions as historical records with separate re-check notes. - Provide at least two rendered TOC levels throughout `docs/`. Convert appropriate architecture figures to Mermaid without changing code examples, transcripts or historical quotations. - Address the October 19 feedback with concrete setup/migration instructions, corrected certificate paths and PubSub names, shorter repeated caveats, consistent XML comments, and a full review of the Concepts guide. Retain #4839's API corrections. - Integrate #4841's runtime/performance guidance and review incoming/recent prose. Preserve dated measurements rather than claiming new benchmark runs; clarify allocation ratios, startup-only processor settings, JIT warm-up and the benchmark commit's scope. Missing raw measurement artifacts and repeat ranges remain tracked by #4842. - Merge master through `e8c5d800a` in `32c6394b7`. Resolve the CTT log conflict using the updated Mantis states and OPC answers, retaining historical framing and re-checks for C28/C32/C43. - Address the latest naming/index feedback in `adb5bf693`: rename the guides to `docs/WotCon.md` and `docs/WotNodeSetConversion.md`; move the provider and DataType-declaration contracts into the conversion guide and remove `docs/WoT.md`. Rename `samples/DI` to `samples/Di` and `samples/Isa95` to `samples/ISA95`. Add content-index READMEs to Di, FluentApi, ISA95, Lds and PubSub; update solution entries, project references, Docker/CI paths, test fixture paths and documentation links with exact casing. **WoT guide scope.** This branch retains the detailed conversion guide that #4758 had replaced with an anchor stub. Conversion limits, verified document sets, preservation rules and provider ownership now live together in `WotNodeSetConversion.md`; binding/runtime guidance remains in `WotBindings.md` and `WotCon.md`. The design-rationale/test-ledger prose was shortened, the oversized argument-table cell moved into its section, and existing anchors preserved. **SDK policy is a separate, explicit user-directed change.** `global.json` sets a stable minimum of `10.0.400`, `rollForward: latestMajor`, and `allowPrerelease: false`. Newer major SDKs are permitted; CI's explicit SDK pins are unchanged. README, GettingStarted, DeveloperGuide and Recycling instructions reflect the possible analyzer differences. The image-contract regression fix accepts compatible stable SDK images instead of requiring exact equality with the floor. The latest four rename/index threads are resolved after publication. Three older threads remain open: universal obsolete-removal timing, unconditional nonce-strength wording, and a blanket Vision NativeAOT claim. Existing implementation/evidence constraints are explained in their inline replies. The two-level TOCs remain as requested. ## Validation - `git diff --check` and staged diff checks: passed. The untouched upstream AutoID NodeSet retains its provenance bytes, including two existing license-header trailing spaces. - `.\.azurepipelines\validate-migration-plugin.ps1`: passed; 15 bundled migration documents and manifests synchronized. - Documentation/path validation: **101** documents retain two rendered TOC levels (**2,228** entries), with idempotent formatting. **52** new relative links and their anchors passed exact-case checks. No tracked references to the old guide/sample paths remain. Both relocated provider-contract sections are preserved in the destination. - `dotnet sln UA.slnx list`: passed; shows the renamed Di/ISA95 projects and the existing FluentApi/Lds/PubSub projects. Updated solution and pump ProjectReference paths also passed exact-case existence checks. - Latest focused commands, run from the repository root: ```powershell # Passed: 61 channel send-order and reconnect tests. dotnet test tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~UaSCBinaryChannelSendOrderTests|FullyQualifiedName~TcpReconnectKeyAgreementTests' --verbosity minimal # Passed: 5 pump datasheet tests; builds the renamed pump sample. dotnet test tests\Opc.Ua.Di.Tests\Opc.Ua.Di.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~PumpDatasheetConformanceTests' --verbosity minimal # Passed: 4 repository NodeSet path/round-trip tests, including the moved pump models. dotnet test tests\Opc.Ua.Types.Tests\Opc.Ua.Types.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~RepositorySourceSurvivesSerializedLinkedPartitionsAsync' --verbosity minimal # Passed: build, zero warnings/errors. dotnet build samples\ISA95\MinimalIsa95Server\MinimalIsa95Server.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal # Passed: dependent sample-test project build, zero warnings/errors. dotnet build tests\Opc.Ua.WotCon.Samples.Tests\Opc.Ua.WotCon.Samples.Tests.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal ``` Earlier focused integration checks passed 2,620 tests across AutoID, event queues/scheduling, source generation, MCP/package profiles and WoT. Both reviewed Mermaid diagrams rendered locally without network access. These checks are not a full solution run. The full solution has **not** been rerun for this review. Earlier `dotnet test UA.slnx -p:CustomTestTarget=net10.0 --verbosity quiet` did not pass: three AOT projects rejected VSTest and 20 Vision tests failed during graphics initialization with `OutOfMemoryException`. Remaining long-running tests were stopped at the user's request. A focused Vision rerun passed 558 tests and reproduced those 20 failures. The earlier `dotnet test UA.slnx -p:CustomTestTarget=net48 --verbosity quiet` was blocked by the former SDK pin and was not retried after the policy change. The user approved proceeding with those limitations documented; current remote CI is not claimed green. ## Related Issues - Follow-up #4842 tracks the requested 2.0.2+ benchmark/tuning and diagnostic-tool documentation refresh. #4841 supplies documentation and earlier results, not all newly requested measurements. - #4758 explains the conversion guide's earlier consolidation; the current provider contracts are now consolidated into `WotNodeSetConversion.md`. - #4839 supplies the reviewed API corrections; #4843 supplies the updated CTT issue record. - The original prose cleanup and SDK policy were user-requested without a source issue. No new runtime architecture is introduced by these documentation edits. ## 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. - [ ] I have added tests that prove my fix is effective or that my feature works and increased code coverage. - [x] I have added all necessary documentation. - [ ] 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. --------- Co-authored-by: Roman Ettlinger <romanett98@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
232 lines
7.1 KiB
Markdown
232 lines
7.1 KiB
Markdown
# Provisioning Mode
|
|
|
|
## Overview
|
|
|
|
Provisioning mode starts the server with a limited default namespace and the security settings described below. Administrators can provision certificates and configure the server before exposing application functionality.
|
|
|
|
## Contents
|
|
|
|
- [Overview](#overview)
|
|
- [Purpose](#purpose)
|
|
- [How to Enable Provisioning Mode](#how-to-enable-provisioning-mode)
|
|
- [ConsoleReferenceServer](#consolereferenceserver)
|
|
- [Command Line Options](#command-line-options)
|
|
- [Behavior in Provisioning Mode](#behavior-in-provisioning-mode)
|
|
- [1. Limited Namespace](#1-limited-namespace)
|
|
- [2. Authentication Requirements](#2-authentication-requirements)
|
|
- [3. Certificate Handling](#3-certificate-handling)
|
|
- [4. Reduced Attack Surface](#4-reduced-attack-surface)
|
|
- [Use Cases](#use-cases)
|
|
- [Initial Server Setup](#initial-server-setup)
|
|
- [Certificate Provisioning](#certificate-provisioning)
|
|
- [Secure Configuration](#secure-configuration)
|
|
- [Implementation Details](#implementation-details)
|
|
- [ReferenceServer Class](#referenceserver-class)
|
|
- [Programmatic Usage](#programmatic-usage)
|
|
- [Security Considerations](#security-considerations)
|
|
- [Benefits](#benefits)
|
|
- [Limitations](#limitations)
|
|
- [Best Practices](#best-practices)
|
|
- [Comparison with Normal Mode](#comparison-with-normal-mode)
|
|
- [Examples](#examples)
|
|
- [Start Server in Provisioning Mode](#start-server-in-provisioning-mode)
|
|
- [Expected Output](#expected-output)
|
|
- [Related Documentation](#related-documentation)
|
|
|
|
## Purpose
|
|
|
|
The provisioning mode addresses the need for secure server initialization by:
|
|
|
|
- Providing a minimal server environment during initial setup
|
|
- Requiring authenticated user access (anonymous access is disabled)
|
|
- Enabling automatic certificate acceptance to simplify certificate provisioning
|
|
- Preventing access to application-specific data and functionality until the server is properly configured
|
|
|
|
This mode is particularly useful when:
|
|
|
|
- Setting up a new OPC UA server installation
|
|
- Provisioning certificates for production environments
|
|
- Performing initial server configuration in a secure manner
|
|
|
|
## How to Enable Provisioning Mode
|
|
|
|
### ConsoleReferenceServer
|
|
|
|
The ConsoleReferenceServer application supports provisioning mode via the `--provision` command line option:
|
|
|
|
```bash
|
|
dotnet ConsoleReferenceServer.dll --provision
|
|
```
|
|
|
|
### Command Line Options
|
|
|
|
When using provisioning mode, you can combine it with other options:
|
|
|
|
```bash
|
|
# Enable provisioning mode with console logging
|
|
dotnet ConsoleReferenceServer.dll --provision --console --log
|
|
|
|
# Enable provisioning mode with timeout
|
|
dotnet ConsoleReferenceServer.dll --provision --timeout 300
|
|
```
|
|
|
|
Note: When provisioning mode is enabled, auto-accept for untrusted certificates is automatically activated. You don't need to specify the `--autoaccept` option separately.
|
|
|
|
## Behavior in Provisioning Mode
|
|
|
|
When the server starts in provisioning mode:
|
|
|
|
### 1. Limited Namespace
|
|
|
|
- Only the core OPC UA namespace is exposed
|
|
- Application-specific node managers are not loaded
|
|
- Standard OPC UA objects (Objects, Types, Views) remain accessible
|
|
- Custom server nodes and data are not available
|
|
|
|
### 2. Authentication Requirements
|
|
|
|
- Anonymous authentication is disabled
|
|
- Users must authenticate using:
|
|
- Username/password
|
|
- X.509 certificate
|
|
- Other supported authentication mechanisms
|
|
|
|
### 3. Certificate Handling
|
|
|
|
- Auto-accept for untrusted certificates is enabled
|
|
- Administrators can provision certificates without manual approval
|
|
- Certificate validation still occurs, but untrusted certificates are accepted
|
|
|
|
### 4. Reduced Attack Surface
|
|
|
|
- No application-specific functionality is exposed
|
|
- Minimal node managers are active
|
|
- Only core server capabilities are available
|
|
|
|
## Use Cases
|
|
|
|
### Initial Server Setup
|
|
|
|
1. Start the server in provisioning mode
|
|
2. Connect as an authenticated administrator
|
|
3. Provision required certificates
|
|
4. Configure server settings
|
|
5. Restart the server in normal mode
|
|
|
|
### Certificate Provisioning
|
|
|
|
1. Start the server with `--provision`
|
|
2. Use a GDS (Global Discovery Server) or certificate management tool
|
|
3. Push certificates to the server
|
|
4. Verify certificate installation
|
|
5. Exit provisioning mode
|
|
|
|
### Secure Configuration
|
|
|
|
1. Enable provisioning mode for configuration changes
|
|
2. Make necessary updates to server configuration
|
|
3. Test changes in the limited environment
|
|
4. Restart in production mode
|
|
|
|
## Implementation Details
|
|
|
|
### ReferenceServer Class
|
|
|
|
The provisioning mode is implemented in the `ReferenceServer` class:
|
|
|
|
```csharp
|
|
public bool ProvisioningMode { get; set; }
|
|
```
|
|
|
|
When `ProvisioningMode` is true:
|
|
|
|
- `CreateMasterNodeManager` skips loading application-specific node managers
|
|
- `GetUserTokenPolicies` removes anonymous authentication policies
|
|
|
|
### Programmatic Usage
|
|
|
|
To enable provisioning mode programmatically:
|
|
|
|
```csharp
|
|
var server = new ReferenceServer();
|
|
Quickstarts.Servers.Utils.EnableProvisioningMode(server);
|
|
```
|
|
|
|
Or directly:
|
|
|
|
```csharp
|
|
var server = new ReferenceServer
|
|
{
|
|
ProvisioningMode = true
|
|
};
|
|
```
|
|
|
|
## Security Considerations
|
|
|
|
### Benefits
|
|
|
|
- Reduces attack surface during initial setup
|
|
- Requires authenticated access for configuration
|
|
- Prevents unauthorized access to application data
|
|
|
|
### Limitations
|
|
|
|
- Auto-accept allows an untrusted certificate to pass the trust-list check
|
|
(`BadCertificateUntrusted`). It does not disable other certificate validation
|
|
or user authentication.
|
|
- Should only be used during controlled setup/configuration periods
|
|
- Not intended for long-term operation
|
|
|
|
### Best Practices
|
|
|
|
1. Use provisioning mode only during initial setup or maintenance windows
|
|
2. Ensure the server is not accessible from untrusted networks while in provisioning mode
|
|
3. Switch to normal mode as soon as provisioning is complete
|
|
4. Monitor and review all certificates that were auto-accepted
|
|
5. Remove or properly validate any questionable certificates before exiting provisioning mode
|
|
|
|
## Comparison with Normal Mode
|
|
|
|
| Feature | Normal Mode | Provisioning Mode |
|
|
|---------|-------------|-------------------|
|
|
| Namespace | Full application namespace | Core namespace only |
|
|
| Node Managers | All configured | Core managers only |
|
|
| Anonymous Access | Allowed (if configured) | Disabled |
|
|
| Auto-Accept Certificates | Optional | Enabled |
|
|
| Application Data | Accessible | Not available |
|
|
| Security Admin Access | Available | Required |
|
|
|
|
## Examples
|
|
|
|
### Start Server in Provisioning Mode
|
|
|
|
Windows:
|
|
|
|
```cmd
|
|
ConsoleReferenceServer.exe --provision --console --log
|
|
```
|
|
|
|
Linux/Mac:
|
|
|
|
```bash
|
|
dotnet ConsoleReferenceServer.dll --provision --console --log
|
|
```
|
|
|
|
### Expected Output
|
|
|
|
When provisioning mode is active, you should see log messages similar to:
|
|
|
|
```
|
|
[INF] Enabling provisioning mode.
|
|
[INF] Auto-accept enabled for provisioning mode.
|
|
[INF] Server is in provisioning mode - limited namespace enabled.
|
|
[INF] MasterNodeManager.Startup - NodeManagers=2
|
|
```
|
|
|
|
The `NodeManagers=2` indicates only the core node managers are loaded (CoreNodeManager and SystemNodeManager), confirming the limited namespace is in effect.
|
|
|
|
## Related Documentation
|
|
|
|
- [Certificates](Certificates.md) - Certificate management and storage
|
|
- [RoleBasedUserManagement](RoleBasedUserManagement.md) - User authentication and authorization
|