Four Thousand Federated Users and Three Hundred Accidental Admins
An insurer federates 4,000 employees from Microsoft Entra ID into a single OCI Identity Domain using SAML 2.0. The group mapping was configured during a 2021 proof of concept: every member of the Entra group All-OCI-Users maps to the OCI group Tenancy-Admins, because the original team could not get finer-grained policies approved in time. The tenancy has nine compartments spanning development, test, and production. Forty batch jobs authenticate to OCI Object Storage and Autonomous Database using user API keys whose credentials sit in plaintext configuration files on Azure VMs; the oldest key is 27 months old. Three contractor firms need console access for eight-week engagements. An internal audit found no documented break-glass procedure, no quarterly access review, and no evidence that MFA is enforced before OCI console access. The security team wants Entra ID Conditional Access to be the single control plane for authentication, and wants production access granted only for the duration of an incident or change.
1. Design the group and policy mapping. Why is SAML federation alone insufficient, and where does SCIM fit?
Read the worked answer
SAML solves authentication and coarse authorization at the moment of sign-in. It does not solve lifecycle. A SAML assertion carries whatever attributes the IdP puts in it at login time; if someone is removed from an Entra group at 10:00, their existing OCI session keeps working, and if they are removed from the company entirely, nothing in OCI deprovisions their identity-domain user. That is the mechanism that produced 300 tenancy admins.
Target design:
- Replace All-OCI-Users -> Tenancy-Admins with a role model: one Entra group per OCI role per environment, for example oci-prod-dba, oci-prod-readonly, oci-dev-developer. Map each to a same-named OCI group in the identity domain.
- Write policies at compartment scope referencing those groups, not tenancy scope. Example: Allow group oci-prod-dba to manage database-family in compartment prod. Read-only groups get inspect/read, not manage.
- Keep Tenancy-Admins for a named group of no more than a handful of people, and alert on every membership change.
- Enable SCIM provisioning from Entra ID into the identity domain so user creation, group membership, deactivation, and leavers all flow automatically. SCIM is the lifecycle channel; SAML is the login channel. Both are required.
Two practical traps: nested Entra groups are not expanded into OCI group membership by default, so assert only direct members; and SCIM propagation is not instantaneous, so document the expected delay in the joiner/mover/leaver runbook rather than telling auditors it is immediate.
2. How do you eliminate the forty plaintext API keys without breaking the batch jobs?
Read the worked answer
Start by being precise about the constraint: instance principals and resource principals are OCI constructs that bind an OCI compute instance or OCI Functions function to a dynamic group. An Azure VM cannot present an OCI instance principal, so 'just use instance principals' is not a complete answer while the jobs stay on Azure.
Three paths, in order of preference:
- Move the jobs to OCI. Run them on OCI Container Instances, OCI Functions, or compute in a dedicated compartment, and authorize through a dynamic group with a matching rule on compartment OCID plus a defined tag. The secret disappears entirely, which is the only real fix. This is the recommended path for anything that touches production data.
- Confidential application with OAuth 2.0 client credentials. Register an OCI IAM confidential application in the identity domain, scope it to the minimum APIs, and store the client secret in Azure Key Vault with automatic rotation on a 90-day schedule and a managed identity for retrieval. This is a real improvement over static user keys, but the secret still exists.
- Keep it and lie to yourself - not recommended.
For either path, do the work in this order: inventory what each key can actually reach, create the new principal and policy, run the job in parallel against a test bucket, cut over, then delete the old key. Never delete keys first. Retire user API keys for human accounts entirely and forbid them by policy; humans should use console sessions or short-lived CLI tokens obtained through federation.
3. Contractors and break-glass: what controls do you put around each, and what are the limits of relying on Entra ID?
Read the worked answer
Contractors: one Entra group per firm, membership granted through a time-bound access package with an approver and an automatic expiry at day 56, SCIM-provisioned into an OCI contractor group scoped to development and test compartments only. No contractor group should have any policy granting manage rights in production. Log every approval so the quarterly review has evidence rather than recollection.
Break-glass: two local identity-domain users, excluded from federation, credentials split and sealed, hardware MFA tokens stored separately, and a documented activation procedure that requires a second person. Create a detection rule that fires on any sign-in by those accounts, and test them once a quarter during a maintenance window - an untested break-glass account is a liability, not a control.
Limits of Entra ID you must state plainly:
- Conditional Access is evaluated at Entra sign-in. It cannot revoke an OCI session that is already open. Set the identity-domain session lifetime and sign-out behaviour to bound the exposure, and know that disabling an Entra account takes effect in OCI only after the session and SCIM delay expire.
- Entra ID Privileged Identity Management activation is not evaluated by OCI IAM. OCI sees group membership, so JIT works only if the group membership itself is time-bound and SCIM keeps up.
- If Entra is unavailable, federated sign-in fails for everyone, including administrators. That is precisely why the two local break-glass accounts exist, and why they must never be federated.