Orchestration Engine 0.183.322

Orchestration Engine 0.183.321

Direct projectMember ID reads now require the row to be active and not
removed, matching the existing collection query. The project-access check
remains in place. A removed member is therefore not exposed to an authorized
reader who retained its old 1pm ID; an active member remains readable.

On Server v1.6.464, a disposable project's removed row was absent from the
member collection but GET /v1/projectMembers/1pm... and the corresponding
/v2-beta request returned 200. Focused manager tests first failed for
inactive and removed rows, then passed after the guard was added. Release
acceptance must repeat the remove-and-direct-read lifecycle on both API
versions with a disposable project and confirm 404, as well as active-row 200,
foreign-project 404, and restoration of QA fixtures.

This patch changes no OIDC mapping, project role, membership write, schema, or
database table. No migration is required. Rollback to Engine 0.183.320 is
technically possible but restores the stale-member read defect; restrict
access and assess retained member IDs before doing so.

Orchestration Engine 0.183.320

Project-member collection access checks the requested project against the token policy before loading members.

Before this patch, a token authorized for project A could send
X-API-Project-Id: A with GET /v1/projectMembers?projectId=B or
GET /v2-beta/projectMembers?projectId=B. The authenticator selected A, but
the custom collection resource manager loaded B's members without checking
access to B. A token with no access to B must now receive 404 before any B
membership is loaded. Direct member-ID access retains its existing project
check. A malformed project ID also returns 404 without a database member read.

The change is intentionally limited to the custom projectMember resource
manager. It does not change project roles, OIDC identity mapping, generic
resource authorization, or membership writes. Focused tests cover the foreign
collection, authorized collection, malformed ID, and direct-ID allow/deny
paths. The Server consuming this release must also run v1/v2 API and browser
role matrices against a disposable project, including an authorized header
with a different unauthorized query project, before deployment.

Rollback: restore the prior immutable Server image containing Engine
0.183.319 only if the authorization regression is understood; that version
does not contain this collection-read protection. No database migration is
required for this patch.

Orchestration Engine 0.183.319

This patch makes shared Default membership reconciliation atomic. The Engine
rechecks all authenticated direct and group identities and, only when none has
an active project membership, creates the stable account membership while
holding the existing project lock. A concurrent administrator update therefore
cannot be weakened by a later baseline member grant.

The release preserves the explicit shared, personal, and none provisioning
modes and the legacy project.create.default=false switch. Invalid modes fail
closed. A deterministic barrier test repeats the conflicting update order 100
times and verifies that no duplicate or role-escalating membership appears.

The runtime matrix must prove owner, member, restricted, read-only, and
no-access behavior with two accounts per role, direct-user and group
membership, exact collection sets, and direct-ID create/read/update/delete
checks on both v1 and v2 API surfaces before a consuming Server release is
published.

Orchestration Engine 0.183.318

• Restore restricted OpenID Connect login for an existing active account
  whose project membership is stored against its stable rancher_id, including
  membership in the shared Default environment.
• Resolve the external identity to the exact account before introducing any
  stable account identity into the authorization decision.
• Keep required mode explicit allow-list only. Stable project membership is
  never supplied to that check and cannot become an allow-list bypass.
• Keep inactive and unknown accounts fail-closed and preserve all existing
  direct and group roles, including noaccess.

The focused auth-logic tests cover identity-link account resolution, the
restricted stable-membership path, and the required-mode bypass boundary.
The runtime matrix must prove owner, member, restricted, read-only, and
no-access behavior through both v1 and v2 APIs, exact stack visibility, denied
direct UI routes, and six independent OpenID Connect browser sessions before a
Server release consumes this Engine.

Orchestration Engine 0.183.317

• Reconcile eligible local and external accounts into the single shared
  Default environment identified by the stable adminProject UUID.
• Use the stable internal account identity for the baseline member entry so
  provider claim formatting cannot create duplicate environment membership.
• Preserve every existing direct or group role, including noaccess; shared
  provisioning never replaces an explicit authorization decision.
