7.2 OCI IAM Identity Domains & Identity Constructs

7.2 OCI IAM Identity Domains & Identity Constructs

[!NOTE] Foundations Blueprint Focus: Identity and Access Management (IAM) provides the foundational security boundary for everything deployed in Oracle Cloud Infrastructure. For the 1Z0-1085-26 exam, you must master the modern Identity Domains architecture, understand the distinct purposes of Users, Groups, and Dynamic Groups, comprehend how Instance Principals eliminate hardcoded credentials, and know how enterprise federation (SAML 2.0/SCIM) enables Single Sign-On.

In cloud environments, traditional perimeter security models (such as corporate firewalls and VPNs) are insufficient on their own. Identity is the modern cloud security perimeter. In Oracle Cloud Infrastructure, Identity and Access Management (IAM) governs authentication (verifying who an entity is) and authorization (verifying what permissions that entity possesses across tenancies, compartments, and resources).

Modern OCI IAM is built on Identity Domains, a unified identity-as-a-service (IDaaS) platform that merges cloud infrastructure access governance with comprehensive consumer and enterprise identity lifecycle management.

---

Unified Modern Architecture: OCI IAM with Identity Domains

Historically, Oracle Cloud Infrastructure utilized two distinct identity frameworks: legacy OCI IAM (which managed tenancy compartments and cloud policies) and Oracle Identity Cloud Service (IDCS, which managed enterprise federation, SSO, and application access). Oracle unified these architectures into OCI IAM with Identity Domains.

An Identity Domain is a self-contained container for managing users, groups, dynamic groups, credentials, authentication policies, and single sign-on integrations:

• The Default Identity Domain: Every new OCI tenancy is automatically provisioned with a Default domain. This domain serves as the primary root container for cloud administrators and daily operations.
• Multiple Identity Domains: Organizations can create multiple independent identity domains within a single OCI tenancy. This enables clean organizational partitioning—for example, maintaining one domain for internal corporate employees, a separate domain for external contractors, and another for consumer-facing digital applications.
• Identity Domain Types & Tiers:
  • Free / Default Tier: Included with every OCI tenancy at no cost. Its published object limits are 2,000 users and 250 groups, and it includes basic Multi-Factor Authentication (MFA) via the Oracle Mobile Authenticator app and FIDO2/WebAuthn hardware keys, dynamic groups, and standard IAM policy evaluation.
  • Premium & Enterprise Tiers: Available for organizations requiring advanced identity governance. These paid tiers unlock adaptive risk-based authentication (evaluating user geolocation and impossible travel anomalies), automated hybrid directory synchronization (Active Directory Bridge), third-party SMS/email MFA, and self-service password reset workflows.

---

Core IAM Principals: The Building Blocks of Identity

In OCI IAM, a Principal is an authenticated actor that can request operations against OCI resources. Principals fall into three primary constructs: Users, Groups, and Dynamic Groups.

+-------------------------------------------------------------------------+
|                        OCI IAM CORE PRINCIPALS                          |
+-------------------+-----------------------------+-----------------------+
|       USERS       |            GROUPS           |     DYNAMIC GROUPS    |
+-------------------+-----------------------------+-----------------------+
| • Human operators | • Collections of IAM users  | • Collections of OCI  |
| • Machine service | • Policies attach to Groups |   compute instances   |
|   accounts        | • Users inherit permissions | • Defined by matching |
| • Hold credentials|   from all assigned groups  |   rules               |
|   (keys, tokens)  | • Cannot nest groups        | • Instance Principals |
+-------------------+-----------------------------+-----------------------+

1. Users

A User is an individual identity defined within an identity domain. Users can represent human personnel (such as database administrators, network engineers, and security auditors) or non-human service accounts:

• Authentication Credentials: Depending on their operational role, users utilize different credentials:
  • Console Passwords: Used by human operators to log into the web-based OCI Console.
  • API Signing Key Pairs: 2048-bit RSA public/private key pairs used to cryptographically sign REST API requests, OCI CLI commands, Terraform/OpenTofu scripts, and OCI Software Development Kit (SDK) calls.
  • Auth Tokens: Oracle-generated strings used to authenticate with third-party tools that do not support OCI RSA signatures, such as the OCI Container Registry (via Docker login) and Amazon S3-compatible Object Storage APIs.
  • OAuth 2.0 Client Credentials: Used by automated integration workflows and API gateways.
  • SMTP Credentials: Used by instances and applications to send transactional emails via the OCI Email Delivery service.

2. Groups

A Group is a collection of IAM users who require identical access rights.

