Oracle Cloud IAM without Identity Domains Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, Identity, and Compliance

1. Introduction

What this service is

IAM without Identity Domains is the “classic” Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) experience where you manage users, groups, compartments, policies, and related security primitives directly in the tenancy, without the newer Identity Domains layer.

One-paragraph simple explanation

If you need to control who can log in to Oracle Cloud and what they can do (create compute instances, manage networks, read buckets, administer databases), IAM without Identity Domains is the core service that lets you create users and groups, place resources into compartments, and write policies that enforce least-privilege access.

One-paragraph technical explanation

Technically, IAM without Identity Domains is a tenancy-scoped, global control-plane service that provides identity objects (users, groups), authorization primitives (policies and policy language), and governance boundaries (compartments). Authentication is typically performed via Console credentials (for human access) and API signing keys / tokens (for programmatic access through OCI APIs, CLI, and SDKs). Authorization is evaluated via OCI’s policy engine (verbs such as inspect, read, use, manage) at request time across OCI services.

What problem it solves

It solves the foundational cloud security problem: centralized identity and least-privilege access control across all OCI services—without having to build your own access control layer in every application or rely on ad-hoc credential sharing.

Naming and lifecycle note (important): Oracle Cloud has been transitioning many tenancies to IAM with Identity Domains. “IAM without Identity Domains” is still present for many environments (especially older tenancies) and remains widely referenced in OCI documentation. If your OCI Console shows Identity Domains or domain-related navigation for users and groups, you may be in the “with Identity Domains” model; this tutorial is specifically for the “without Identity Domains” model. Verify your tenancy type in the official docs and in your OCI Console UI before following the lab steps.

2. What is IAM without Identity Domains?

Official purpose

IAM without Identity Domains provides authentication and authorization for Oracle Cloud (OCI) resources by managing: – Identities (users and groups) – Access boundaries (compartments) – Permissions (policies written in OCI policy language) – Programmatic credentials (API keys, auth tokens, customer secret keys) – Workload identity (dynamic groups and instance principals / resource principals, where applicable)

For official documentation entry points, start here: – OCI IAM documentation: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm
– OCI IAM policy language: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policysyntax.htm

Core capabilities (high level)

Create and manage users, groups, and group membership
Create and manage compartments for isolation and delegation
Write policies to control access to OCI resources
Use dynamic groups to grant permissions to OCI resources (workloads) based on matching rules
Manage programmatic access credentials (API keys, auth tokens, customer secret keys)
Integrate with external identity providers via federation (commonly SAML 2.0), depending on tenancy configuration
Provide auditability via OCI Audit logs for IAM-related API calls (through the Audit service)

Major components

Component	What it is	Why it matters
Tenancy	Your top-level OCI account boundary	All IAM objects and policies are evaluated within a tenancy
Users	Human identities (local to OCI IAM)	Used for console login and API access
Groups	Collections of users	Policies are typically granted to groups, not individual users
Compartments	Logical isolation boundaries for resources	Enables separation of duties, environment isolation, and delegated admin
Policies	Authorization rules in policy language	Enforces least privilege across services
Dynamic Groups	Groups for OCI resources (not humans) matched by rules	Enables workload identity (instances/functions) to call OCI APIs securely
Credentials	API keys/tokens/secret keys	Enables programmatic access without sharing passwords
Federation	Trust relationship to an external IdP	Centralizes user lifecycle and MFA (depending on IdP setup)
Audit integration	Record of API calls	Supports forensics, compliance, and change tracking

Service type

A control-plane security service (identity + authorization), not a data-plane service. It does not host application workloads; it governs them.

Scope: regional/global/zonal?

IAM without Identity Domains is best understood as: – Tenancy-scoped – Global (not tied to a single region), although some OCI services and resources you control with IAM are regional.

In practical terms, you typically create one set of IAM users/groups/policies and use them to manage resources across multiple OCI regions in the same tenancy.

How it fits into the Oracle Cloud ecosystem

IAM without Identity Domains sits at the center of OCI’s Security, Identity, and Compliance category: – Every OCI API call is authenticated (identity) and authorized (policy) – Every OCI service (Compute, Networking, Object Storage, Database, Kubernetes, etc.) relies on IAM policy evaluation – Audit, Logging, Security Zones, Cloud Guard (and other governance tools) depend on IAM for access control and traceability

3. Why use IAM without Identity Domains?

Business reasons

Reduce risk and simplify governance: consistent access controls across all OCI services.
Faster onboarding: standardized roles and compartments let new teams start quickly.
Separation of duties: clean boundaries between dev, ops, security, and finance via compartments and policies.

Technical reasons

Least privilege by design: policy language supports tight scope (compartment, resource type, verbs).
Workload identity: dynamic groups + instance/resource principals reduce long-lived secret usage.
Automation-ready: first-class integration with OCI CLI/SDK/Terraform (permissions controlled by IAM).

Operational reasons

Central control: access changes happen in one place.
Auditable: IAM changes and access attempts can be tracked via OCI Audit.
Delegation: compartment administrators can be empowered without granting full tenancy admin.

Security/compliance reasons

Strong policy enforcement at the platform level (not application-dependent).
Supports compliance frameworks (your implementation determines compliance posture): access control, change tracking, and audit trails.
Federation compatibility enables centralized identity lifecycle and MFA enforcement via enterprise IdPs (availability and exact setup vary by tenancy).

Scalability/performance reasons

IAM is designed to handle large enterprises (many compartments, groups, policies).
Policy evaluation is platform-native; you avoid building and scaling authorization services yourself.

When teams should choose it

Choose IAM without Identity Domains when: – Your tenancy is already using the classic IAM model and your console navigation matches it. – You need straightforward OCI-native user/group/policy management without the Identity Domains abstraction. – You’re operating in a multi-compartment OCI environment and need clear delegated administration.

When they should not choose it

You should not design new processes around IAM without Identity Domains if: – Your tenancy is clearly using IAM with Identity Domains (you should use the identity domain model and its documentation). – Your organization requires features that may be centered around identity domains (for example, domain-centric user lifecycle patterns). Verify required features in official docs. – You need advanced identity lifecycle governance that is better handled by an external IdP or identity governance product.

4. Where is IAM without Identity Domains used?

Industries

Common in any regulated or security-conscious industry using OCI: – Financial services (segregation of duties, audit) – Healthcare/life sciences (access control and traceability) – Public sector (tenancy governance and compartment isolation) – SaaS providers (multi-environment, multi-team isolation) – Telecommunications and media (large-scale operational delegation)

Team types

