User accounts

open62541-all-security ships four hard-coded user accounts. Identical credentials to uanetstandard-test-suite's opcua-userpass and opcua-all-security servers — so test code can target either server with the same login config.

The four accounts

Plaintext passwords are deliberate — this is a test target, not a real authentication system.

How they're wired

In server.c:

static const UA_UsernamePasswordLogin logins[] = {
    {UA_STRING_STATIC("admin"),    UA_STRING_STATIC("admin123")},
    {UA_STRING_STATIC("operator"), UA_STRING_STATIC("operator123")},
    {UA_STRING_STATIC("viewer"),   UA_STRING_STATIC("viewer123")},
    {UA_STRING_STATIC("test"),     UA_STRING_STATIC("test")},
};

UA_AccessControl_default(
    config,
    /* allowAnonymous = */ true,
    &policyUri,
    sizeof(logins) / sizeof(logins[0]),
    logins);

Unlike uanetstandard-test-suite (which loads config/users.json), open62541's UA_AccessControl_default embeds the list directly. To change users:

1. Edit server.c in your fork.
2. docker compose build.
3. docker compose up -d --force-recreate.

There is no runtime config file.

Access control behaviour

open62541's UA_AccessControl_default provides a permissive default: all authenticated users can read and write all nodes. It does not enforce role-based per-node ACLs the way uanetstandard-test-suite's userpass server does.

Implications:

For role-based write rejection tests, use uanetstandard-test-suite's opcua-userpass (port 4841). This server is fine for "does username auth work at all" but not for "is the role check enforced".

Anonymous

allowAnonymous = true is set, so anonymous identity is also valid. Use cases:

• Connect to test plain None/None connectivity without credentials.
• Run NodeManagement-style tests where auth isn't the focus.

Anonymous users have the same permissions as authenticated under UA_AccessControl_default — no role differentiation.

Test patterns

Happy path

connect(opc.tcp://localhost:24841, policy=Basic256Sha256,
        mode=SignAndEncrypt, identity=UserName("admin", "admin123"))
→ Good

Repeat for the other three users — all succeed.

Wrong password

connect(..., identity=UserName("admin", "wrong"))
→ Bad_UserAccessDenied

Unknown user

connect(..., identity=UserName("alice", "anything"))
→ Bad_UserAccessDenied

open62541's UA_AccessControl_default returns Bad_UserAccessDenied for any credential mismatch. Bad_IdentityTokenRejected is reserved for the "wrong token type" case (e.g. sending Anonymous to a server that requires UserName).

Plain-text password over None

connect(opc.tcp://localhost:24841, policy=None, mode=None,
        identity=UserName("admin", "admin123"))
→ Good  (because allowNonePolicyPassword = true)

On a stricter server this combination fails — Bad_SecurityPolicyRejected or Bad_SecurityChecksFailed (the rejection happens at the transport layer because the password isn't encrypted with the server's public key). The permissive allowNonePolicyPassword = true posture lets it through here.

Compatibility with the main suite

Your test code can target either:

opc.tcp://localhost:24841                 # extra-test-suite (bare URL — no resource path)
opc.tcp://localhost:4841/UA/TestServer    # uanetstandard-test-suite userpass
opc.tcp://localhost:4843/UA/TestServer    # uanetstandard-test-suite all-security

Note that this suite's open62541 servers serve at the bare URL (no /UA/TestServer path) — see Ports and endpoints.

…with the same credentials. The wire interactions are identical for the username/password path. Differences:

The right server depends on what you're testing.

Where to read next

• Trust posture — the cert-validation context.
• Policies and modes — what combinations the server advertises.