Federating Identity with OCI

Most organisations already have an identity provider. It holds the accounts, enforces the password policy, runs the multi factor checks, and handles the process of adding people when they join and removing them when they leave. The last thing you want when you adopt OCI is a second, separate set of accounts that someone has to manage in parallel, because that is how former employees keep access they should have lost and how password policies quietly diverge. Federation solves this by letting your existing identity provider handle authentication for OCI, so you manage one set of identities and one set of controls. This guide explains how federation works on OCI and how to set it up so it strengthens your security rather than complicating it.

The core benefit is single source of truth for identity. When someone joins, they are added once, in your identity provider, and that grants them appropriate access to OCI along with everything else. When they leave, they are removed once, and that access disappears everywhere. The password policy, the multi factor requirement, and the account lifecycle are all governed in one place, which is both more secure and less work.

How federation works

Federation establishes a trust relationship between OCI and your identity provider. When a user tries to access OCI, they are redirected to your identity provider to authenticate. The provider verifies them, applies whatever controls you have configured there such as multi factor authentication, and then asserts back to OCI that this user is who they claim to be. OCI trusts that assertion because of the relationship you established, and grants access according to the groups and policies you have mapped. The user never has a separate OCI password, because OCI never handles their authentication directly.

This sits on top of the identity domains foundation covered in our identity domains guide. Identity domains are where federation is configured, and understanding them makes the federation setup much clearer. The two work together, the domain is the container and the federation is the trust relationship you set up within it.

What federation gives you

Mapping groups to access

The step that makes federation useful rather than just convenient is the mapping between groups in your identity provider and access in OCI. You define groups centrally, for example a group of cloud engineers and a group of read only auditors, and you map those groups to OCI groups that have policies attached. When someone is added to the engineers group in your identity provider, they automatically receive the engineer access in OCI, and when they are removed they lose it. This keeps the least privilege discipline from our IAM policies guide aligned with the access governance you already run, so the two never drift apart.

The discipline here is to keep the group structure clean and meaningful. Groups that map to real roles, with policies that grant only what that role needs, give you a system where access is easy to reason about. Groups that have accumulated random members and broad policies give you the opposite, so the federation setup is a good moment to review and tidy the access model rather than simply replicate an existing mess.

Setting it up well

That last point matters more than it first appears. If all access depends on the federation path and that path becomes unavailable, you can be locked out of your own environment at the worst possible moment. A small number of carefully controlled local emergency accounts, used only when federation is down and monitored closely, is the standard safeguard against that scenario.

Federation and zero trust

Federation is one of the most effective steps toward the zero trust model discussed in our zero trust guide, because zero trust depends on strong, consistent identity verification on every request. When your identity provider handles authentication, applies multi factor, and governs the account lifecycle in one place, every request into OCI starts from a verified identity governed by controls you trust. That is exactly the foundation zero trust is built on, which is why federation is usually the first thing we put in place when an estate is moving toward that model.

Bringing it together

Federation lets your existing identity provider handle authentication for OCI, so you manage one set of identities, one password policy, one multi factor requirement, and one joiner and leaver process. It removes the risk of orphaned accounts, keeps least privilege aligned with the access governance you already run, and lays the foundation for zero trust. Set it up with meaningful groups mapped to least privilege policies, enforce multi factor at the provider, test the lifecycle, and keep a small set of emergency accounts as a safeguard. The foundation is in our identity domains guide, the full model is in our complete security guide, and the broader picture is in our IAM and security solution.