Platform engineering teams building shared OCI landing zones
DevOps/SRE teams managing infrastructure automation and access
Security engineering teams defining least privilege and guardrails
Application teams needing scoped access to specific compartments/services
Operations/helpdesk teams handling user access requests

Workloads

Any OCI workload: Compute, OKE (Kubernetes), Functions, Object Storage, Database, Analytics, Integration services, etc.
CI/CD automation (OCI CLI/SDK/Terraform) requiring programmatic access

Architectures

Multi-account patterns are often implemented as multi-compartment patterns in OCI.
Hub-and-spoke networks, shared services compartments, and environment compartments (dev/test/prod).
Workload identity patterns using dynamic groups and instance principals.

Real-world deployment contexts

Enterprises: centralized security team sets baseline policies; app teams manage their compartments.
SaaS: strong isolation by environment; automation credentials carefully scoped.
Hybrid: federation to corporate IdP for console access and centralized offboarding.

Production vs dev/test usage

Production: strict least-privilege, federation preferred, tight compartment boundaries, limited admins, audited changes.
Dev/test: still use compartments and policies, but with more permissive roles—ideally time-bound or monitored.

5. Top Use Cases and Scenarios

Below are realistic ways IAM without Identity Domains is used in Oracle Cloud.

1) Build a compartment-based landing zone

Problem: Multiple teams need OCI resources without stepping on each other.
Why this service fits: Compartments + policies provide clean isolation and delegation.
Example: Create Network, Security, SharedServices, App-Dev, App-Prod compartments and delegate admins per compartment.

2) Enforce least-privilege for Object Storage access

Problem: A team needs buckets and objects access without full admin.
Why this service fits: Policy language can grant manage object-family only in the needed compartment.
Example: A data engineering group can upload datasets to DataIngest compartment buckets but cannot manage VCNs or compute.

3) Secure CI/CD pipelines with scoped API keys

Problem: Automation needs to create/update OCI resources.
Why this service fits: Create a dedicated automation user in a group with limited policies.
Example: A pipeline user can deploy to App-Dev only, with no read access to production secrets.

4) Enable workloads to call OCI APIs without stored secrets

Problem: An application on a VM must access Object Storage or Vault without embedding keys.
Why this service fits: Dynamic groups + instance principals allow identity based on the instance itself.
Example: A compute instance in App-Prod can read objects from a bucket using instance principal permissions.

5) Delegate network administration without tenancy admin

Problem: Network engineers must manage VCNs and gateways, but not databases.
Why this service fits: Policies can target network resource families in a compartment.
Example: Network team gets manage virtual-network-family in Network compartment only.

6) Centralize user lifecycle with federation

Problem: Manual user management in OCI becomes error-prone and offboarding is risky.
Why this service fits: Federation to an external IdP can centralize authentication and lifecycle (implementation-dependent).
Example: Use SAML federation so employees use corporate SSO to log into OCI; removing the corporate account removes access.

7) Separate duties for security monitoring and incident response

Problem: Security team needs visibility without the ability to change infrastructure.
Why this service fits: read or inspect policies plus Audit/Logging access.
Example: Security analysts can read logs, list resources, and view IAM policies but cannot modify compute or networks.

8) Manage cross-team shared services safely

Problem: Shared services (DNS, bastions, logging) are used by many teams.
Why this service fits: Compartments isolate shared services while allowing controlled access.
Example: App teams can use shared subnets or read log groups but can’t alter shared infrastructure.

9) Implement environment isolation for compliance

Problem: Compliance requires strict separation between dev and prod.
Why this service fits: Separate compartments with distinct policies, groups, and change controls.
Example: Developers can manage resources in App-Dev but have read-only in App-Prod.

10) Control access for third-party vendors

Problem: A vendor needs temporary access to troubleshoot.
Why this service fits: Create a restricted group + policy; remove membership when done.
Example: Vendor can read metrics/logs in a single compartment for 48 hours.

11) Limit access by source network (where applicable)

Problem: Console/API access must originate only from known corporate networks.
Why this service fits: IAM “network sources” can restrict requests based on IP ranges (feature availability and exact behavior: verify in official docs).
Example: Only corporate VPN IP ranges can access OCI APIs for admin operations.

12) Provide break-glass administration

Problem: Need emergency access when federation or IdP fails.
Why this service fits: Keep a minimal set of local OCI admins with tightly protected credentials.
Example: Two security leads have local accounts stored in a secure vault for outage recovery.

6. Core Features

Note: Feature availability and UI labels can vary depending on tenancy type and OCI updates. Where you see “Verify in official docs,” confirm in Oracle’s current documentation for your tenancy model.

6.1 Users (local OCI identities)

What it does: Creates human identities in the OCI tenancy.
Why it matters: You need identities to grant access and to authenticate to the Console/API.
Practical benefit: Simple onboarding for small teams or as break-glass accounts.
Limitations/caveats: For large enterprises, local user lifecycle can become hard to govern; federation is often preferred.

6.2 Groups and group membership

What it does: Organizes users; policies typically target groups.
Why it matters: Grants are easier to manage via role-based access control (RBAC) patterns.
Practical benefit: Add/remove users from a group instead of editing policies frequently.
Limitations/caveats: Excessive group sprawl can make access reviews hard—use naming standards.

6.3 Compartments (resource isolation and delegation)

What it does: Creates logical boundaries for OCI resources.
Why it matters: Compartments are the primary scope boundary for policy grants.
Practical benefit: Model environments and teams; delegate admin rights per compartment.
Limitations/caveats: Compartment hierarchy planning matters; moving resources between compartments can have operational consequences.

6.4 Policies (OCI policy language)

What it does: Defines permissions using statements like:
Allow group <group-name> to manage object-family in compartment <compartment-name>
Why it matters: This is the core authorization layer for OCI.
Practical benefit: Fine-grained control by service, verb, and scope.
Limitations/caveats: Policy evaluation can appear eventually consistent (changes might take a short time to apply). Policy language has its own syntax and learning curve.

Official policy language reference: – https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policysyntax.htm

6.5 Dynamic groups (workload identity)

What it does: Creates groups for OCI resources (for example, instances) based on matching rules.
Why it matters: Enables “identity for workloads” so apps can call OCI APIs without distributing user keys.
Practical benefit: Better security posture than long-lived API keys in application configs.
Limitations/caveats: Matching rules must be designed carefully (too broad rules can grant access to unintended instances).

6.6 Instance principals / resource principals (where applicable)

What it does: Allows OCI resources (like compute instances) to authenticate to OCI APIs using their own identity.
Why it matters: Eliminates secret distribution for many OCI-to-OCI access patterns.
Practical benefit: Rotate-free authentication for workloads.
Limitations/caveats: Requires correct dynamic group and policy configuration; debugging can be non-trivial.

