Extend the RoleManagement sample to the Part 18 items #836 recommends

[romanett]

Proposed changes

Issue #836 is a menu of nine self-contained increments to Workshop/RoleManagement, written
down after #828 landed so that the gaps were a choice on record. This takes the four its own
Suggested order names — 5 (AccessRestrictions), 7 (auditing), 2 (endpoint-filtered
Role and CustomConfiguration) and 1 limited to Thumbprint / X509Subject — and gives
each of them a demonstration in the sample client and a fixture in the tests. Items 3 (the
§5 user management model, which wants its own sample) and 9 (a vendor-defined Role, blocked
on OPCFoundation/UA-.NETStandard#4361) stay open, as the issue asks.

AccessRestrictions — the half of the access story the sample was missing

Calibration carries EncryptionRequired, MaintenanceNote adds ApplyRestrictionsToBrowse.
An Engineer who holds Browse, Read and Write on both is refused with
BadSecurityModeInsufficient on the unsecured endpoint, and the distinction is the point:
BadUserAccessDenied means sign in as somebody else, BadSecurityModeInsufficient means
reconnect with security. The client shows the attribute in a new column.

An endpoint filter, and the flag that goes with it

ConfigureAdmin is restricted to the encrypted endpoints, which Part 18 §4.4.1 evaluates
before any identity rule. Its CustomConfiguration flag is deliberately left false and the
client's new Toggle CustomConfiguration button flips it — that flag is the only thing which
lets a Role with an empty Identities list be granted at all.

A Role earned by a certificate rather than by an account

ConfigureAdmin is granted by an X509Subject rule naming the certificate the sample client
creates for itself, so an anonymous Session from that client holds a Role no account can
earn. One new node, ServiceCode, is there to observe it. The client's identity criteria
drop-down adds Thumbprint and X509Subject beside UserName and fills the box with what it
would present.

Auditing

The server sets AuditingEnabled and the client subscribes to AuditEventType on the Server
object — see the caveat below.

Three things the stack does differently from what the issue assumed

All measured against 2.0.0-preview.4, and all recorded in the README and in code comments so
the next reader does not have to rediscover them:

1. Thumbprint and X509Subject match the client's application instance certificate, not
   a user certificate — SessionManager passes session.ClientCertificate to
   ResolveGrantedRoles. So no X509 user token policy is needed, and such a Role belongs to the
   workstation: every Session it opens holds it, signed in or not. The issue assumed the other
   reading, which is why it estimated this item as needing a user certificate.
2. IRoleManager.AddEndpoint refuses an entry whose EndpointUrl is empty, although
   EndpointTypeComparer.Matches treats a default-valued field as a wildcard per §4.4.2 — so
   { SecurityMode = SignAndEncrypt } cannot be stored. The server copies the endpoint
   descriptions it actually advertises instead, which is why that part of the Role configuration
   runs in OnServerStarted rather than in CreateRoleManager. Filed upstream as
   IRoleManager.AddEndpoint refuses the wildcard endpoint filter that EndpointTypeComparer is written to match UA-.NETStandard#4412.
3. No audit event of any type reaches a subscriber in 2.0.0-preview.4. Server.Auditing
   reads true, AddIdentity answers Good, and a GeneralModelChangeEvent from the same
   Server object arrives on the same subscription — audit events do not. Reproduced on
   RoleManagement and on NodeManagement, with nothing logged server-side. The tier 1.5
   fixture is therefore written the right way round and wrapped in KnownIssueAsync, so it
   turns into a failure asking for the note to be removed the moment the stack delivers them.
   A separate investigation into the root cause is under way; if it turns out to be sample
   misconfiguration rather than a stack defect, that note and the matching README paragraph
   are what have to change.

A smaller one, also in the README: ApplyRestrictionsToBrowse covers a Browse of the restricted
node itself and a TranslateBrowsePathsToNodeIds starting there, but not the reference to it in
its parent's browse result — that per-reference filter applies role permissions only.

Related Issues

• Fixes Role management sample: Part 18 functionality not yet demonstrated #836 (items 1, 2, 5 and 7; items 3 and 9 stay open on purpose)
• Reported upstream: IRoleManager.AddEndpoint refuses the wildcard endpoint filter that EndpointTypeComparer is written to match UA-.NETStandard#4412
• Item 9 remains blocked on [Server] Part 18 RoleSet: AddRole can overwrite an existing node, and Roles configured at startup never get one UA-.NETStandard#4361

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds functionality)
• Test enhancement (non-breaking change to increase test coverage)
• Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
• Documentation Update (if none of the other choices apply)

Checklist

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

Further comments

Why the demonstrations are laid out the way they are

Each feature is observed through a Role and a node which the other features do not touch, so a
failing assertion names one cause. MaintenanceNote and Calibration are observed through
Roles which are not endpoint-filtered; ServiceCode, which the endpoint-filtered Role owns,
carries no AccessRestrictions of its own. Without that separation a refusal on the unsecured
endpoint would be over-determined and the fixtures would stop teaching anything.

Test results

Run locally on Windows against 2.0.0-preview.4:

• tier 1 Tests/SampleServers.Tests — 115 passed
• tier 1.5 Tests/SampleNodeManagers.Tests — 164 passed, 4 skipped (one of them the recorded
  audit known issue; the other three pre-date this change)
• tier 2 Tests/SampleClients.Tests — 63 passed

Two of the tier 2 fixtures are new. TheCertificateOfThisClientEarnsTheServiceCode is the one
worth knowing about: it holds the server's hard-coded X509Subject criteria to the certificate
the client's own configuration file actually produces, so it fails if either is edited without
the other.

Shared test helper

TestClient gains an application certificate subject and thumbprint, and a connect overload
which takes a certificate subject, so a test can assert what a server matched a client by. Two
clients built with the same subject still differ by thumbprint, which is exactly the contrast
between the two criteria.

🤖 Generated with Claude Code