Identity quietly determines whether the rest of an OCI architecture is secure. Identity domains organise authentication and authorisation, and getting their architecture right is foundational to a secure estate.
Identity is the part of an OCI architecture that quietly determines whether the rest of it is secure. You can design the networks, the compartments and the availability beautifully, but if anyone can authenticate as anyone and access anything, none of that structure protects you. Identity domains are the construct OCI uses to organise authentication and authorisation, and getting their architecture right is foundational to a secure estate. This article explains what identity domains are, how they fit the wider design, and how to structure them well.
An identity domain is a self contained set of users, groups and the policies that govern them, along with the configuration for how those users authenticate. Treating identity as an architectural concern rather than an afterthought is one of the marks of a mature OCI design, because identity is where most real world security incidents begin, in credentials that should not have existed or permissions that were broader than the work required. The sections below explain how identity domains work and how to structure them, building on the foundations in OCI Landing Zone and Architecture: A Complete Guide and connecting to the broader discipline in Security by Design on OCI.
An identity domain holds the users who can authenticate, the groups that organise them, and the settings that govern how authentication happens, including multi factor requirements and federation with external identity providers. It is the boundary within which identity is managed, and a tenancy can have more than one, which allows you to separate identity concerns where that separation is useful, for example keeping the identities for one part of the organisation distinct from another. Understanding the identity domain as a container for identity, with its own configuration, is the starting point for designing how many you need and how they relate.
| Element | Role in the identity architecture |
|---|---|
| Users | The individual identities that authenticate to the estate |
| Groups | Collections of users that policies are written against |
| Policies | Statements granting groups access to resources in compartments |
| Federation | Trust with an external identity provider for single sign on |
| MFA settings | Requirements for a second authentication factor |
The single most important principle in identity architecture is that access is granted to groups, never to individuals directly, and policies are written against those groups. This matters because it keeps access manageable as people join, move and leave, since changing someone's access becomes a matter of changing their group membership rather than hunting through scattered individual grants. An estate where policies reference groups, and group membership reflects roles, stays comprehensible as it grows, while one where access was granted ad hoc to individuals becomes an unauditable tangle that no one fully understands. This group based approach is the foundation that makes the compartment structure in Compartment Strategy for OCI enforceable.
Most organisations already have an identity provider where employee identities live, and the right architecture federates the identity domain with that provider rather than creating a second, separate set of credentials. Federation means people authenticate with their existing corporate identity, which is better for security, because there is one identity lifecycle to manage rather than two, and better for users, who do not need another password. It also means that when someone leaves the organisation and their corporate identity is disabled, their access to OCI goes with it, closing the gap that separate credentials would leave open. Designing federation in from the start is far easier than retrofitting it after a separate set of identities has accumulated.
The question of how many identity domains to use is an architectural decision that depends on how much you need to separate identity concerns. A single domain is simplest and is right for many organisations, where one set of identities and policies governs the whole estate. Multiple domains make sense where there is a genuine need to keep identity populations or policies separate, for example a strict boundary between business units, or between an internal estate and one that external parties access. The trade off is that more domains mean more to manage, so the right number is the smallest that meets the genuine separation requirements, not the largest that might theoretically be useful.
An identity architecture should grant each group the access its members need to do their work and nothing more, which is the principle of least privilege. Broad grants are convenient, because they avoid the friction of asking for access, but they are exactly how a single compromised credential becomes an estate wide incident, since the compromised identity inherits all the access it was over generously given. Designing policies that grant narrowly, and resisting the pressure to widen them for convenience, is much of what makes an identity architecture genuinely protective rather than merely present. This is the same discipline that runs through Security by Design on OCI, applied specifically to who can do what.
Access tends to accumulate, because people gain it as their roles change but rarely lose it when they no longer need it, so an identity architecture needs a regular review that confirms access still matches need. This is far easier in an estate built on groups and policies, because reviewing access is a matter of reviewing group memberships and the policies written against them, rather than trying to reconstruct who can do what from scattered individual grants. Building access review into the operating rhythm, rather than treating it as a one off, is what keeps the identity architecture from quietly drifting into the over privileged tangle that every long lived estate is at risk of becoming.
It is worth stepping back to see why identity architecture matters so much, which is that every other control in the estate depends on it. Compartment boundaries only protect you if identity controls who can cross them, network segmentation only helps if identity governs who can change it, and even the best availability design is undermined if an attacker with stolen broad credentials can simply delete the redundancy. Identity is the layer that the rest of the architecture rests on, which is why designing it deliberately, rather than letting it accrete, is one of the most consequential decisions in the whole estate.
Designing identity domains, federation and policy structure is part of our IAM and Security practice, and we treat it as foundational in the broader OCI Security and Compliance work. The aim is an estate where access is granted to groups, mapped to roles, federated with your existing identity provider, and kept matched to need through regular review, so that identity strengthens the rest of the architecture rather than quietly undermining it.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.