(Confirm current scope in docs for your target service integrations.)

6.7 API keys (request signing) for OCI CLI/SDK

What it does: Uses an RSA key pair; OCI stores the public key; your client signs requests with the private key.
Why it matters: This is the standard secure mechanism for OCI API authentication for local users.
Practical benefit: Strong cryptographic authentication; works across CLI/SDKs.
Limitations/caveats: Private key protection is critical; rotation should be planned.

OCI CLI docs: – https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm

6.8 Auth tokens (for certain API patterns)

What it does: Creates tokens used with specific services/protocols that don’t support OCI request signing (common example patterns exist for Object Storage compatibility and tooling).
Why it matters: Enables integration with tools that can’t sign OCI API requests.
Practical benefit: Allows controlled access without sharing the user password.
Limitations/caveats: Treat as secrets; rotate and scope carefully; avoid creating many unmanaged tokens.

6.9 Customer secret keys (S3 compatibility scenarios)

What it does: Provides keys used with S3-compatible APIs for Object Storage.
Why it matters: Some applications are built around S3 semantics.
Practical benefit: Faster migration for S3-based tooling.
Limitations/caveats: Adds another credential type to manage; enforce rotation and least privilege.

6.10 Federation (external identity provider trust)

What it does: Enables users to authenticate via an external IdP (commonly SAML 2.0), depending on OCI tenancy setup.
Why it matters: Centralizes authentication, user lifecycle, and often MFA enforcement at the enterprise IdP.
Practical benefit: Faster onboarding/offboarding and improved access governance.
Limitations/caveats: Setup complexity; break-glass local access still recommended.

6.11 Auditability (via OCI Audit service)

What it does: IAM-related operations and API calls can be captured as audit events.
Why it matters: Compliance, forensics, and operational troubleshooting.
Practical benefit: Track “who changed what and when.”
Limitations/caveats: Understand retention/export requirements; integrate with Logging/SIEM as needed.

OCI Audit overview: – https://docs.oracle.com/en-us/iaas/Content/Audit/Concepts/auditoverview.htm

7. Architecture and How It Works

Service architecture at a high level

IAM without Identity Domains is part of the OCI control plane. The major flow is:

A user or workload authenticates to OCI (Console login, API signing request, or principal-based auth).
OCI receives an API request for a target service (Compute, Networking, Object Storage, etc.).
The IAM authorization engine evaluates applicable policies: – Who is the caller (user/group or dynamic group principal) – What action is requested (inspect, read, use, manage) – What resource type is involved – Scope boundary (tenancy vs compartment)
If allowed, the request proceeds to the target service.
The action is recorded in audit logs (Audit service).

Request/data/control flow

Control plane flow: IAM policy evaluation happens for most OCI service API calls.
Data plane flow: IAM doesn’t carry your application data; data flows in the target services (Object Storage, block volumes, etc.).
Audit flow: Events are emitted to Audit; you can integrate with Logging/Notifications/SIEM downstream.

Integrations with related services

Common integrations: – OCI Audit for tracking IAM and API activity – OCI Logging for centralized log management (service-specific) – OCI Vault for secrets/keys used by applications (IAM controls who can access Vault) – OCI Cloud Guard / Security Zones (governance services that rely on IAM permissions) – OCI Resource Manager / Terraform (automation identities controlled by IAM)

Dependency services

IAM is foundational; most OCI services depend on it. IAM itself depends on OCI tenancy constructs.

Security/authentication model (summary)

Human access: Console login (local users or federated users)
Programmatic access:
API signing keys for users
Auth tokens / customer secret keys for specific compatibility scenarios
Instance/resource principals for workloads (dynamic groups + policies)

Networking model

IAM is a control-plane service and is accessed over HTTPS endpoints. Network-level controls (like restricting access from certain source IP ranges) may be available using IAM features such as network sources (verify current behavior in official docs). For most customers, network security is applied at: – VCN and subnet controls (for workloads) – Private endpoints / service gateways (for data plane where applicable) – IAM policies for authorization

Monitoring/logging/governance considerations

Audit logs: baseline for “who did what.”
Tagging: tag compartments and IAM objects where supported (IAM object tagging support varies; verify).
Access reviews: periodic reviews of group memberships and policies.
Automation: changes via Terraform should be reviewed and logged.

Simple architecture diagram (Mermaid)

flowchart LR
  U[User / Automation] -->|Authenticate| IAM[IAM without Identity Domains]
  U -->|API Request| SVC[OCI Service API<br/>(Compute, Object Storage, etc.)]
  SVC -->|Authorize (policy eval)| IAM
  SVC -->|Emit events| AUD[OCI Audit]
  AUD --> SEC[Security Ops / SIEM]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Tenant[OCI Tenancy]
    subgraph IAMClassic[IAM without Identity Domains]
      USERS[Users]
      GROUPS[Groups]
      POL[Policies]
      COMP[Compartments]
      DG[Dynamic Groups]
    end

    subgraph Shared[Shared Services Compartment]
      LOG[Logging / Log Groups]
      VAULT[Vault (Secrets/Keys)]
      NOTIF[Notifications]
    end

    subgraph AppProd[App-Prod Compartment]
      OKE[OKE / Compute]
      OS[Object Storage]
      DB[Database]
    end
  end

  IdP[Enterprise IdP<br/>(SAML Federation - optional)] --> IAMClassic
  OKE -->|Instance/Resource Principal| IAMClassic
  USERS --> GROUPS
  GROUPS --> POL
  POL --> COMP
  POL --> AppProd
  OKE --> OS
  OKE --> DB
  IAMClassic -->|Audit events| AUDIT[OCI Audit]
  AUDIT --> LOG
  LOG --> NOTIF
  NOTIF --> SOC[SecOps / On-call]
  VAULT --> OKE

8. Prerequisites

Tenancy/account requirements

An Oracle Cloud (OCI) tenancy that uses the IAM without Identity Domains model.
If your tenancy uses Identity Domains, use the “IAM with identity domains” documentation instead. Verify in official docs and console UI.

Permissions/IAM roles

To complete the hands-on lab, you need a user with permissions to: – Create compartments – Create users and groups – Create policies – Optionally manage Object Storage resources in a test compartment

Typically, this means you need tenancy administrator access (or equivalent delegated admin permissions) for setup.

Billing requirements

IAM without Identity Domains itself is typically not billed as a metered resource, but the lab uses Object Storage, which can have costs.
Ensure your tenancy has billing enabled (or Free Tier with available limits).

Tools needed

Choose one: – OCI Console (web UI) – OCI CLI for verification steps and the lab
CLI docs: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm

