Identity Domains: SAML/OIDC federation setup notes

Problem

Most teams already have an identity provider such as Entra ID (formerly Azure AD) or Okta, and nobody wants a second set of passwords for the cloud console. Federation solves that, but a careless setup can lock out administrators or leave group membership drifting away from what the IdP says.

I wanted a repeatable order of operations that keeps a way back in at every step.

Options and trade-offs

• Console setup: straightforward and visible, and it needs careful mapping and testing.
• API or automation: repeatable, but there are more moving parts to get wrong the first time.
• Default sign-on and IdP policies versus custom rules: the defaults are a fine start, but confirm what they do to administrators before you rely on them.

My recommendation

Use the Identity Domains flow with a SAML identity provider. Exchange metadata, decide which assertion attribute identifies the user, map IdP groups to IAM groups, and test with a staged non-admin account before an administrator. Change federation and MFA separately so a problem can be traced to one change.

Worked example

The sequence I follow in the Console. It is a checklist, not a script, because the exact screens differ a little between tenancies.

1. Keep a local break-glass admin that does NOT use the new IdP.
2. Identity Domains > Security > Identity providers > Add SAML IdP.
   - Upload the IdP metadata XML (or enter the endpoints and signing cert).
   - Choose the attribute that carries the username (NameID or email).
3. Export the domain's service provider metadata and import it into the IdP.
4. Map IdP groups to IAM groups (group mapping / JIT provisioning).
5. Add the IdP to an identity provider policy rule and activate it.
6. Test: non-admin user first, then an admin. Confirm group-based access.
7. Record the metadata expiry date and who owns the mapping table.

For Entra ID the pattern is the same. You create an enterprise application, upload the service provider metadata, download the federation metadata XML and import it into the domain. OIDC-based identity providers follow the same ideas, with a client ID and secret in place of metadata files.

Checklist

1. Keep a break-glass local administrator outside federation.
2. Document the group mappings and name an owner for each.
3. Test a non-admin sign-in before you test an admin sign-in.
4. Watch for attribute mismatches, and fix the mapping instead of widening a policy.
5. Track the IdP signing certificate expiry and the metadata refresh process.
6. Do not change federation and MFA policy in the same maintenance window.

Where this doesn't apply

A very small tenancy with no external IdP is better off with local users and a strong sign-on policy. Federation adds value when there is already an identity source to follow.

One honest limitation

An expired or rotated IdP certificate can break sign-in without warning. I keep a calendar entry for it and a short, written refresh procedure.

Sources

• OCI Documentation: Federating with Identity Domains (SAML identity providers)
• OCI Documentation: Identity Provider Policies in Identity Domains
• OCI Documentation: Manually Federating Your Tenancy