Administration and access

Three separate access decisions

Signing in establishes an identity. Active organization and project memberships authorize operations. Source permissions determine which evidence and disclosure surfaces those operations may use. Passing one layer does not bypass the others.

The current Soldier Data login registry supports owner, analyst and viewer claims. The broader application capability matrix also contains admin and reviewer roles, but those are not extra role values to insert into the pilot login file. Use the generated role matrix below to understand application policy, not to infer that every optional administration screen is enabled.

Onboard a pilot user

1. Record the user’s purpose, required project, approved role and approving owner. Prefer the minimum access needed for the work.
2. Confirm which identity mode the deployed environment actually uses. The U4 pilot uses the controlled Soldier Data account boundary; OIDC/account administration is separately configured code, not evidence of a live enterprise identity service.
3. Have the authorized operator provision the account using the protected account-file schema and password-verifier procedure. Never ask for the password in chat or commit a verifier/account document into the application repository.
4. Apply approved organization and project membership through the environment’s supported administration procedure. Do not assume a login-file role creates a database membership. During a release account freeze, coordinate changes with the release operator.
5. Apply any required process restart through a reviewed release/change procedure: the login account registry is loaded at startup.
6. Have the user sign in themselves. Verify the intended project and evidence access, and verify that unrelated project evidence stays unavailable. Record the result and approval reference without storing session cookies.

Role and capability reference

The following selected actions are generated from the application’s ROLE_CAPABILITIES export. Both organization and project roles must allow the action where project scope is required. Source rights and runtime configuration can still refuse it.

Change or revoke access

1. Confirm the requester’s authority and identify the exact organization, project, subject and intended change. Keep a recoverable authorized owner.
2. For the pilot login registry, active=false prevents new authentication after the configured process is restarted; incrementing sessionVersion invalidates earlier cookies under the reloaded registry. Follow the controlled file-update and restart procedure.
3. Change authoritative organization/project membership separately where needed. The capability authorizer reads those memberships on every action; legacy login roles alone never grant project access.
4. Verify that an existing session and a fresh login behave as intended. Check both project evidence and artifact access. Do not share the revoked person’s password to perform this check.
5. Record who approved the change, what scope changed, when it became effective and how denial was verified.

Password, session and account support

Administration record and review cadence

Maintain an access-change record containing the requester, approving role, subject/project identifiers, change, effective time and verification outcome. Store sensitive operational details in the organization’s approved private system, not in the public documentation portal.

Review access when a person’s role changes or a project closes. Recheck source eligibility before new exports. No automatic access-review interval, enterprise audit retention term or service-level commitment is established by this guide.