Optional: – Terraform / OCI Resource Manager for infrastructure-as-code (not required for this lab)

Region availability

IAM is tenancy/global, but the lab uses a target OCI region for Object Storage operations. Pick a region where your tenancy is subscribed.

Quotas/limits

IAM object limits (number of users, groups, policies) exist. For most small labs they won’t be an issue.
Object Storage limits (buckets/objects) also exist.
Always check current service limits/quotas in OCI docs for your region and tenancy.

Prerequisite services (for the lab)

Object Storage (to demonstrate IAM permissions end-to-end)
Audit (optional, for verifying actions)

9. Pricing / Cost

Current pricing model (accurate framing)

IAM without Identity Domains (users, groups, compartments, policies) is generally treated as a foundational OCI capability and is not typically priced like a usage-metered service.
However, the resources you control with IAM (Compute, Storage, Networking egress, Logging ingestion, etc.) can incur costs.

Because pricing can vary by region, service, and contract, use Oracle’s official pricing resources: – Oracle Cloud Pricing: https://www.oracle.com/cloud/pricing/ – Oracle Cloud Price List: https://www.oracle.com/cloud/price-list/ – Oracle Cloud Cost Estimator (if available in your region): https://www.oracle.com/cloud/costestimator.html (verify availability)

Pricing dimensions you must understand

Even if IAM itself is not metered, your total cost depends on: – Object Storage: storage GB-month, requests, retrieval (depends on tier), and outbound transfer – Logging: ingestion, storage/retention, and exports (service-specific) – Audit: may have included retention with limits; exporting logs to storage can cost storage/egress – Networking: internet egress, inter-region traffic, NAT gateways, load balancers – Compute/OKE: OCPU/memory hours, node pools, load balancers, block volumes

Free tier considerations

Oracle Cloud has a Free Tier program and Always Free resources, but eligibility and limits change. Verify current Free Tier entitlements on Oracle’s pricing/free tier pages.

Cost drivers in IAM-centric designs

Too many broad permissions can lead to resource sprawl (indirect cost).
Overuse of logging at high volumes can increase ingestion/storage costs.
Using S3 compatibility keys/tokens across many apps increases operational overhead (not direct cost, but real cost).

Hidden or indirect costs

Operational cost: access reviews, credential rotation, incident response.
Data egress: exporting audit/log data to external systems can incur egress charges.
Automation mistakes: overly permissive policies can lead to expensive resources being created unintentionally.

Network/data transfer implications

IAM policy evaluation doesn’t directly change network costs, but: – Better IAM can prevent accidental exposure and reduce incident costs. – Cross-region architectures increase data transfer costs; IAM won’t remove that.

How to optimize cost (IAM angle)

Use least privilege to prevent unintended provisioning.
Use compartments and quotas/budgets (where available) to constrain spend (budgeting features are outside IAM but related to governance).
Prefer instance/resource principals to reduce credential sprawl and operational overhead.
Avoid duplicating “admin-like” policies for many teams.

Example low-cost starter estimate (conceptual)

A minimal lab cost can be near-zero if you: – Use a single small Object Storage bucket with a tiny object – Delete everything after validation – Avoid high-volume logging exports or egress

Exact costs depend on region and your tenancy’s pricing—use the Cost Estimator and Object Storage pricing pages for numbers.

Example production cost considerations (conceptual)

In production, IAM design impacts cost mainly by controlling: – Who can provision expensive resources – The blast radius of misconfigurations – The operational burden of credential management and audits

10. Step-by-Step Hands-On Tutorial

Objective

Set up a least-privilege OCI access pattern using IAM without Identity Domains: – Create a compartment for a lab – Create a group and user – Create a policy granting Object Storage permissions only in that compartment – Create an API signing key and configure OCI CLI – Use OCI CLI to create a bucket and upload an object – Validate permissions and clean up

Lab Overview

You will build this flow:

Admin user creates compartment, group, user, and policy.
Lab user authenticates with OCI CLI using an API key.
Lab user performs Object Storage actions only within the lab compartment.

Expected outcome: – The lab user can manage Object Storage objects/buckets only in the lab compartment. – The lab user cannot manage unrelated resources (because no policies grant that).

Step 1: Confirm you are using “IAM without Identity Domains”

Sign in to the OCI Console.
Navigate to the IAM area (often under Identity & Security).
Look for classic navigation items such as Users, Groups, Policies, Compartments that are not centered around “Identity Domains.”

Expected outcome: You can locate classic IAM objects directly (users/groups/policies) without selecting an identity domain.

If your console requires selecting an identity domain to manage users/groups, stop and use the “IAM with Identity Domains” documentation instead.
Verify in official docs: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm

Step 2: Create a compartment for the lab

In the OCI Console, go to Identity & Security → Compartments.
Click Create Compartment.
Use: – Name: iam-lab-compartment – Description: Lab compartment for IAM without Identity Domains tutorial – Parent: choose an appropriate parent (often the root compartment)
Create the compartment.

Expected outcome: A new compartment exists, and you can select it from the compartment picker.

Verification tip: Copy the compartment OCID from the compartment details page—you will use it later.

Step 3: Create a group for Object Storage admins (scoped to the lab)

Go to Identity & Security → Groups.
Click Create Group.
Use: – Name: iam-lab-os-admins – Description: Group for lab user with Object Storage access in lab compartment

Expected outcome: The group exists with no members.

Step 4: Create a lab user and add them to the group

Go to Identity & Security → Users.
Click Create User.
Provide: – Name: iam-lab-user – Description: Lab user for OCI CLI access
Create the user.
Open the user details and add the user to the group: – Add to Group → select iam-lab-os-admins

Expected outcome: iam-lab-user is a member of iam-lab-os-admins.

Verification tip: Keep the user’s OCID and username handy.

Step 5: Create a policy granting least-privilege Object Storage access

Go to Identity & Security → Policies.
Ensure you are in the root compartment (policies are often created at a higher level so they can reference target compartments; exact behavior depends on your tenancy—verify in your console).
Click Create Policy.
Use: – Name: iam-lab-os-policy – Description: Allow lab group to manage Object Storage in lab compartment – Compartment: root (or appropriate parent)
Add a policy statement (start with one of the common patterns below):

Option A (simple and broad within Object Storage): – Allow group iam-lab-os-admins to manage object-family in compartment iam-lab-compartment

Option B (more restrictive; verify resource types/verbs in docs if you want to refine): – You can split bucket management from object management, but policy syntax must match OCI’s supported resource types.

Expected outcome: The policy is created.

Verification: Policy changes may take a short time to propagate. If access fails immediately, wait a couple of minutes and retry.

Official policy reference: – https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policysyntax.htm

