Federated Sign-In Works, Authorization Does Not

Authentication and authorization are separate planes. SAML proves who the user is; it does not create OCI group memberships. Policies in OCI are evaluated against OCI group membership - direct membership for IAM users, and mapped or provisioned membership for federated users. Northwind built the first half and not the second, which is why 40 local IAM users (with real group memberships) work and 2,400 federated users do not.

Fixes, in order:

1. Repair SCIM. Users stuck in 'pending' normally means the provisioning job cannot authenticate or cannot match objects: an expired SCIM bearer token on the identity domain, the Entra app scoped to 'assigned users only' with no assignments, or an attribute mapping that fails the required user-name uniqueness check because the UPN collides with existing entries.
2. Provision groups, not just users. Map the Entra groups that already express business roles to OCI groups in the prod identity domain, then write policies against those OCI groups. Do not write policies against any-user or against individual users.
3. Verify the assertion path. If SCIM is unreliable, the SAML assertion must carry group claims and the identity domain must be configured to map them. Pick one mechanism, not both, and document it, because conflicting sources of membership produce access that silently changes.
4. Re-check the policies themselves. A policy in a compartment the federated group cannot see, or a policy that grants tenancy-level verbs but not the compartment-level inspect, produces the same 'empty tenancy' experience.

Why not dynamic groups: dynamic groups are matching rules over resource principals (compute instances, functions, and similar) and are used to let workloads call OCI APIs without keys. They are not a mechanism for granting human federated users access, and building a user-access model on them is a category error that passes review and fails audit.

The target property is that no credential exists long enough to be committed to a variable group.

OCI-hosted workloads. Move them to instance principals: a dynamic group whose matching rule scopes to the instance compartment, and policies granting only the specific verbs and resources the workload needs. No key material is stored at all, and rotating compute replaces the identity. For OCI Functions and OKE workloads, use resource principals and workload identity respectively so the pod or function gets its own short-lived principal rather than inheriting the node's.

Azure-hosted build and runtime workloads. Three viable patterns, in order of preference:

1. Run the OCI-touching step where OCI can issue a credential. An OCI DevOps build pipeline or an OCI compute runner using instance principals removes the cross-cloud secret entirely.
2. If the tenant supports workload identity federation, federate the external OIDC issuer to the OCI identity domain and exchange a short-lived workload token for OCI API access. This is the cleanest answer when available; confirm availability in the tenancy before designing around it.
3. If neither is possible, isolate the remaining key: store it in Azure Key Vault (not a DevOps variable group), retrieve it at run time with the pipeline's managed identity, scope the OCI policy to a narrow compartment, rotate on a schedule with overlap, and alarm on any use outside the pipeline's expected source IPs and times.

Regardless of pattern, retire the old keys in a defined order: create the new principal, dual-run, verify from logs that the old key is silent, disable for seven days, then delete. Deleting on day one causes an outage and destroys the audit trail. Tag every service account with owner, purpose, and expiry so the next audit does not rediscover 60 unknown principals.

Sharing a database superuser password through one secret makes every administrative action unattributable and turns one Vault policy mistake into total database compromise.

Target state:

• Eliminate shared superuser use. Provision named database accounts per administrator with the minimum role required, and separate human administration from application access. Application connection pools should use a least-privilege schema account, never SYS.
• Split the secret. One secret per credential, in a compartment whose policy grants read only to the group that actually needs that specific credential, with the Vault key in a separate compartment so key administration and secret retrieval are different privileges.
• Use secret bundles and versioning so rotation does not require a coordinated outage, and enable rotation with an overlap window so both old and new credentials are valid briefly.
• Make retrieval attributable. Vault audit logs record who read which secret version and when; route them to the tenancy audit stream and alert on reads outside the normal deployment windows or by identities outside the expected group. That log becomes the evidence audit is asking for.
• For cloud-native administrative access, prefer federated human identity plus short-lived sessions over stored credentials wherever the service supports it, so the credential never exists as a secret at all.

Break-glass:

• Keep two local IAM users in a dedicated identity domain that is not federated, with hardware MFA, credentials sealed offline, and a policy limited to tenancy administration recovery.
• Alarm on every sign-in by those users; the alarm is the control, not the existence of the user.
• Test the path quarterly: an untested break-glass account is usually found to be locked out or mis-scoped during the real incident.
• Break-glass must not grant database superuser access by itself; it restores identity, and normal named-account provisioning then does the rest.