• The Cardinal Rule of OCI IAM: In OCI, policies can never be written directly for individual users. Policies grant permissions exclusively to groups. Users inherit permissions solely by being assigned to one or more groups.
• Multi-Group Membership: A user can belong to multiple groups simultaneously. In this scenario, the user inherits the union of all permissions granted across each group.
• Flat Group Hierarchy: OCI IAM does not support nested groups (a group cannot contain another group).

3. Dynamic Groups & Instance Principals

A Dynamic Group is a specialized IAM construct where the members are not human users, but rather OCI compute instances or cloud resources.

• Membership Matching Rules: Membership is not configured manually by adding user accounts. Instead, administrators write declarative matching rules. Whenever a compute instance matches the rule conditions, it automatically becomes an active member of the dynamic group.
• Matching Rule Syntax: Rules can use ANY (logical OR) or ALL (logical AND) operators to match resource attributes:
  • Matching by Compartment OCID: ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaaxample'}
  • Matching by Resource Tag: ALL {tag.Operations.Environment.value = 'Production'}
  • Matching a Specific Instance: ANY {instance.id = 'ocid1.instance.oc1.iad.aaaaaaaaxample'}

Instance Principals: Eliminating Credential Leakage

In traditional cloud architectures, if a software script on a virtual machine needs to upload nightly database backups to Object Storage, developers often create a service user, generate an RSA private key, and embed that private key into a local configuration file on the server. If that server is compromised or its backup image is exposed, the credentials are permanently leaked.

OCI solves this vulnerability using Instance Principals:

1. An administrator creates a Dynamic Group containing the application servers.
2. An IAM policy is written granting the dynamic group access: ALLOW dynamic-group BackendServers TO manage objects IN COMPARTMENT DataLake.
3. The application running on the compute instance queries the local Instance Metadata Service (http://169.254.169.254/opc/v2/identity/cert.pem).
4. OCI injects an ephemeral, short-lived X.509 cryptographic certificate and security token directly into the instance memory.
5. The application SDK signs outgoing OCI API calls using this temporary token.
6. Result: Zero static passwords, private keys, or API tokens are ever stored on the instance disk or in application source code.

---

Identity Constructs Architectural Comparison

---

Authentication Controls & Account Governance

OCI IAM Identity Domains provide multi-layered security controls to protect tenancies against unauthorized access:

• Multi-Factor Authentication (MFA): MFA requires users to present two or more verification factors before gaining console access. Supported factors include the Oracle Mobile Authenticator (OMA) mobile app (push approvals and time-based one-time passwords/TOTP), FIDO2 / WebAuthn hardware security keys (such as YubiKeys or device biometrics like Touch ID/Windows Hello), and email/SMS one-time passcodes.
• Password Policies: Administrators can configure tenancy-wide or domain-specific password rules, including minimum length (minimum 12 characters recommended), mandatory character sets (uppercase, lowercase, digits, symbols), password expiration cycles (e.g., 90 days), history restrictions (preventing reuse of the last 10 passwords), and lockout thresholds after failed login attempts.
• Sign-On Policies & Network Perimeters: Sign-on policies evaluate real-time session context before granting access. Administrators can define Network Perimeters (whitelisted corporate public CIDRs). A sign-on rule can enforce that console logins originating outside corporate IP ranges are prompted for mandatory MFA or outright blocked.
• Session Limits: Enforces maximum session durations and idle inactivity timeouts to prevent hijacked unattended browser sessions.

---

Enterprise Federation and Single Sign-On (SSO)

Large enterprises typically maintain an authoritative on-premises or cloud identity provider, such as Microsoft Entra ID (formerly Azure AD), Okta, Ping Identity, or Active Directory Federation Services (ADFS). Rather than manually creating duplicate user accounts and passwords inside OCI, organizations configure Identity Federation:

• Single Sign-On (SSO) via SAML 2.0: OCI IAM Identity Domains act as a Service Provider (SP), federating with the corporate directory acting as the Identity Provider (IdP) using the Security Assertion Markup Language (SAML 2.0) standard. When an engineer navigates to the OCI Console, they are redirected to their corporate identity provider login screen. Upon successful enterprise authentication, the IdP sends a digitally signed SAML assertion back to OCI, granting access without OCI ever seeing or storing the user's corporate password.
• Automated Provisioning via SCIM: OCI supports the System for Cross-domain Identity Management (SCIM) protocol. When an employee is hired, modified, or terminated in Microsoft Entra ID or Okta, SCIM automatically provisions, updates, or deactivates their corresponding identity inside the OCI Identity Domain in real time.