Step 6: Create an API key for the lab user (for OCI CLI/SDK access)

You will generate an RSA key pair locally and upload the public key to the OCI user.

6A) Generate an API signing key pair (local machine)

On Linux/macOS (or Windows with OpenSSL installed), run:

mkdir -p ~/.oci
openssl genrsa -out ~/.oci/oci_api_key.pem 2048
openssl rsa -pubout -in ~/.oci/oci_api_key.pem -out ~/.oci/oci_api_key_public.pem
chmod 600 ~/.oci/oci_api_key.pem

Expected outcome: You have: – ~/.oci/oci_api_key.pem (private key, keep secret) – ~/.oci/oci_api_key_public.pem (public key, upload to OCI)

6B) Upload the public key in OCI Console

Sign in as an admin (or as the lab user if permitted to manage their own API keys).
Go to Identity & Security → Users → iam-lab-user.
Find API Keys.
Click Add API Key.
Paste the contents of oci_api_key_public.pem.

After adding the key, OCI will show: – Fingerprint (important) – The key entry in the user’s API keys list

Expected outcome: The user has an API key registered and you have the fingerprint.

Step 7: Install and configure OCI CLI for the lab user

OCI CLI installation varies by OS. Follow Oracle’s official instructions: – https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm

After installation, create the CLI config file:

nano ~/.oci/config

Add a profile like this (replace placeholders):

[iam-lab]
user=ocid1.user.oc1..exampleuniqueID
fingerprint=11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00
tenancy=ocid1.tenancy.oc1..exampleuniqueID
region=us-ashburn-1
key_file=/home/youruser/.oci/oci_api_key.pem

Where to get values: – user: from iam-lab-user details page – tenancy: from Tenancy details (or admin user’s tenancy OCID) – region: choose your target region (must be subscribed) – fingerprint: from the API key entry you created – key_file: path to your private key

Expected outcome: OCI CLI has a working profile named iam-lab.

Step 8: Verify authentication and discover your Object Storage namespace

Run:

oci os ns get --profile iam-lab

Expected outcome: The command returns your Object Storage namespace string.

Store it in a shell variable (optional):

NS=$(oci os ns get --profile iam-lab --query 'data' --raw-output)
echo "$NS"

Step 9: Create a bucket in the lab compartment

You need the compartment OCID for iam-lab-compartment. Set it:

COMP_OCID="ocid1.compartment.oc1..exampleuniqueID"

Create a bucket:

oci os bucket create \
  --profile iam-lab \
  --compartment-id "$COMP_OCID" \
  --namespace-name "$NS" \
  --name "iam-lab-bucket" \
  --storage-tier Standard

Expected outcome: The CLI returns JSON output showing the bucket was created.

Verification:

oci os bucket get \
  --profile iam-lab \
  --namespace-name "$NS" \
  --name "iam-lab-bucket"

Step 10: Upload and list an object

Create a small test file:

echo "hello from IAM without Identity Domains lab" > hello.txt

Upload:

oci os object put \
  --profile iam-lab \
  --namespace-name "$NS" \
  --bucket-name "iam-lab-bucket" \
  --file "hello.txt" \
  --name "hello.txt"

List objects:

oci os object list \
  --profile iam-lab \
  --namespace-name "$NS" \
  --bucket-name "iam-lab-bucket"

Expected outcome: You see hello.txt listed.

Step 11: (Optional) Verify authorization boundaries by attempting a disallowed action

Try to list compartments (often restricted to admins unless explicitly granted):

oci iam compartment list --profile iam-lab --compartment-id-in-subtree true --all

Expected outcome: This may fail with an authorization error such as “NotAuthorizedOrNotFound” unless you have additional IAM read permissions.

This demonstrates least privilege: you granted Object Storage access, not IAM read access.

Validation

You have successfully validated IAM without Identity Domains if: – The lab user can create a bucket and upload/list objects in iam-lab-compartment. – The lab user cannot perform unrelated actions (for example, listing all compartments or managing compute) unless additional policies exist.

Optional audit validation: – Check OCI Audit for events corresponding to your API calls.
Audit docs: https://docs.oracle.com/en-us/iaas/Content/Audit/Concepts/auditoverview.htm

Troubleshooting

1) “NotAuthorizedOrNotFound” when creating bucket/object

Common causes: – Policy not propagated yet: wait 1–5 minutes, retry. – Policy targets wrong compartment name/scope: ensure statement references iam-lab-compartment correctly. – The user is not actually in the group: verify group membership. – Wrong compartment OCID used in CLI.

Fix: – Re-check group membership and the policy statement. – Verify compartment selection and OCIDs.

2) CLI authentication errors (401, signature errors)

Common causes: – Wrong fingerprint in ~/.oci/config – Private key permissions too open or wrong path – Wrong user OCID / tenancy OCID – Clock skew on your machine

Fix: – Re-copy values from OCI Console. – Ensure chmod 600 ~/.oci/oci_api_key.pem. – Synchronize system time.

3) Region-related errors

Object Storage is regional. If you use a region not subscribed/available, commands may fail.

Fix: – Set region= in the CLI profile to a subscribed region. – Verify in Console which regions are enabled.

Cleanup

To avoid ongoing cost and clutter:

Delete the object:

oci os object delete \
  --profile iam-lab \
  --namespace-name "$NS" \
  --bucket-name "iam-lab-bucket" \
  --object-name "hello.txt" \
  --force

Delete the bucket:

oci os bucket delete \
  --profile iam-lab \
  --namespace-name "$NS" \
  --name "iam-lab-bucket" \
  --force

In OCI Console (as admin): – Delete policy iam-lab-os-policy – Remove user iam-lab-user from group and delete the user – Ensure you also delete the user’s API key entry first if required by the console workflow – Delete group iam-lab-os-admins – Delete compartment iam-lab-compartment (only possible when empty; deletion can take time)

Expected outcome: All lab-created IAM objects and storage resources are removed.

11. Best Practices

Architecture best practices

Design compartments first, then policies. Use compartments to model:
environments (dev/test/prod)
teams (platform/app/security)
shared services vs workloads
Keep a clean compartment hierarchy; avoid deep nesting unless you have a clear delegation model.
Use separate compartments for “shared” services (logging, networking, vault) with carefully designed use permissions.

IAM/security best practices

Prefer group-based access; avoid writing policies for individuals.
Apply least privilege:
Start with inspect/read
Move to use
Use manage only when required
Separate human admin roles:
Tenancy admins (very small set)
Compartment admins (delegated)
Read-only auditors/security
Use dynamic groups + instance/resource principals for workloads when possible to reduce secret sprawl.
For programmatic user credentials:
Protect private keys
Rotate keys/tokens regularly
Use separate automation users per pipeline/team

