OCI Identity Architecture & Authorization Flow

Background & Early OCI IAM Architecture

  • OCI’s identity service originally launched as a standalone product ("OCI IAM")
    • Architecture deliberately simple: divided into two functional layers
      • IDCP (Identity Control Plane) – accepted management/control requests
      • Identity Data Plane – stored identity objects
    • Supported only a handful of operations at first:
      • User create
      • Group create / full CRUD
      • Group ↔︎ User membership management
      • IAM Policy definition (called simply “policy” in early days)
    • “Charm” of the initial system: minimal, easy to reason about, but clearly limited in features

CRUD Operations & Audit Flow (Original Model)

  • All management actions ("CRUD from the CP") were routed through IDCP
    • End-user → IDCP → performs requested CRUD → persists in Data Plane
  • Supported resource types beyond users & groups:
    • Policies
    • Network Sources (allowing IP-based restrictions)
  • Every control-plane call automatically produced OCI Audit records
    • Ensured compliance & troubleshooting visibility

Introduction of IDCS & Its Logging Strategy

  • IDCS (Oracle Identity Cloud Service) came later as a separate, cloud-native identity suite
    • Maintains its own audit/event tables inside an RDBMS
    • Emits additional tech-ops logs through “Lumberjack” pipeline, e.g.:
      • OAuth-related logs
      • Control-plane REST logs
    • Originally comprised ≈ 15–2015\text{–}20 individual micro-services
      • Each micro-service handled both control-plane & data-plane functions internally (no explicit split)
      • At least 1414 micro-services still exist today after platform changes

2021 Re-platforming & System Merge

  • 02 / 2021: major consolidation effort
    • Lumberjack log streams merged between OCI IAM & IDCS
    • Goal: move toward a single identity backplane while preserving historical behaviour

Present-Day High-Level Components

  1. IDCP (Identity Control Plane)
    • Handles audit for identity CRUD but now delegates user & group objects to IDCS
  2. IDDP (Identity Data & Decision Plane)
    • Hosts & evaluates IAM policy statements
    • Still stores/serves Network Sources
    • Continues to issue access-decision logs (NOT audit logs)
  3. IDCS (cloud identity micro-services)
    • Now the system of record for Users & Groups
    • Each service keeps its own control-plane + data-plane logic
    • Exposes real-time APIs for CRUD and operational queries

Resulting migration:

  • User & Group tables moved from IDDP → IDCS
  • Policy & Network Sources remain in IDDP
  • IDCP continues to emit classic Audit records for management actions

Policy Lifecycle & Logging Streams

  • Create / modify / delete Policy
    • Action routed to IDCP → persisted in IDDP → audit log entry generated
  • Runtime authorization checks
    • Produce access logs (NOT audit)
    • Logs shipped to Object Storage, then forwarded to Secure Data Warehouse (SDW) to power tools such as the Policy Simulator

Request Flow & Authorization Path (“Splat” Example)

  1. Caller invokes a service API endpoint; e.g., “read bucket”
  2. Splat (front-end auth gateway) intercepts
    • Performs minimal / “vanilla” JWT validation – confirms signature only, nothing else
  3. Splat derives resource context via the target service
    • e.g., bucket-name, tags, service-specific context variables
    • Captures request context: caller IP, timestamp, etc.
  4. Splat (or in some cases the language SDK) sends an authorization request to IDDP
    • Payload: principal (subject), resource context, request context

IDDP Evaluation Logic

  • Extract subject
    • For humans → look up Group memberships (now in IDCS)
    • For non-human principals (instances, functions) → evaluate Dynamic Resource Groups (DRGs)
  • Evaluate policies in order until a match is found
    • On first ALLOW → returns “permission granted”
    • If no match → implicit DENY
  • Needs both resource context and request context; therefore every authorization decision must be routed via the service layer, not executed in isolation

Terminology & Quick Reference

  • Audit Log – immutable record of management activity (user CRUD, policy CRUD, etc.)
  • Access Log – runtime record of authorization decisions (allow/deny)
  • Network Source – CIDR/IP objects used in policy & token conditions
  • Dynamic Resource Group – rule-based grouping for non-human principals
  • Splat – gateway/proxy enforcing coarse token validation before passing to IDDP

Practical & Operational Implications

  • Separation of concerns ensures scalability:
    • IDCS specializes in identity CRUD & token services
    • IDDP remains the authoritative policy engine
  • Engineers must integrate with Lumberjack & Object Storage for log analysis; platform tools (e.g., Policy Simulator) rely on these streams
  • Minimal JWT checks at gateway mean security posture relies heavily on policy evaluation; malicious or misconfigured tokens might pass Splat but fail in IDDP
  • Service teams must always forward full resource & request context; missing context ⇒ incorrect authorization results

Recap – End-to-End Call Sequence Example (“Read Bucket”)

  1. User’s token attached to API call
  2. Splat validates signature, gathers bucket metadata
  3. Splat sends auth payload to IDDP
  4. IDDP queries IDCS for group membership, DRG membership
  5. Policy evaluation → “ALLOW” found → request proceeds
  6. Storage service returns bucket data to user
  7. Access decision logged (Object Storage + SDW); no audit record generated because no control-plane update occurred

Key Takeaways for the Exam

  • Memorize the three core components (IDCP, IDDP, IDCS) & their responsibilities
  • Distinguish Audit vs Access logs and know where each is stored
  • Understand that users/groups now live in IDCS, while policy stays in IDDP
  • Be able to narrate the authorization flow (Splat → IDDP) and why context is critical
  • Remember the 02/2021 consolidation and the presence of 1414+ micro-services in IDCS after re-platforming