• Serialize exact membership creation with the existing project lock and make
  repeated or concurrent login reconciliation idempotent.
• Keep existing personal environments and workloads intact. Accounts created
  by an older release adopt the shared Default on their next successful login.
• Retain configurable personal and none provisioning modes for compatible
  deployments.

The focused auth-logic tests cover baseline creation, group-role preservation,
direct no-access preservation, and a missing shared project that fails closed.
The runtime matrix must prove owner, member, restricted, read-only, and
no-access behavior through both v1 and v2 APIs, exact stack visibility, denied
direct UI routes, and six independent OpenID Connect browser sessions before a
Server release consumes this Engine.

Orchestration Engine 0.183.316

• Preserve local-administrator recovery while an external OpenID Connect
  provider uses required site access.
• Recognize only the server-encrypted local-auth payload issued by the existing
  recovery flow, whose final durable token remains bound to the active provider.
• Recheck at request time that platform security and local recovery remain
  enabled and that the stable principal is still an active administrator.
• Keep normal OpenID Connect sessions on the unchanged required allow-list;
  non-administrators, inactive accounts, malformed payloads, and disabled
  recovery continue to fail closed.

The auth reactor regression suite verifies both sides of the boundary: the
completed local password plus MFA recovery session remains usable, while
ordinary external identities still require the configured OIDC user or group.

Runtime acceptance must switch between restricted, required-group, and
required-user policies without locking out the local recovery administrator,
then prove each temporary account's site and environment permissions.

Orchestration Engine 0.183.315

• Persist internal authentication credentials for the explicitly selected
  account and verify ownership after creation, instead of trusting request
  context defaults during unauthenticated OIDC login.
• Exclude built-in and service accounts from login-identity resolution; only
  active user and administrator accounts may own a login identity.
• Repair an existing authIdentity link owned by the built-in token account
  only when the provider, external identity type, external ID, link digest, and
  target account's external identity all match.
• Keep valid cross-account links fail-closed with IdentityAlreadyLinked and
  retain the explicit reassignment workflow for every intentional move.
• Apply the same explicit ownership check to identity-proof use records and
  provider-switch tickets, the two adjacent internal credential creation paths.

The focused regression suite reproduces the transient token-account overwrite,
proves exact legacy repair, and rejects both a mismatched target identity and a
link already owned by another login account.

Repeated-login acceptance must prove that every session resolves to the
same user account and retains its site and environment permissions.

Orchestration Engine 0.183.314

• Keep the frozen v1 projectMember.externalIdType options aligned with the
  reviewed core schema so oidc_user and oidc_group survive v1 environment
  and membership creation after an upgrade.
• Preserve every historical provider option already present in the v1 schema
  and de-duplicate the resulting list in stable order.
• Limit compatibility enrichment to projectMember.externalIdType; unrelated
  frozen schemas and enum fields remain unchanged.
• Preserve the runtime identity boundary from 0.183.312 and account activation
  ordering from 0.183.313. Unknown external identity types remain rejected.

The regression test proves both the reviewed option union and the
unrelated-schema boundary. Runtime acceptance creates fresh OpenID Connect
users, provisions v1 project members, compares v1 and v2 schema options, and
then verifies environment visibility and role-specific operations.

Orchestration Engine 0.183.313

• Complete a newly provisioned external account's account.create lifecycle
  synchronously before the token flow enters MFA.
• Prevent a successful OpenID Connect exchange from passing a transient
  registering account into the MFA active-account gate.
• Keep the MFA safety boundary intact: every non-active account is still
  rejected, existing-account login is unchanged, and no provider or identity
  validation is relaxed.
• Preserve the validated oidc_user and oidc_group boundary and the
  Engine-owned stable rancher_id contract from 0.183.312.

The regression test proves that external account creation executes the
synchronous resource lifecycle and never uses the background scheduling path.
Runtime acceptance uses fresh Authentik users so every tested login exercises
new-account provisioning, OIDC, MFA, account activation, and session issuance
in their real order.