Cost best practices

Treat IAM as a spend-control system: only allow provisioning to those who need it.
Use compartments to align spend ownership (chargeback/showback).
Limit who can create cost-intensive resources (large compute shapes, load balancers, high-tier storage).
Keep logs and audit exports sized appropriately (retention policies and export frequency matter).

Performance best practices

IAM performance is not usually your bottleneck, but:
Minimize overly complex policy sprawl that makes reviews hard.
Keep dynamic group matching rules clear and minimal.

Reliability best practices

Maintain break-glass local accounts with strong protection for emergency access (stored securely, monitored).
Avoid single-admin dependency. Require at least two admins for critical compartments.
Document recovery steps if federation/SSO is unavailable.

Operations best practices

Use naming conventions:
Compartments: env-app or team-env
Groups: role-scope (e.g., net-admins-prod)
Policies: policy-<scope>-<purpose>
Implement a regular access review:
group membership checks
stale credentials cleanup (API keys/tokens)
Track changes via Audit; integrate with a SIEM if required.

Governance/tagging/naming best practices

Standardize compartment names and descriptions for fast audits.
Use tags for cost tracking on resources; IAM controls who can create/edit tag namespaces (tagging governance intersects with IAM—verify tag governance features and permissions in official docs).

12. Security Considerations

Identity and access model

Authentication:
Human: console credentials or federated login
Programmatic: API signing keys or tokens, or workload principals
Authorization:
Policies define permissions; evaluation is performed by OCI at request time.
Policies should be scoped to compartments whenever possible.

Encryption

IAM does not store your application data, but it does manage credentials: – Protect private keys locally (file permissions, secure storage, endpoint hardening). – Treat auth tokens and secret keys as secrets; store in a secret manager (for example OCI Vault) where appropriate.

Network exposure

OCI IAM APIs are accessed over the public internet endpoints (HTTPS).
If using IP-based restrictions (network sources), ensure they are accurate and kept up-to-date. Verify current behavior and limitations in official docs before relying on it for compliance.

Secrets handling

Do not embed private keys or auth tokens in source code.
For CI/CD, use secure secret storage and short-lived access patterns where possible.
Prefer workload principals (dynamic groups) over distributing user credentials to workloads.

Audit/logging

Use OCI Audit as the authoritative record of IAM and API activity.
Forward audit logs to centralized logging/SIEM when required.
Establish alerting on:
policy changes
creation of new API keys
changes in group membership for admin groups

Compliance considerations

IAM supports compliance objectives such as: – access control (least privilege) – traceability (audit logs) – separation of duties (compartments + roles)

But compliance is about configuration and process: – define approval workflows for policy changes – periodically review access – enforce credential hygiene

Common security mistakes

Granting manage all-resources in tenancy to too many groups.
Using shared accounts (“team user”) instead of individual identities.
Long-lived API keys used by multiple pipelines without rotation.
Overly broad dynamic group matching rules.
No break-glass plan (or break-glass credentials unmanaged).

Secure deployment recommendations

Keep tenancy admins minimal and protected.
Use federation for workforce identity if feasible; keep local users as backup.
Implement strong change management for policies.
Use compartments to reduce blast radius.

13. Limitations and Gotchas

Known limitations (practical)

Tenancy model mismatch: If your tenancy uses Identity Domains, the objects and workflows differ. This is the #1 source of confusion.
Policy propagation delay: After creating/updating policies, access may not work instantly.
Policy readability at scale: Many compartments and policies can become hard to audit without naming and documentation standards.

Quotas/limits

Limits exist for IAM objects (users/groups/policies) and service limits for resources. Exact numbers change and can vary. Verify current limits in official docs.

Regional constraints

IAM is global/tenancy-scoped, but many services you authorize are regional. Ensure CLI profiles target the correct region.

Pricing surprises

IAM itself may not be a direct metered cost, but:
logging exports
data egress for audit/log forwarding
accidental provisioning due to permissive policies
can create real cost.

Compatibility issues

Some tools require auth tokens or S3 secret keys; others support API signing. Choose the right credential type for each integration.
Federation setups vary significantly by enterprise IdP and OCI tenancy type.

Operational gotchas

Deleting compartments requires all contained resources to be removed first, and deletion may be asynchronous.
Rotating keys without updating dependent automation can break deployments.
Overlapping policies across multiple parent compartments can make effective permissions non-obvious.

Migration challenges

Moving from classic IAM (without identity domains) to identity domains (or vice versa) can involve changes in how identities are managed. Do not assume a 1:1 mapping without reading Oracle’s migration guidance. Verify in official docs.

Vendor-specific nuances

OCI policy language differs from AWS/Azure/GCP IAM models; plan training accordingly.
“NotAuthorizedOrNotFound” errors can be ambiguous: it might be a permission issue or truly missing resource.

14. Comparison with Alternatives

IAM without Identity Domains is one approach within OCI and differs from other cloud IAM systems.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud IAM without Identity Domains	Tenancies using classic IAM model	Simple OCI-native users/groups/compartments/policies; strong compartment scoping; good for OCI governance foundations	Tenancy-type specific; may not match newer domain-centric identity features	When your tenancy uses classic IAM and you need direct OCI IAM management
Oracle Cloud IAM with Identity Domains	Tenancies standardized on identity domains	Domain-centric identity management; often aligns with enterprise identity patterns	Different UI/workflows; migration considerations	When your tenancy uses identity domains or you need domain-based identity management
AWS IAM + AWS Organizations	AWS environments	Mature policy ecosystem; broad integration	Policy complexity; learning curve	When you are primarily on AWS or need AWS-native identity
Microsoft Entra ID + Azure RBAC	Azure environments	Strong enterprise identity integration; RBAC tied to Azure resources	Complexity across subscriptions/management groups	When you are primarily on Azure or need Entra-native identity lifecycle
Google Cloud IAM	GCP environments	Uniform IAM across services; strong service account model	Model differs from OCI/AWS; role granularity varies	When you are primarily on GCP
Keycloak (self-managed)	Hybrid/multi-cloud apps needing central auth	Full control; many protocols; app-centric identity	You must operate/patch/scale it; not cloud-control-plane IAM	When you need app identity federation across multiple environments and accept operational overhead

15. Real-World Example

Enterprise example: regulated multi-team OCI platform

Problem: A financial services company is building a governed OCI landing zone for 20+ teams with strict separation of dev/prod and audit requirements.
Proposed architecture:
Compartments:
- Security (Audit exports, SIEM integration, Vault)
- Network (VCNs, DRGs, gateways)
- SharedServices (bastions, tooling, central logging)
- AppTeamA-Dev, AppTeamA-Prod, … for each team
IAM without Identity Domains:
- Groups: net-admins, sec-auditors, appteamA-dev-admins, appteamA-prod-readonly
- Policies scoped to compartments, using least privilege
Federation to corporate IdP (where supported) for workforce login; local break-glass accounts maintained.
Why this service was chosen: The enterprise has an existing classic IAM tenancy and needs direct compartment/policy governance aligned to OCI’s model.
Expected outcomes:
Clear separation of duties and environments
Auditable changes and access
Reduced risk of cross-team impact

Startup/small-team example: lean access for a small SaaS on OCI

Problem: A startup runs a SaaS on OCI and needs to avoid sharing root/admin credentials while enabling engineers to deploy quickly.
Proposed architecture:
Compartments: Dev, Prod
Groups:
- devs-dev-admin (manage most resources in Dev)
- devs-prod-deploy (manage only deployment-related resources in Prod)
- security-readonly (read logs/audit)
Use dynamic groups for compute instances in Prod to read from Object Storage and access secrets (where applicable).
Why this service was chosen: It’s the default tenancy model for them (classic), and it provides enough governance without extra tooling.
Expected outcomes:
Least privilege without slowing down delivery
Reduced credential sprawl in production workloads
Better incident response through auditability

16. FAQ

1) How do I know if I’m using IAM without Identity Domains?
Check your OCI Console navigation. If users/groups/policies are managed directly under IAM without selecting an identity domain, you’re likely in the classic model. If you must select an identity domain for user management, you’re likely using the identity domains model. Verify in official docs: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm

2) Is IAM without Identity Domains “deprecated”?
Oracle has been emphasizing Identity Domains for many tenancies, but “IAM without Identity Domains” still exists and is documented. The right question is whether your tenancy uses it today and what Oracle’s current guidance is for new deployments—verify in official docs and release notes.

3) Do IAM users cost money?
IAM is generally not billed per user like a SaaS directory. However, always confirm current Oracle pricing terms for your contract/tenancy. Your usage of other OCI services (storage, compute, logging) does cost money.

4) What’s the difference between a compartment and a group?
A compartment is a boundary for resources. A group is a collection of users. Policies connect them: they grant a group permissions to act on resources in a compartment.

5) Should I grant permissions to users directly?
Best practice is to grant permissions to groups, then manage access by group membership. This improves auditability and reduces policy sprawl.

6) Why do policy statements reference compartments by name?
OCI policy language commonly references compartments by name in the statement. This makes readability better, but it also means you must keep names consistent and avoid confusing naming.

7) How long do policies take to take effect?
Often within moments, but sometimes there is a short propagation delay. If you get an authorization error right after a policy change, wait a few minutes and retry.

8) What’s the safest way to give applications access to OCI APIs?
Prefer dynamic groups + instance/resource principals (workload identity) so you don’t store long-lived user private keys in applications.

9) When should I use API keys vs auth tokens?
Use API keys for OCI CLI/SDK and services that support request signing. Use auth tokens for tools/protocols that do not support OCI request signing. Confirm which credential type your integration requires.

10) What is “NotAuthorizedOrNotFound” and why is it confusing?
OCI often returns this when you either (a) lack permission or (b) the resource doesn’t exist in the scope you can see. Troubleshoot by verifying policies, compartment OCIDs, and whether the resource truly exists.

11) Can I restrict access by IP address?
OCI IAM has features such as network sources that can restrict access based on source IPs. Behavior and applicability depend on your setup—verify current details in official documentation before relying on it for compliance.

12) How do I implement separation of duties (SoD) in OCI?
Use compartments aligned to organizational boundaries and create distinct groups/policies for roles (network admins, DB admins, auditors). Keep tenancy admins minimal.

13) How do I audit who changed a policy?
Use OCI Audit to view events for policy creation/update/deletion. You may also export audit logs to Object Storage or a SIEM depending on your requirements.

14) Can I manage IAM without Identity Domains using Terraform?
Yes, OCI supports Terraform (including Resource Manager). Ensure your automation identity has least-privilege permissions and protect state files (which may contain sensitive data).

15) What’s the recommended way to manage access for third parties?
Create dedicated users/groups with scoped policies, time-bound access, and strong monitoring. Remove access immediately when the engagement ends.

16) Do I need a separate tenancy for each environment?
Not necessarily. Many OCI designs use compartments for dev/test/prod within a single tenancy. For strict isolation requirements, multiple tenancies might be considered—but that adds operational overhead.

17) What’s the most common beginner mistake in OCI IAM?
Creating one broad admin group and putting everyone in it. Start with least privilege and compartment-scoped permissions.

17. Top Online Resources to Learn IAM without Identity Domains

Resource Type	Name	Why It Is Useful
Official documentation	OCI IAM docs	Primary reference for IAM without Identity Domains concepts and tasks: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm
Official documentation	Policy syntax reference	Authoritative policy language rules and examples: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policysyntax.htm
Official documentation	OCI CLI install/use	Step-by-step CLI setup and auth models: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Official documentation	OCI Audit overview	Understand audit events and retention/export patterns: https://docs.oracle.com/en-us/iaas/Content/Audit/Concepts/auditoverview.htm
Official documentation	Object Storage overview	Useful for IAM labs and real-world access control: https://docs.oracle.com/en-us/iaas/Content/Object/Concepts/objectstorageoverview.htm
Official pricing	Oracle Cloud Pricing	High-level pricing entry point: https://www.oracle.com/cloud/pricing/
Official pricing	Oracle Cloud Price List	Detailed SKU-level pricing reference (region/contract dependent): https://www.oracle.com/cloud/price-list/
Official tool	Oracle Cloud Cost Estimator	Helps model spend; verify availability: https://www.oracle.com/cloud/costestimator.html
Official architecture	OCI Architecture Center	Reference architectures and best practices: https://docs.oracle.com/en/solutions/
Official training/labs	Oracle Cloud Tutorials (landing)	Official tutorials vary; start here and search IAM topics: https://docs.oracle.com/en/learn/
Official video	Oracle Cloud Infrastructure YouTube	Webinars, how-tos, and architecture content (search IAM topics): https://www.youtube.com/@OracleCloudInfrastructure

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	OCI fundamentals, DevOps practices, automation, security basics	check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners, build/release engineers	SCM, CI/CD foundations, DevOps workflows	check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations, monitoring, reliability practices	check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability engineers	SRE principles, incident management, reliability engineering	check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams, platform teams	AIOps concepts, observability, automation	check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	Cloud/DevOps training content	Engineers and students	https://rajeshkumar.xyz/
devopstrainer.in	DevOps coaching and workshops	DevOps practitioners	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps services/training resources	Teams needing practical DevOps guidance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and learning resources	Operations/DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting	Cloud architecture, implementation support, operations	OCI landing zone setup; IAM policy design; CI/CD automation hardening	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	Platform engineering, DevOps transformation, automation	IAM and compartment strategy; secure automation user design; operational best practices	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services	Delivery pipelines, infrastructure automation, ops practices	Terraform/IaC rollout; access control reviews; logging/audit integrations	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

Cloud fundamentals: regions, compartments/projects/subscriptions, shared responsibility
Basic security concepts: least privilege, RBAC, credential types, audit logging
OCI basics:
compartments and resource organization
core services you will govern (Compute, Networking, Object Storage)

What to learn after this service

Advanced OCI governance:
logging strategy and retention
audit export pipelines
tagging strategies for cost and compliance
Infrastructure as Code (IaC):
Terraform with OCI Resource Manager
policy-as-code review workflows
Workload identity patterns:
dynamic groups and instance/resource principals at scale
Security services:
Vault (secrets/keys)
Cloud Guard / Security Zones (where applicable)

Job roles that use it

Cloud engineer (OCI)
Solutions architect / cloud architect
DevOps engineer / platform engineer
Site reliability engineer (SRE)
Security engineer / cloud security engineer
Cloud operations engineer

Certification path (if available)

Oracle offers OCI certifications. The exact certification names and requirements change over time, so: – Verify current OCI certification tracks on Oracle University / Oracle certification pages (official). – Focus on IAM as a core domain in architect, security, and operations certifications.

Project ideas for practice

Build a multi-compartment landing zone and delegated admin model.
Implement a “read-only auditor” role that can inspect resources and read audit logs.
Create a CI/CD automation user with minimal permissions to deploy a single service.
Implement dynamic group-based access for a compute instance to read from Object Storage.
Set up an audit export pipeline to Object Storage (and optionally forward to a SIEM).

22. Glossary

IAM (Identity and Access Management): The service that controls authentication and authorization for cloud resources.
IAM without Identity Domains: OCI classic IAM model where users/groups/policies are managed at the tenancy level without identity domain constructs.
Tenancy: The top-level OCI account boundary that contains resources, compartments, and IAM configuration.
User: A human identity in OCI IAM (local to the tenancy).
Group: A collection of users; policies usually grant permissions to groups.
Policy: Authorization rules written in OCI policy language that grant groups (or dynamic groups) permissions.
Policy statement: A single rule line such as Allow group ... to manage ... in compartment ....
Verb (policy language): Permission level such as inspect, read, use, manage.
Compartment: Logical container for OCI resources; used for isolation, delegation, and policy scoping.
OCID: Oracle Cloud Identifier, a globally unique ID for OCI resources.
Dynamic group: A group for OCI resources (not humans) defined by matching rules.
Instance principal / resource principal: A method for OCI resources to authenticate to OCI APIs without user keys (exact applicability depends on service).
API signing key: RSA key pair used to sign OCI API requests (private key local, public key uploaded to OCI).
Fingerprint: Identifier of an uploaded public key, used by OCI to match requests to a key.
Auth token: Token used for certain non-signing integrations.
Customer secret key: Key pair used for S3-compatible Object Storage access patterns.
Federation: Using an external identity provider for authentication (commonly SAML), instead of local OCI users.
Audit log: Record of API calls and changes captured by OCI Audit.

23. Summary

IAM without Identity Domains in Oracle Cloud is the classic OCI IAM model used to manage users, groups, compartments, policies, and credentials to enforce least-privilege access across OCI services in the Security, Identity, and Compliance category.

It matters because every OCI API request depends on IAM for authorization, and a good IAM design: – reduces breach risk and accidental changes – enables clean delegation across teams – improves auditability and compliance readiness

Cost-wise, IAM itself is typically not the direct cost driver, but it strongly influences spend by controlling who can provision and change metered services (compute, storage, logging, and network egress).

Use IAM without Identity Domains when your tenancy operates in the classic model and you want clear, compartment-scoped governance with OCI-native policy controls. Next, deepen your skills by implementing dynamic groups for workload identity and by integrating Audit logs into your security monitoring pipeline using official OCI documentation and architecture guidance.

rajeshkumar

Category

1. Introduction

What this service is

One-paragraph simple explanation

One-paragraph technical explanation

What problem it solves

2. What is IAM without Identity Domains?

Official purpose

Core capabilities (high level)

Major components

Service type

Scope: regional/global/zonal?

How it fits into the Oracle Cloud ecosystem

3. Why use IAM without Identity Domains?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose it

When they should not choose it

4. Where is IAM without Identity Domains used?

Industries

Team types

Workloads

Architectures

Real-world deployment contexts

Production vs dev/test usage

5. Top Use Cases and Scenarios

1) Build a compartment-based landing zone

2) Enforce least-privilege for Object Storage access

3) Secure CI/CD pipelines with scoped API keys

4) Enable workloads to call OCI APIs without stored secrets

5) Delegate network administration without tenancy admin

6) Centralize user lifecycle with federation

7) Separate duties for security monitoring and incident response

8) Manage cross-team shared services safely

9) Implement environment isolation for compliance

10) Control access for third-party vendors

11) Limit access by source network (where applicable)

12) Provide break-glass administration

6. Core Features

6.1 Users (local OCI identities)

6.2 Groups and group membership

6.3 Compartments (resource isolation and delegation)

6.4 Policies (OCI policy language)

6.5 Dynamic groups (workload identity)

6.6 Instance principals / resource principals (where applicable)

6.7 API keys (request signing) for OCI CLI/SDK

6.8 Auth tokens (for certain API patterns)

6.9 Customer secret keys (S3 compatibility scenarios)

6.10 Federation (external identity provider trust)

6.11 Auditability (via OCI Audit service)

7. Architecture and How It Works

Service architecture at a high level

Request/data/control flow

Integrations with related services

Dependency services

Security/authentication model (summary)

Networking model

Monitoring/logging/governance considerations

Simple architecture diagram (Mermaid)

Production-style architecture diagram (Mermaid)

8. Prerequisites

Tenancy/account requirements

Permissions/IAM roles

Billing requirements

Tools needed

Region availability

Quotas/limits

Prerequisite services (for the lab)

9. Pricing / Cost

Current pricing model (accurate framing)

Pricing dimensions you must understand

Free tier considerations

Cost drivers in IAM-centric designs

Hidden or indirect costs

Network/data transfer implications

How to optimize cost (IAM angle)

Example low-cost starter estimate (conceptual)