{"id":977,"date":"2026-04-17T08:42:02","date_gmt":"2026-04-17T08:42:02","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-iam-with-identity-domains-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/"},"modified":"2026-04-17T08:42:02","modified_gmt":"2026-04-17T08:42:02","slug":"oracle-cloud-iam-with-identity-domains-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-iam-with-identity-domains-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/","title":{"rendered":"Oracle Cloud IAM with Identity Domains Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, Identity, and Compliance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security, Identity, and Compliance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p>IAM with Identity Domains is Oracle Cloud\u2019s identity and access management approach that uses <strong>Identity Domains<\/strong> to manage workforce identities (users, groups, sign-in policies, MFA, federation) and connect them to <strong>Oracle Cloud Infrastructure (OCI)<\/strong> authorization (policies, compartments, resources).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Simple explanation (one paragraph)<\/h3>\n\n\n\n<p>If you need to control <strong>who can sign in<\/strong> to Oracle Cloud, <strong>how they authenticate<\/strong> (password, MFA, SSO), and <strong>what they can do<\/strong> once signed in (read, manage, administer resources), IAM with Identity Domains gives you the identity layer (users\/groups\/authentication) and integrates with OCI\u2019s resource authorization model (policies\/compartments) so you can apply least-privilege access in a structured, auditable way.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Technical explanation (one paragraph)<\/h3>\n\n\n\n<p>Technically, an <strong>Identity Domain<\/strong> is a logical identity boundary in Oracle Cloud where you define and govern identities (users, groups), authentication controls (password policies, MFA, sign-on policies), federation to external IdPs (SAML 2.0 \/ OIDC), and lifecycle automation (for example, SCIM provisioning). OCI then evaluates authorization through IAM <strong>policies<\/strong> and <strong>compartments<\/strong> to decide whether an authenticated principal can call APIs or access resources. This separation helps enterprises centralize identity governance while keeping OCI resource authorization consistent and scalable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>IAM with Identity Domains solves common cloud governance problems:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Securely onboarding\/offboarding people and partners<\/li>\n<li>Enforcing MFA and sign-in policies for console and application access<\/li>\n<li>Integrating Oracle Cloud access with corporate identity providers (SSO)<\/li>\n<li>Mapping business roles (groups) to OCI permissions (policies) across compartments<\/li>\n<li>Reducing credential sprawl and improving auditability for compliance<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Naming note (important): Oracle has historically used <strong>Oracle Identity Cloud Service (IDCS)<\/strong> terminology. In OCI, the strategic direction is <strong>IAM with Identity Domains<\/strong> (often surfaced in the console as <strong>Domains<\/strong> under Identity &amp; Security). If you encounter \u201cIDCS\u201d in older guides, treat it as legacy naming and <strong>verify current behavior in official docs<\/strong> for your tenancy and domain type.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is IAM with Identity Domains?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose (practical summary)<\/h3>\n\n\n\n<p>IAM with Identity Domains is used to <strong>manage identities and authentication<\/strong> (users, groups, MFA, federation, SSO) and to integrate those identities into OCI so they can be <strong>authorized<\/strong> to access OCI resources using <strong>OCI IAM policies<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Core capabilities typically include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity management<\/strong>: users, groups, attributes, lifecycle states<\/li>\n<li><strong>Authentication controls<\/strong>: password policies, MFA enrollment and enforcement, sign-on policies<\/li>\n<li><strong>Federation\/SSO<\/strong>: integrate with external identity providers (for example, enterprise IdPs) using common protocols (SAML 2.0 and\/or OIDC, depending on configuration)<\/li>\n<li><strong>Application integration<\/strong>: enterprise app SSO catalogs and assignments (availability depends on domain capabilities\/edition\u2014verify in official docs)<\/li>\n<li><strong>Provisioning and automation<\/strong>: SCIM provisioning for user\/group lifecycle (common in enterprise patterns\u2014verify for your domain)<\/li>\n<li><strong>OCI integration<\/strong>: use domain-managed users\/groups as principals for OCI Console and API access, governed by OCI policies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>While exact console labels can vary, the typical components you work with are:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity Domain<\/strong>: the boundary that contains identities, authentication settings, and integrations.<\/li>\n<li><strong>Users<\/strong>: human identities (employees, contractors, partners) who sign in.<\/li>\n<li><strong>Groups<\/strong>: collections of users aligned to roles (e.g., \u201cApp-Operators\u201d, \u201cBilling-Viewers\u201d).<\/li>\n<li><strong>Administrative roles<\/strong>: domain-level admin roles (separate from OCI resource permissions).<\/li>\n<li><strong>Sign-on \/ security policies<\/strong>: rules for session control, MFA requirements, and access conditions (exact features can differ by domain type\u2014verify).<\/li>\n<li><strong>Identity providers (IdPs)<\/strong>: external systems used for SSO\/federation.<\/li>\n<li><strong>Applications<\/strong>: SSO-integrated apps (including OCI Console as an app), and potentially other SaaS apps (depending on domain capabilities).<\/li>\n<li><strong>Audit and reporting<\/strong>: logs\/events for identity changes and sign-in events (also complemented by OCI Audit for API calls).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>This is a <strong>control-plane<\/strong> security service (identity and access management). It is foundational: you configure it once and it governs access to many other services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (tenancy\/account and domain boundaries)<\/h3>\n\n\n\n<p>IAM with Identity Domains is <strong>tenancy-scoped<\/strong> (Oracle Cloud account\/tenancy), with <strong>domain-scoped<\/strong> identity boundaries inside the tenancy.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Tenancy<\/strong>: the top-level OCI account boundary that owns compartments, policies, and resources.<\/li>\n<li><strong>Identity domains within the tenancy<\/strong>: one or more domains that hold users and groups.<\/li>\n<\/ul>\n\n\n\n<p>Availability of multiple domains, domain types, and feature sets can depend on how your Oracle Cloud account was set up and what subscriptions you have. <strong>Verify your tenancy\u2019s domain capabilities in the OCI Console and official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Oracle Cloud ecosystem<\/h3>\n\n\n\n<p>In OCI you typically use:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity Domains<\/strong> for: workforce identity, authentication, MFA, SSO, and federation<\/li>\n<li><strong>OCI IAM (policies\/compartments)<\/strong> for: authorization to OCI resources<\/li>\n<li><strong>OCI Audit<\/strong> for: immutable records of API activity in the tenancy<\/li>\n<li><strong>OCI Logging \/ Events \/ Cloud Guard<\/strong> for: operational security monitoring (where applicable)<\/li>\n<\/ul>\n\n\n\n<p>Official docs starting points:\n&#8211; OCI IAM documentation: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Identity\/home.htm<br\/>\n&#8211; Identity Domains overview (verify current URL\/structure within the IAM docs): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Identity\/identity-domains\/overview.htm (If this exact page changes, navigate from the IAM docs home.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use IAM with Identity Domains?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster onboarding and safer offboarding<\/strong>: centralize identity lifecycle so access can be granted and removed reliably.<\/li>\n<li><strong>Support for enterprise SSO<\/strong>: reduce password fatigue and help meet corporate access standards.<\/li>\n<li><strong>Auditability and compliance<\/strong>: show who has access and who did what, which supports audits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separation of concerns<\/strong>: identity\/authentication in domains; authorization to OCI resources through policies and compartments.<\/li>\n<li><strong>Standard protocols<\/strong>: leverage SAML\/OIDC\/SCIM patterns rather than building custom integrations.<\/li>\n<li><strong>Consistent access model<\/strong>: group-to-policy mapping supports scalable permission management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Role-based administration<\/strong>: delegate identity administration without giving blanket tenancy admin access.<\/li>\n<li><strong>Repeatable patterns<\/strong>: consistent constructs (domains, groups, policies) are easier to automate and document.<\/li>\n<li><strong>Reduced \u201csnowflake\u201d access<\/strong>: fewer one-off permissions tied to individual users.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MFA enforcement<\/strong>: reduce risk of credential theft.<\/li>\n<li><strong>Central policy enforcement<\/strong>: standardize sign-in and session controls.<\/li>\n<li><strong>Least privilege<\/strong>: map job roles to minimal OCI permissions via policies.<\/li>\n<li><strong>Better visibility<\/strong>: identity events + OCI Audit provide stronger traceability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Group-based access scales<\/strong>: you add\/remove users from groups instead of editing policies repeatedly.<\/li>\n<li><strong>Compartment-based authorization scales<\/strong>: structure permissions by environment\/team\/project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose IAM with Identity Domains when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Workforce access to OCI Console and APIs with strong authentication controls<\/li>\n<li>Centralized group and policy management aligned to org roles<\/li>\n<li>Integration with a corporate identity provider (SSO)<\/li>\n<li>A platform standard for identity governance across OCI projects<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When they should not choose it (or should use complementary services)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you need <strong>workload identity<\/strong> for compute instances, functions, or Kubernetes pods, you will also use <strong>OCI features such as dynamic groups, instance principals, and OKE workload identity<\/strong> (these are not the same as workforce identity domains).<\/li>\n<li>If you require complex customer identity (CIAM) features, branding-heavy login experiences, or advanced consumer identity journeys, you may need a different Oracle identity product or architecture. <strong>Verify current Oracle offerings<\/strong> for customer identity use cases.<\/li>\n<li>If you\u2019re trying to avoid any identity provider and want fully self-managed identity, you could use self-hosted IAM (e.g., Keycloak), but you\u2019ll trade away managed security controls and tight OCI integration.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is IAM with Identity Domains used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Common in industries with strong compliance or identity governance requirements:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services and insurance<\/li>\n<li>Healthcare and life sciences<\/li>\n<li>Public sector and education<\/li>\n<li>Telecommunications<\/li>\n<li>Retail and e-commerce (especially where PCI-adjacent operations exist)<\/li>\n<li>Manufacturing and supply chain<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering \/ cloud center of excellence (CCoE)<\/li>\n<li>Security engineering and IAM teams<\/li>\n<li>DevOps\/SRE teams who manage cloud access<\/li>\n<li>Application teams needing controlled access to compartments\/resources<\/li>\n<li>Compliance and audit teams (read-only access to logs, access reviews)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-team OCI environments organized by compartments<\/li>\n<li>Hybrid identity setups (on-prem AD \/ external IdP + OCI)<\/li>\n<li>Regulated workloads requiring MFA and audit trails<\/li>\n<li>Shared services and landing zones (network, security, logging compartments)<\/li>\n<li>Multi-environment setups (dev\/test\/prod isolation)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Enterprise tenancy<\/strong>: multiple identity domains (if enabled), federation to corporate IdP, strict MFA, delegated administration.<\/li>\n<li><strong>Startup\/small team<\/strong>: single domain, a small number of groups, simple policies, optional MFA enforcement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: enforce MFA, restrict admin roles, audit and review access, integrate SSO, apply least-privilege.<\/li>\n<li><strong>Dev\/test<\/strong>: still enforce basic hygiene (MFA for admins, minimal privileges), but you may use looser policies while you iterate\u2014then tighten before production.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where IAM with Identity Domains is a strong fit. Each includes the problem, why the service fits, and an example.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Secure workforce sign-in to OCI Console (MFA + policies)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Users need console access, but passwords alone are risky and hard to govern.<\/li>\n<li><strong>Why it fits<\/strong>: Identity Domains manage users, MFA, and sign-on policies; OCI policies define what each group can do.<\/li>\n<li><strong>Example<\/strong>: Enforce MFA for \u201cAdministrators\u201d and limit \u201cDevelopers\u201d to dev compartments only.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Corporate SSO federation (SAML\/OIDC) for OCI access<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Separate cloud passwords create security gaps and offboarding delays.<\/li>\n<li><strong>Why it fits<\/strong>: Identity Domains can federate with an external IdP so users authenticate centrally.<\/li>\n<li><strong>Example<\/strong>: Employees log into OCI using the same corporate SSO used for email and HR systems.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Partner and contractor access with limited scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Contractors need short-term access without exposing production resources.<\/li>\n<li><strong>Why it fits<\/strong>: Domain users can be placed into tightly-scoped groups; policies restrict access to specific compartments.<\/li>\n<li><strong>Example<\/strong>: External DBA gets access only to a \u201cmigration\u201d compartment for 30 days.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Delegated identity administration (without tenancy-wide admin)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Central IT cannot handle all access requests.<\/li>\n<li><strong>Why it fits<\/strong>: Identity domain administrative roles can delegate user\/group management to specific admins.<\/li>\n<li><strong>Example<\/strong>: Helpdesk can reset passwords and manage MFA enrollment without changing OCI resource policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Environment isolation using compartments + group mapping<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Dev teams accidentally modify production resources.<\/li>\n<li><strong>Why it fits<\/strong>: Map groups to compartments via OCI policies; isolate dev\/test\/prod.<\/li>\n<li><strong>Example<\/strong>: \u201cApp-Team-A-Dev\u201d can manage compute in Dev compartment but cannot read Prod secrets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Build a least-privilege \u201cread-only audit\u201d role<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Auditors need visibility without any ability to change resources.<\/li>\n<li><strong>Why it fits<\/strong>: Create a domain group and OCI policies granting inspect\/read permissions.<\/li>\n<li><strong>Example<\/strong>: Audit group can view compartments, logs, and configurations but cannot create\/delete.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Centralized access reviews and role cleanup<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Over time, permissions accumulate and become unclear.<\/li>\n<li><strong>Why it fits<\/strong>: Group-based policy mapping makes it easier to enumerate roles and remove stale group memberships.<\/li>\n<li><strong>Example<\/strong>: Quarterly access review checks membership of \u201cNetwork-Admins\u201d and \u201cSecurity-Admins\u201d.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Integrate identity lifecycle with HR or directory (SCIM provisioning)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Manual user creation is error-prone.<\/li>\n<li><strong>Why it fits<\/strong>: Identity domains commonly support automated provisioning patterns (verify your tenant\u2019s options).<\/li>\n<li><strong>Example<\/strong>: When HR marks an employee as terminated, the account is disabled and access removed automatically.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Enforce stronger sign-on rules for privileged users<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Admin accounts are targeted by phishing.<\/li>\n<li><strong>Why it fits<\/strong>: Identity domain security policies can enforce stricter MFA\/session controls for admin groups (capabilities vary\u2014verify).<\/li>\n<li><strong>Example<\/strong>: Administrators must use MFA every sign-in and have shorter session timeouts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Support multiple identity boundaries (separate domains)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: M&amp;A or business units need separation while sharing the same OCI tenancy.<\/li>\n<li><strong>Why it fits<\/strong>: Multiple identity domains can isolate users\/groups and sign-in policies (availability depends on tenancy\/subscription).<\/li>\n<li><strong>Example<\/strong>: \u201cSubsidiary-A Domain\u201d and \u201cCorporate Domain\u201d with different IdPs and admin teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Controlled API access for human users (CLI\/SDK)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Engineers need programmatic access but credentials must be governed.<\/li>\n<li><strong>Why it fits<\/strong>: Combine strong sign-in with controlled issuance of API credentials and tightly scoped OCI policies.<\/li>\n<li><strong>Example<\/strong>: SREs use OCI CLI only for read-only access to logs and metrics compartments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Standardized landing zone for enterprise OCI adoption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Multiple teams adopt OCI without consistent access patterns.<\/li>\n<li><strong>Why it fits<\/strong>: Domain + group + compartment + policy patterns form a repeatable blueprint.<\/li>\n<li><strong>Example<\/strong>: Platform team publishes a \u201cnew project\u201d template: create compartments, groups, policies, and tagging rules.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: Some Identity Domains capabilities can be subscription-, domain-type-, or edition-dependent. If you don\u2019t see a feature in your console, <strong>verify in official Oracle Cloud documentation<\/strong> and your account\u2019s entitlements.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Identity Domains (logical identity boundary)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a container for identity objects and security settings.<\/li>\n<li><strong>Why it matters<\/strong>: Enables separation between identity administration and OCI resource authorization.<\/li>\n<li><strong>Practical benefit<\/strong>: Cleaner governance; supports separation between business units or identity sources.<\/li>\n<li><strong>Caveats<\/strong>: Not every tenancy supports multiple domains; domain creation and features vary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Users and user lifecycle management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Create\/manage human identities with attributes, status, and authentication settings.<\/li>\n<li><strong>Why it matters<\/strong>: Centralizes who can authenticate into Oracle Cloud.<\/li>\n<li><strong>Practical benefit<\/strong>: Easier onboarding\/offboarding; consistent account controls.<\/li>\n<li><strong>Caveats<\/strong>: User identifiers and email workflows can affect sign-in; plan naming conventions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Groups (role-based access building block)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Groups aggregate users for role-based assignment.<\/li>\n<li><strong>Why it matters<\/strong>: OCI policies typically grant permissions to groups\u2014not individual users.<\/li>\n<li><strong>Practical benefit<\/strong>: Add\/remove users without rewriting policies.<\/li>\n<li><strong>Caveats<\/strong>: Avoid group sprawl; align to job roles and compartments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Administrative roles (domain administration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Delegates who can administer the identity domain (users, groups, settings).<\/li>\n<li><strong>Why it matters<\/strong>: Enforces separation of duties (SoD).<\/li>\n<li><strong>Practical benefit<\/strong>: Helpdesk can manage basic identity tasks; security team controls policies.<\/li>\n<li><strong>Caveats<\/strong>: Domain admin \u2260 OCI resource admin. You usually still need OCI policies for resource access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Authentication policies (password, sessions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls password complexity\/rotation rules and session behaviors.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces account takeover risk.<\/li>\n<li><strong>Practical benefit<\/strong>: Standardize security posture across the tenancy.<\/li>\n<li><strong>Caveats<\/strong>: Overly strict password rotation can reduce security in practice\u2014prefer MFA + modern guidance where allowed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Multi-Factor Authentication (MFA)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Adds a second factor to authentication.<\/li>\n<li><strong>Why it matters<\/strong>: Mitigates credential theft and phishing risk (not all phishing, but significantly reduces impact).<\/li>\n<li><strong>Practical benefit<\/strong>: Stronger protection for console access and privileged actions.<\/li>\n<li><strong>Caveats<\/strong>: Enrollment and recovery processes must be planned; enforce MFA especially for admins.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Federation \/ Single Sign-On (SSO) to external IdPs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets users authenticate through a corporate IdP (SAML\/OIDC patterns).<\/li>\n<li><strong>Why it matters<\/strong>: Centralizes authentication and offboarding; aligns with enterprise security.<\/li>\n<li><strong>Practical benefit<\/strong>: Users sign in with corporate credentials; less password management.<\/li>\n<li><strong>Caveats<\/strong>: Misconfiguration can lock out admins\u2014keep break-glass accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Application integration (including OCI Console as an app)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Represents target applications for SSO and access assignments.<\/li>\n<li><strong>Why it matters<\/strong>: Allows consistent assignment and policy enforcement.<\/li>\n<li><strong>Practical benefit<\/strong>: Streamlined user access to OCI and potentially other apps.<\/li>\n<li><strong>Caveats<\/strong>: The catalog and controls can vary by domain type\/edition.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Provisioning and synchronization (SCIM patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Automates user\/group creation and updates from external systems.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces manual errors and improves lifecycle accuracy.<\/li>\n<li><strong>Practical benefit<\/strong>: HR-driven identity lifecycle; faster offboarding.<\/li>\n<li><strong>Caveats<\/strong>: Requires careful attribute mapping and change management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Auditing and visibility<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides visibility into identity changes and sign-in related events (plus OCI Audit for API calls).<\/li>\n<li><strong>Why it matters<\/strong>: Compliance and incident response require traceability.<\/li>\n<li><strong>Practical benefit<\/strong>: You can answer: \u201cwho changed MFA policy?\u201d or \u201cwho added this user to Admins?\u201d<\/li>\n<li><strong>Caveats<\/strong>: Ensure you know where logs are stored and how long they\u2019re retained (verify retention behavior in your tenancy).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Integration with OCI authorization (policies + compartments)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses domain-managed users\/groups as principals for OCI authorization decisions.<\/li>\n<li><strong>Why it matters<\/strong>: Identity without authorization is incomplete; policies enforce permissions at scale.<\/li>\n<li><strong>Practical benefit<\/strong>: Least-privilege access aligned to compartments and resource types.<\/li>\n<li><strong>Caveats<\/strong>: Policy language and group references must be correct; test with non-prod first.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A user (or federated user) initiates sign-in to Oracle Cloud.<\/li>\n<li>The Identity Domain authenticates them (password\/MFA and\/or redirects to an external IdP).<\/li>\n<li>After authentication, the user receives a session\/tokens for Oracle Cloud access.<\/li>\n<li>When the user performs actions in OCI (console or API), OCI evaluates <strong>authorization<\/strong> using:\n   &#8211; the user\u2019s group memberships from the identity domain\n   &#8211; the requested resource\u2019s compartment\n   &#8211; IAM policies that grant or deny actions<\/li>\n<li>Activity is captured in logs:\n   &#8211; identity events (domain)\n   &#8211; OCI API activity in <strong>OCI Audit<\/strong><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request, data, and control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: Identity configuration changes (user creation, MFA policies, federation setup) occur in the domain.<\/li>\n<li><strong>Data plane<\/strong>: OCI resources (compute, storage, network) are separate services; IAM governs access but does not \u201chold\u201d your application data.<\/li>\n<li><strong>Authorization evaluation<\/strong>: when an OCI API call is made, policies are evaluated to decide if the principal can perform the action.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related Oracle Cloud services<\/h3>\n\n\n\n<p>Common integrations:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Compartments and IAM Policies<\/strong>: define authorization boundaries.<\/li>\n<li><strong>OCI Audit<\/strong>: records API calls and many control-plane actions across OCI services.<\/li>\n<li><strong>OCI Logging<\/strong>: centralize logs (service\/application logs). Identity-domain-specific log integration options can vary\u2014verify.<\/li>\n<li><strong>OCI Cloud Guard<\/strong>: posture management and threat detection; can ingest IAM-related signals in broader governance patterns.<\/li>\n<li><strong>OCI Notifications \/ Events<\/strong>: build automation for governance (e.g., alert when policies change).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A working <strong>OCI tenancy<\/strong><\/li>\n<li><strong>Identity &amp; Security<\/strong> services enabled in the tenancy<\/li>\n<li>A <strong>home region<\/strong> concept (OCI uses a home region for identity-related control plane; exact behavior differs\u2014verify in docs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authentication<\/strong> happens in the Identity Domain (local user auth or federated).<\/li>\n<li><strong>Authorization<\/strong> to OCI resources happens through OCI IAM policy evaluation.<\/li>\n<li>Privileged access should be implemented with:<\/li>\n<li>MFA and strong sign-on policies for admins<\/li>\n<li>least privilege policies<\/li>\n<li>break-glass accounts kept secure and monitored<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>End-user sign-in uses Oracle Cloud public endpoints.<\/li>\n<li>Federation to an external IdP requires HTTPS connectivity between browsers and the IdP; in some setups, SCIM provisioning requires outbound connectivity from the IdP\/provisioning agent to Oracle endpoints.<\/li>\n<li>OCI resources themselves can be private (VCN), but identity endpoints are typically public SaaS-style control plane endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat identity configuration changes as high-risk events:<\/li>\n<li>changes to MFA policy<\/li>\n<li>creation of admin users<\/li>\n<li>changes to federation<\/li>\n<li>policy changes granting broad permissions<\/li>\n<li>Use OCI Audit and your SIEM to monitor and alert on:<\/li>\n<li>policy changes<\/li>\n<li>group membership changes<\/li>\n<li>repeated sign-in failures or suspicious logins (availability depends on log sources\u2014verify)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User \/ Admin] --&gt;|Sign-in| ID[OCI IAM with Identity Domains]\n  ID --&gt;|Authenticated session| C[OCI Console \/ APIs]\n  C --&gt;|API request| P[OCI IAM Policy Evaluation]\n  P --&gt;|Allow\/Deny| R[OCI Resources\\n(Compartments, Buckets, Compute, etc.)]\n  C --&gt; A[OCI Audit Logs]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Corp[Corporate Identity]\n    IDP[External IdP\\n(SAML\/OIDC)]\n    HR[HR \/ Directory]\n  end\n\n  subgraph OCI[Oracle Cloud Tenancy]\n    D1[Identity Domain\\n(Workforce)]\n    D2[Optional: Separate Identity Domain\\n(Partners\/BU)\\nVerify availability]\n    POL[IAM Policies]\n    CMP[Compartments\\n(Prod\/Dev\/Security\/Shared)]\n    RES[OCI Resources\\n(OKE, Compute, DB, Object Storage)]\n    AUD[OCI Audit]\n    LG[OCI Logging]\n    CG[OCI Cloud Guard\\n(optional)]\n  end\n\n  User[Employees\/Contractors] --&gt;|SSO| IDP\n  IDP --&gt;|Federation| D1\n  HR --&gt;|Provisioning (SCIM)\\nVerify support| D1\n\n  D1 --&gt;|Groups| POL\n  POL --&gt;|Authorize| RES\n  RES --&gt; CMP\n\n  POL --&gt; AUD\n  D1 --&gt; LG\n  AUD --&gt; LG\n  LG --&gt; SIEM[External SIEM\/SOC\\n(optional)]\n  CG --&gt; SIEM\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Tenancy \/ account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>Oracle Cloud (OCI) tenancy<\/strong> where you can access <strong>Identity &amp; Security<\/strong>.<\/li>\n<li>Access to <strong>IAM with Identity Domains<\/strong> in the OCI Console (typically under <em>Identity &amp; Security \u2192 Domains<\/em>).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ roles required<\/h3>\n\n\n\n<p>You will need permissions to:\n&#8211; Manage identity domain objects (users\/groups) <strong>in the domain<\/strong>\n&#8211; Create or manage OCI policies and compartments <strong>in the tenancy<\/strong><\/p>\n\n\n\n<p>In many environments, these are separated:\n&#8211; Domain admin role(s) for identity management\n&#8211; Tenancy\/compartment admin permissions for OCI policy and compartment management<\/p>\n\n\n\n<p>If you do not have both, coordinate with your OCI tenancy administrators.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many IAM capabilities are foundational and often available without direct metering, but <strong>do not assume<\/strong> premium identity features are free.<\/li>\n<li>If you plan to create test resources (like Object Storage buckets) you may incur minimal costs depending on your account\/free tier.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools (optional but useful)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web browser to access the <strong>OCI Console<\/strong><\/li>\n<li><strong>OCI CLI<\/strong> (optional) for verification steps: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/SDKDocs\/cliinstall.htm  <\/li>\n<li>SSH\/key tools (optional) if you later use compute instances<\/li>\n<li>Access to an email inbox for user invitation\/activation flows (common in identity systems)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI uses regions; identity administration has a \u201chome region\u201d concept and domain endpoints.<\/li>\n<li><strong>Verify identity domain region\/home region behavior in official docs<\/strong> for your tenancy, because it affects where you manage identity and how endpoints are addressed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM and identity services have limits (users, groups, policies, compartments) that depend on tenancy and service constraints.<\/li>\n<li>Check OCI limits in the console (typically <em>Governance &amp; Administration \u2192 Limits, Quotas and Usage<\/em>) and IAM docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services for the lab<\/h3>\n\n\n\n<p>For the hands-on tutorial in this article, you\u2019ll need:\n&#8211; An identity domain you can administer (often the \u201cDefault\u201d domain)\n&#8211; Permission to create:\n  &#8211; one compartment (or use an existing sandbox compartment)\n  &#8211; one Object Storage bucket (optional but recommended for verification)\n  &#8211; one OCI policy<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (how to think about cost)<\/h3>\n\n\n\n<p>IAM with Identity Domains sits at the foundation of Oracle Cloud security. In many Oracle Cloud setups:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Core OCI IAM authorization features<\/strong> (policies, compartments, basic identity for OCI access) are typically part of the platform experience.<\/li>\n<li><strong>Identity Domains capabilities<\/strong> may include features that, in some contexts, are associated with Oracle identity subscriptions (for example, advanced identity governance, app catalog features, or higher-tier security capabilities).<\/li>\n<\/ul>\n\n\n\n<p>Because Oracle\u2019s identity capabilities can be bundled differently across OCI accounts and commercial agreements, you should treat pricing as:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Plan\/edition dependent<\/strong> (features available in your identity domain)<\/li>\n<li><strong>User-count dependent<\/strong> in some subscription models (common across identity products)<\/li>\n<li><strong>Contract dependent<\/strong> (enterprise agreements may bundle identity)<\/li>\n<\/ul>\n\n\n\n<p>Do not rely on blog posts for exact prices; use Oracle\u2019s official price list and your Oracle contract.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Oracle Cloud Price List: https:\/\/www.oracle.com\/cloud\/price-list\/<\/li>\n<li>Oracle Cloud Pricing page (overview): https:\/\/www.oracle.com\/cloud\/pricing\/<\/li>\n<li>OCI Cost Management and Billing docs: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Billing\/home.htm<\/li>\n<li>OCI Cost Estimator\/Calculator (if applicable in your region\/program): https:\/\/www.oracle.com\/cloud\/costestimator.html (verify current tool availability)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to expect<\/h3>\n\n\n\n<p>Depending on your setup, pricing may be influenced by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Number of active users<\/strong> in an identity domain (common identity subscription dimension)<\/li>\n<li><strong>Enabled feature tier\/edition<\/strong> for identity capabilities<\/li>\n<li><strong>Add-on governance\/security modules<\/strong> (if purchased separately)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (direct and indirect)<\/h3>\n\n\n\n<p>Even if IAM itself does not appear as a metered line item in your tenancy bill, IAM decisions drive real costs:<\/p>\n\n\n\n<p><strong>Direct<\/strong>\n&#8211; Potential per-user licensing for advanced identity features (verify your plan)<\/p>\n\n\n\n<p><strong>Indirect<\/strong>\n&#8211; <strong>Operational overhead<\/strong>: time spent managing access, audits, and incident response\n&#8211; <strong>Logging\/SIEM ingestion<\/strong>: centralizing logs may increase Logging or external SIEM costs\n&#8211; <strong>Network egress<\/strong>: federation and SIEM export can increase outbound data transfer (depends on architecture and region)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity flows are control plane and relatively low bandwidth.<\/li>\n<li>Federation to an external IdP is mostly browser-based and low cost.<\/li>\n<li>Exporting audit\/log data to external SIEMs can generate meaningful egress and ingestion costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Storage\/compute\/API\/request pricing factors<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>IAM policy evaluation is part of the platform control plane experience; you generally don\u2019t size it like compute.<\/li>\n<li>However, <strong>downstream services<\/strong> you grant access to (Object Storage, Logging, Monitoring) have their own costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize paid identity features if not needed; prefer native OCI patterns for authorization.<\/li>\n<li>Reduce group sprawl and policy sprawl: fewer objects can reduce admin overhead.<\/li>\n<li>Centralize logging thoughtfully:<\/li>\n<li>collect what you need for compliance<\/li>\n<li>avoid high-volume debug logs in production<\/li>\n<li>Prefer federation to reduce password reset overhead and security risk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual, no fabricated numbers)<\/h3>\n\n\n\n<p>A small team can often start with:\n&#8211; One identity domain (default)\n&#8211; A handful of users and groups\n&#8211; A small number of policies and compartments\n&#8211; MFA enabled for admins\n&#8211; Minimal test resources (like a single bucket)<\/p>\n\n\n\n<p>Your incremental costs may be near-zero <strong>for IAM itself<\/strong> in many tenancies, but verify whether your identity domain features require licensing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, cost planning should include:\n&#8211; Identity subscription costs (if applicable): user counts, feature tier\n&#8211; SOC\/SIEM ingestion of identity and audit logs\n&#8211; Engineering time for access reviews and automation\n&#8211; Additional domains (if used) and any associated licensing\/administration overhead<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a <strong>least-privilege access setup<\/strong> using IAM with Identity Domains in Oracle Cloud:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use an Identity Domain to create a <strong>group<\/strong> and a <strong>user<\/strong><\/li>\n<li>Enforce good sign-in hygiene (MFA guidance)<\/li>\n<li>Create an OCI <strong>compartment<\/strong><\/li>\n<li>Create an OCI <strong>policy<\/strong> granting the group limited permissions in that compartment<\/li>\n<li>Verify access by signing in as the new user and performing a read-only task<\/li>\n<li>Clean up resources safely<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build this small access model:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity Domain:<\/li>\n<li>Group: <code>App-Observers<\/code><\/li>\n<li>User: <code>app.observer<\/code><\/li>\n<li>OCI:<\/li>\n<li>Compartment: <code>lab-iam-domain<\/code><\/li>\n<li>Policy: allow the group to <strong>read<\/strong> Object Storage resources in that compartment<\/li>\n<li>(Optional) Bucket: <code>lab-verify-bucket<\/code> for a tangible verification target<\/li>\n<\/ul>\n\n\n\n<p><strong>Expected outcome<\/strong>: The new user can sign in and view\/list Object Storage details in the lab compartment, but cannot administer unrelated resources.<\/p>\n\n\n\n<blockquote>\n<p>Safety note: This lab is designed to be low-risk and low-cost, but always perform it in a sandbox compartment\/tenancy if possible.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Confirm you are using IAM with Identity Domains (and identify your domain)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Sign in to the <strong>OCI Console<\/strong> with an administrator account.<\/li>\n<li>Navigate to <strong>Identity &amp; Security<\/strong>.<\/li>\n<li>Find <strong>Domains<\/strong> (or <strong>Identity Domains<\/strong> depending on console layout).<\/li>\n<li>Identify the domain you will use for the lab. Many tenancies have a <strong>Default<\/strong> domain.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You can see at least one identity domain and you can open it to view settings and users\/groups.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the domain, confirm you can view <strong>Users<\/strong> and <strong>Groups<\/strong> menus.<\/p>\n\n\n\n<p><strong>Common issue<\/strong>\n&#8211; If you don\u2019t see Domains: your account may be using an older tenancy model or your permissions are insufficient. Coordinate with your tenancy administrator and <strong>verify in OCI IAM docs<\/strong> for your tenancy type.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a compartment for the lab (OCI authorization boundary)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the OCI Console, go to <strong>Identity &amp; Security \u2192 Compartments<\/strong> (console navigation may differ slightly).<\/li>\n<li>Click <strong>Create Compartment<\/strong>.<\/li>\n<li>Enter:\n   &#8211; <strong>Name<\/strong>: <code>lab-iam-domain<\/code>\n   &#8211; <strong>Description<\/strong>: <code>Lab compartment for IAM with Identity Domains tutorial<\/code>\n   &#8211; <strong>Parent Compartment<\/strong>: choose a sandbox parent (often the root compartment, but prefer a non-root sandbox if your org has one)<\/li>\n<li>Create the compartment.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A new compartment named <code>lab-iam-domain<\/code> exists.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Open the compartment details page and confirm its state is <strong>Active<\/strong>.<\/p>\n\n\n\n<p><strong>Common issue<\/strong>\n&#8211; \u201cNot authorized\u201d when creating a compartment: you need permission to manage compartments in the parent compartment\/tenancy.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a group in the Identity Domain<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go back to <strong>Identity &amp; Security \u2192 Domains<\/strong> and open your chosen domain.<\/li>\n<li>Navigate to <strong>Groups<\/strong>.<\/li>\n<li>Click <strong>Create group<\/strong>.<\/li>\n<li>Enter:\n   &#8211; <strong>Name<\/strong>: <code>App-Observers<\/code>\n   &#8211; <strong>Description<\/strong>: <code>Read-only observers for lab compartment<\/code><\/li>\n<li>Create the group.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Group <code>App-Observers<\/code> is created in the identity domain.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Open the group and confirm it shows no members yet.<\/p>\n\n\n\n<p><strong>Common issue<\/strong>\n&#8211; Naming constraints: if your organization enforces naming conventions, adjust to match them (e.g., <code>grp-lab-app-observers<\/code>).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a user in the Identity Domain and add them to the group<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the same identity domain, go to <strong>Users<\/strong>.<\/li>\n<li>Click <strong>Create user<\/strong>.<\/li>\n<li>Provide user details. Fields vary, but typically include:\n   &#8211; <strong>Username<\/strong>: <code>app.observer<\/code>\n   &#8211; <strong>Email<\/strong>: use an email you can access (for activation\/reset flows)\n   &#8211; <strong>First name \/ Last name<\/strong>: as appropriate<\/li>\n<li>Create the user.<\/li>\n<li>Add the user to the group:\n   &#8211; Open the <code>App-Observers<\/code> group\n   &#8211; Add member <code>app.observer<\/code>\n   &#8211; Save<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; User exists and is a member of <code>App-Observers<\/code>.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the user\u2019s detail page, confirm group membership includes <code>App-Observers<\/code>.<\/p>\n\n\n\n<p><strong>Common issue<\/strong>\n&#8211; Activation email not received:\n  &#8211; check spam\/quarantine\n  &#8211; confirm your organization allows emails from Oracle Cloud\n  &#8211; verify the correct email address was entered<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: (Recommended) Configure MFA expectation for the new user<\/h3>\n\n\n\n<p>Exact steps vary by tenancy\/domain configuration. In many environments, MFA can be:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>enforced by domain sign-on policies, or<\/li>\n<li>required for specific groups\/admin roles<\/li>\n<\/ul>\n\n\n\n<p>Do the following based on what you see in the console:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the identity domain, locate <strong>Security \/ Sign-on \/ MFA<\/strong> settings (menu names differ).<\/li>\n<li>If you have authority to enforce MFA for the domain or for privileged groups:\n   &#8211; Ensure MFA is required at least for administrators\n   &#8211; Optionally enforce MFA for the new user\/group if your org requires it<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The domain has a documented and (ideally) enforced MFA posture.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Check sign-on policies and confirm MFA is required under the intended conditions.<\/p>\n\n\n\n<p><strong>Common issue<\/strong>\n&#8211; MFA policy changes can affect all users. In production, test policy changes with a pilot group and keep a break-glass admin account.<\/p>\n\n\n\n<blockquote>\n<p>If you are unsure which MFA methods are supported in your tenancy, <strong>verify in official IAM with Identity Domains documentation<\/strong> for your domain type.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create a policy that grants the group read-only access in the lab compartment<\/h3>\n\n\n\n<p>Now connect identity (group) to authorization (OCI policy).<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In OCI Console, go to <strong>Identity &amp; Security \u2192 Policies<\/strong>.<\/li>\n<li>Ensure you are creating the policy in the correct place:\n   &#8211; Many orgs create policies in the <strong>root compartment<\/strong> or a dedicated \u201csecurity\u201d compartment.<\/li>\n<li>Click <strong>Create Policy<\/strong>.<\/li>\n<li>Enter:\n   &#8211; <strong>Name<\/strong>: <code>policy-app-observers-read-objectstorage<\/code>\n   &#8211; <strong>Description<\/strong>: <code>Allow App-Observers to read Object Storage in lab-iam-domain<\/code>\n   &#8211; <strong>Compartment<\/strong>: choose where your org stores policies (often root)<\/li>\n<li>Add a policy statement that grants read access to Object Storage in the lab compartment.<\/li>\n<\/ol>\n\n\n\n<p>OCI policy language is precise and can vary based on how groups\/domains are referenced in your tenancy UI. The safest approach is:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use the <strong>Policy Builder<\/strong> (if available) and select:<\/li>\n<li><strong>Group<\/strong>: <code>App-Observers<\/code><\/li>\n<li><strong>Location<\/strong>: compartment <code>lab-iam-domain<\/code><\/li>\n<li><strong>Permission<\/strong>: \u201cread\u201d for Object Storage resources<\/li>\n<\/ul>\n\n\n\n<p>If you need to write a statement manually, use the policy builder to generate it and copy\/paste. If you must draft one, it will look conceptually like:<\/p>\n\n\n\n<pre><code class=\"language-text\">Allow group App-Observers to read object-family in compartment lab-iam-domain\n<\/code><\/pre>\n\n\n\n<p><strong>Important<\/strong>: If your tenancy requires a domain qualifier for group names, the statement may differ. <strong>Generate the statement with the console builder or verify the exact syntax in official docs<\/strong>.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The policy exists and references the <code>App-Observers<\/code> group and the <code>lab-iam-domain<\/code> compartment.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Open the policy and confirm it is in <strong>Active<\/strong> state and contains the intended statement(s).<\/p>\n\n\n\n<p><strong>Common errors and fixes<\/strong>\n&#8211; <strong>Error<\/strong>: Policy validation fails due to group reference.\n  &#8211; <strong>Fix<\/strong>: Use the Policy Builder to select the identity domain group; it will use the correct reference format.\n&#8211; <strong>Error<\/strong>: User still can\u2019t read resources after policy creation.\n  &#8211; <strong>Fix<\/strong>: Wait a few minutes for propagation; then re-login as the user. Confirm the user is in the correct group.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: (Optional but recommended) Create a test bucket to verify access<\/h3>\n\n\n\n<p>If you want a concrete object to list\/read:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Switch compartment to <code>lab-iam-domain<\/code>.<\/li>\n<li>Go to <strong>Storage \u2192 Object Storage &amp; Archive Storage \u2192 Buckets<\/strong>.<\/li>\n<li>Click <strong>Create Bucket<\/strong>.<\/li>\n<li>Name: <code>lab-verify-bucket<\/code> (must be unique within the namespace constraints shown).<\/li>\n<li>Accept defaults for a simple lab and create.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A bucket exists in the <code>lab-iam-domain<\/code> compartment.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; You can see <code>lab-verify-bucket<\/code> in the bucket list.<\/p>\n\n\n\n<p><strong>Cost note<\/strong>\n&#8211; A small empty bucket is typically low cost, but billing depends on your account and region. Delete it during cleanup.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Sign in as the new user and verify least-privilege access<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open a private\/incognito browser window.<\/li>\n<li>Sign in as <code>app.observer<\/code> using the Identity Domain sign-in flow.<\/li>\n<li>Navigate to the <code>lab-iam-domain<\/code> compartment.<\/li>\n<li>Try to list Object Storage buckets (or open <code>lab-verify-bucket<\/code> if you created it).<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The user can view\/list the bucket(s) and Object Storage details in the lab compartment.\n&#8211; The user should <strong>not<\/strong> have permissions to create\/delete unrelated resources outside this scope.<\/p>\n\n\n\n<p><strong>Verification checks<\/strong>\n&#8211; Positive test: user can view buckets in <code>lab-iam-domain<\/code>.\n&#8211; Negative test: user cannot create a new compartment or manage IAM policies.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>[ ] Compartment <code>lab-iam-domain<\/code> exists<\/li>\n<li>[ ] Identity domain group <code>App-Observers<\/code> exists<\/li>\n<li>[ ] User <code>app.observer<\/code> exists and is in <code>App-Observers<\/code><\/li>\n<li>[ ] Policy <code>policy-app-observers-read-objectstorage<\/code> exists and targets <code>lab-iam-domain<\/code><\/li>\n<li>[ ] User can sign in successfully<\/li>\n<li>[ ] User can read Object Storage resources in <code>lab-iam-domain<\/code><\/li>\n<li>[ ] User cannot perform privileged tenancy-wide tasks<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: User can\u2019t sign in<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm the user is <strong>activated\/enabled<\/strong>.<\/li>\n<li>Confirm you\u2019re using the correct <strong>domain sign-in page<\/strong> (tenancies can have multiple domains).<\/li>\n<li>If federated, confirm IdP assignment and federation configuration (SSO misconfig is common).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: User signs in but sees \u201cNot authorized\u201d everywhere<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm you created an OCI <strong>policy<\/strong> granting access to at least one resource family in a compartment.<\/li>\n<li>Confirm the policy references the correct <strong>group<\/strong> and <strong>compartment<\/strong>.<\/li>\n<li>Confirm the user is a <strong>member of the group<\/strong> you referenced.<\/li>\n<li>Wait for propagation (a few minutes), then sign out\/in again.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Policy statement errors<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use the console\u2019s policy builder to generate correct syntax.<\/li>\n<li>Verify you\u2019re writing policies in the correct compartment scope (root vs child compartments can matter for management).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: You can\u2019t find \u201cDomains\u201d in the console<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your tenancy might be configured differently, or your IAM permissions don\u2019t include domain access.<\/li>\n<li>Check with your Oracle Cloud admin and verify with IAM docs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing access and reduce clutter:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Remove the user from the group <code>App-Observers<\/code>.<\/li>\n<li>Disable or delete the user <code>app.observer<\/code> (follow your org\u2019s retention policy).<\/li>\n<li>Delete the policy <code>policy-app-observers-read-objectstorage<\/code>.<\/li>\n<li>(If created) Delete the bucket <code>lab-verify-bucket<\/code>:\n   &#8211; Ensure it is empty (delete objects first).<\/li>\n<li>Delete the compartment <code>lab-iam-domain<\/code> (compartment deletion can take time; ensure no resources remain).<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Lab-created identity objects and OCI resources are removed or disabled according to policy.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a <strong>landing zone<\/strong> approach:<\/li>\n<li>root compartment for tenancy-wide governance<\/li>\n<li>separate compartments for security, network, shared services, and workloads<\/li>\n<li>Keep identity management (domains\/users\/groups) and authorization (policies\/compartments) cleanly mapped.<\/li>\n<li>Use <strong>separate compartments for environments<\/strong> (dev\/test\/prod) and restrict cross-environment access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>group-based permissions<\/strong>, not user-specific permissions.<\/li>\n<li>Implement <strong>least privilege<\/strong>:<\/li>\n<li>start with read-only<\/li>\n<li>elevate only when required<\/li>\n<li>avoid broad statements like \u201cmanage all-resources\u201d except for minimal admin groups<\/li>\n<li>Enforce <strong>MFA<\/strong> for:<\/li>\n<li>all admins<\/li>\n<li>any user with write access to production<\/li>\n<li>Keep <strong>break-glass accounts<\/strong>:<\/li>\n<li>local to the domain (not federated)<\/li>\n<li>MFA protected<\/li>\n<li>credentials stored in an enterprise password vault<\/li>\n<li>monitored with alerting<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid unnecessary paid identity features if your use case is purely OCI workforce access.<\/li>\n<li>Centralize logs intelligently; don\u2019t export everything at high volume to a SIEM without a retention strategy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize policy complexity:<\/li>\n<li>fewer, clearer policies are easier to troubleshoot<\/li>\n<li>avoid overlapping policies that create confusion during audits<\/li>\n<li>Use a consistent naming convention so teams can find the correct group\/policy quickly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid single points of failure in identity:<\/li>\n<li>if federating, ensure the external IdP is highly available<\/li>\n<li>maintain local emergency access<\/li>\n<li>Document recovery procedures:<\/li>\n<li>MFA reset steps<\/li>\n<li>IdP federation rollback steps<\/li>\n<li>incident response steps for compromised accounts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Perform regular access reviews:<\/li>\n<li>privileged groups<\/li>\n<li>production write-access groups<\/li>\n<li>dormant accounts<\/li>\n<li>Monitor for high-risk changes:<\/li>\n<li>policy changes<\/li>\n<li>group membership changes for admin groups<\/li>\n<li>federation configuration changes<\/li>\n<li>Automate onboarding\/offboarding where possible (SCIM patterns) and validate attribute mappings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Adopt a naming standard:<\/li>\n<li>groups: <code>grp-&lt;team&gt;-&lt;env&gt;-&lt;role&gt;<\/code><\/li>\n<li>policies: <code>pol-&lt;scope&gt;-&lt;role&gt;-&lt;service&gt;<\/code><\/li>\n<li>compartments: <code>&lt;org&gt;-&lt;env&gt;-&lt;workload&gt;<\/code><\/li>\n<li>Use OCI tagging (defined tags) to support cost allocation and governance\u2014especially for shared compartments.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Identity Domains<\/strong> handle <em>who you are<\/em> and <em>how you authenticate<\/em>.<\/li>\n<li><strong>OCI IAM policies<\/strong> handle <em>what you can do<\/em> and <em>where you can do it<\/em> (compartment\/resource scope).<\/li>\n<\/ul>\n\n\n\n<p>Key recommendations:\n&#8211; Avoid granting resource permissions directly to users.\n&#8211; Keep the number of administrators small.\n&#8211; Separate duties:\n  &#8211; identity admins (manage users, MFA)\n  &#8211; cloud admins (manage compartments, policies)\n  &#8211; security auditors (read-only)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity services are managed; data in transit is protected via TLS.<\/li>\n<li>For any stored secrets (API keys, auth tokens, recovery codes), use enterprise vaulting practices.<\/li>\n<li>For OCI resources accessed under these identities, follow service-specific encryption best practices (Object Storage, Block Volume, Database encryption, etc.).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity endpoints are generally accessed over the public internet.<\/li>\n<li>Mitigate risk by:<\/li>\n<li>MFA<\/li>\n<li>IdP conditional access (if your external IdP supports it)<\/li>\n<li>restricting admin actions to hardened endpoints (where your security program requires it)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not share credentials over email\/chat.<\/li>\n<li>Use a password manager or secrets vault.<\/li>\n<li>Rotate credentials and revoke tokens for users who leave the organization.<\/li>\n<li>For API access, prefer short-lived methods when available; if using long-lived keys, implement rotation processes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>OCI Audit<\/strong> as the authoritative record of OCI API actions.<\/li>\n<li>Use identity-domain audit\/sign-in logs where available and export to your SIEM if required.<\/li>\n<li>Define alert rules for:<\/li>\n<li>new admin user creation<\/li>\n<li>changes to MFA\/sign-on policy<\/li>\n<li>group membership elevation<\/li>\n<li>policy statements that grant broad privileges<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>IAM with Identity Domains often supports compliance controls such as:\n&#8211; MFA enforcement\n&#8211; access logging and audit trails\n&#8211; separation of duties\n&#8211; joiner\/mover\/leaver processes<\/p>\n\n\n\n<p>For specific compliance mappings (SOC 2, ISO 27001, HIPAA, PCI DSS), rely on:\n&#8211; Oracle Cloud compliance documentation: https:\/\/www.oracle.com\/cloud\/compliance\/<br\/>\n&#8211; OCI security documentation and your internal controls<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not enforcing MFA for admins<\/li>\n<li>Having no break-glass path (or having one that isn\u2019t secured\/monitored)<\/li>\n<li>Granting broad permissions to large groups (\u201cEveryone is admin\u201d)<\/li>\n<li>Storing API keys on laptops without device security controls<\/li>\n<li>Using shared accounts instead of named users<\/li>\n<li>Not reviewing access after team\/org changes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a clear RBAC model:<\/li>\n<li>small admin groups<\/li>\n<li>per-team operator groups<\/li>\n<li>read-only auditor groups<\/li>\n<li>Use compartment boundaries for isolation.<\/li>\n<li>Document and test:<\/li>\n<li>onboarding<\/li>\n<li>offboarding<\/li>\n<li>incident response for compromised accounts<\/li>\n<li>Integrate with centralized IdP for enterprise workforce where possible, but keep emergency access.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>The exact limitations depend on your tenancy configuration, identity domain type, and Oracle Cloud subscription. Always confirm in official docs and in your console.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ practical gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Multiple domains may not be available<\/strong> or may require specific subscriptions\/entitlements.<\/li>\n<li><strong>Feature availability differs by domain type\/edition<\/strong> (e.g., app catalog features, advanced policies).<\/li>\n<li><strong>Propagation delay<\/strong>: group membership and policy changes may take minutes to apply; re-login often helps.<\/li>\n<li><strong>Policy syntax pitfalls<\/strong>: referencing identity domain groups in OCI policies can be confusing if your tenancy requires domain-qualified references. Use the console policy builder where possible.<\/li>\n<li><strong>Admin lockout risk<\/strong>: misconfigured federation or MFA policies can lock out admins. Always keep at least one secured break-glass admin.<\/li>\n<li><strong>Overlapping policies<\/strong> can lead to unintended access. Maintain a clear policy taxonomy.<\/li>\n<li><strong>Group sprawl<\/strong>: too many groups make audits and access reviews difficult.<\/li>\n<li><strong>External IdP dependency<\/strong>: federated sign-in depends on IdP uptime. Plan for outages.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits exist for:<\/li>\n<li>number of users\/groups\/policies\/compartments<\/li>\n<li>policy size\/statement limits<\/li>\n<li>Check current limits in OCI console and documentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Identity management can involve a home region and region-specific endpoints. This matters for administration and for some integrations.<\/li>\n<li><strong>Verify region behavior for identity domains<\/strong> in official OCI IAM docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Assuming \u201cIAM is free\u201d can be wrong if your domain uses licensed identity features.<\/li>\n<li>SIEM export, log retention, and data egress can create significant costs over time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Federation configuration requires careful alignment of:<\/li>\n<li>SAML\/OIDC metadata<\/li>\n<li>redirect URIs<\/li>\n<li>certificate rotation<\/li>\n<li>attribute\/group mapping<\/li>\n<li>SCIM provisioning (if used) often fails due to attribute mismatches; validate with a pilot first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you are migrating from older IAM models or \u201cIDCS\u201d-named configurations, expect differences in:<\/li>\n<li>UI labels and navigation<\/li>\n<li>group\/policy references<\/li>\n<li>available features<\/li>\n<li>Treat migrations as security-sensitive change projects and test thoroughly.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>IAM with Identity Domains is not the only way to manage identity for OCI-related access. Here\u2019s how it compares.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in Oracle Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI IAM (Policies, Compartments, Dynamic Groups)<\/strong>: authorization engine for OCI resources (still essential).<\/li>\n<li><strong>(Legacy naming) Oracle Identity Cloud Service (IDCS)<\/strong>: older branding and older tutorials may refer to it; modern OCI experience centers on Identity Domains.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Nearest services in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS<\/strong>: AWS IAM (authorization) + AWS IAM Identity Center (workforce SSO)<\/li>\n<li><strong>Microsoft Azure<\/strong>: Microsoft Entra ID (formerly Azure AD) for identity + Azure RBAC for authorization<\/li>\n<li><strong>Google Cloud<\/strong>: Cloud Identity \/ Google Workspace + Google Cloud IAM<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keycloak<\/strong>: self-hosted IdP (OIDC\/SAML), strong control but requires operations, patching, HA design.<\/li>\n<li><strong>Authentik \/ Dex<\/strong>: popular in some Kubernetes-centric environments for OIDC, but less feature-complete for enterprise IAM governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Oracle Cloud IAM with Identity Domains<\/strong><\/td>\n<td>OCI-first identity + authentication + integration with OCI policies<\/td>\n<td>Tight OCI integration, domain-based identity boundary, supports MFA\/federation patterns<\/td>\n<td>Feature set can vary by domain type\/edition; federation misconfig risk<\/td>\n<td>You are running workloads on OCI and need governed workforce access<\/td>\n<\/tr>\n<tr>\n<td><strong>OCI IAM (classic constructs only)<\/strong><\/td>\n<td>OCI authorization and workload identity patterns<\/td>\n<td>Strong compartment\/policy model; dynamic groups for workloads<\/td>\n<td>Not a full workforce IdP experience by itself<\/td>\n<td>Use alongside Identity Domains for authorization and workload identity<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS IAM + IAM Identity Center<\/strong><\/td>\n<td>AWS workforce SSO and RBAC<\/td>\n<td>Mature ecosystem; broad integrations<\/td>\n<td>AWS-specific model; migration to OCI requires redesign<\/td>\n<td>You are primarily on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Microsoft Entra ID + Azure RBAC<\/strong><\/td>\n<td>Microsoft-centric enterprise identity<\/td>\n<td>Deep enterprise adoption; strong conditional access<\/td>\n<td>Azure-centric; mapping to OCI requires federation\/integration<\/td>\n<td>You are primarily on Azure and want centralized workforce identity<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud IAM + Cloud Identity<\/strong><\/td>\n<td>Google Workspace-centric orgs<\/td>\n<td>Strong org policies, mature IAM<\/td>\n<td>GCP-centric; OCI mapping requires federation<\/td>\n<td>You are primarily on GCP<\/td>\n<\/tr>\n<tr>\n<td><strong>Keycloak (self-managed)<\/strong><\/td>\n<td>Custom identity needs, full control, on-prem\/hybrid<\/td>\n<td>Open source, flexible OIDC\/SAML<\/td>\n<td>You operate and secure it; HA and upgrades are on you<\/td>\n<td>You need a self-hosted IdP and have strong ops\/security maturity<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated company with corporate SSO and strict admin controls<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA financial services company runs workloads on Oracle Cloud and must meet strict audit requirements:\n&#8211; MFA for privileged access\n&#8211; SSO through corporate IdP\n&#8211; clear separation of duties\n&#8211; quarterly access reviews and evidence<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Identity Domains:\n  &#8211; Workforce domain federated to corporate IdP (SAML\/OIDC)\n  &#8211; Groups aligned to job functions: <code>NetOps<\/code>, <code>DBA<\/code>, <code>SecOps<\/code>, <code>Auditors<\/code>\n  &#8211; MFA enforced for admins and production write-access groups\n&#8211; OCI:\n  &#8211; Compartments: <code>Shared<\/code>, <code>Network<\/code>, <code>Security<\/code>, <code>Prod<\/code>, <code>NonProd<\/code>\n  &#8211; Policies: least privilege, compartment-scoped, standardized templates\n&#8211; Monitoring\/Governance:\n  &#8211; OCI Audit exported to centralized logging\/SIEM\n  &#8211; Alerts on policy changes and admin group membership changes\n  &#8211; Break-glass local admin account stored in vault<\/p>\n\n\n\n<p><strong>Why IAM with Identity Domains was chosen<\/strong>\n&#8211; Aligns with enterprise SSO and identity governance\n&#8211; Provides domain-level controls for authentication and administration\n&#8211; Integrates cleanly with OCI authorization model (policies\/compartments)<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced credential sprawl\n&#8211; Faster offboarding (disabling IdP account removes access)\n&#8211; Auditable role model and activity logs\n&#8211; Lower risk of privilege misuse<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: small OCI footprint with simple roles<\/h3>\n\n\n\n<p><strong>Problem<\/strong>\nA startup uses OCI for a small SaaS platform and needs:\n&#8211; basic access control\n&#8211; MFA for admins\n&#8211; simple separation between dev and prod<\/p>\n\n\n\n<p><strong>Proposed architecture<\/strong>\n&#8211; Single identity domain (default)\n&#8211; Groups:\n  &#8211; <code>Admins<\/code> (very small)\n  &#8211; <code>Developers<\/code> (dev-only manage)\n  &#8211; <code>ReadOnly<\/code> (support\/audit)\n&#8211; Compartments:\n  &#8211; <code>dev<\/code>\n  &#8211; <code>prod<\/code>\n&#8211; Policies:\n  &#8211; Developers can manage compute\/storage in dev\n  &#8211; Only Admins can manage production\n&#8211; Basic audit monitoring:\n  &#8211; review OCI Audit for policy changes and suspicious activity<\/p>\n\n\n\n<p><strong>Why IAM with Identity Domains was chosen<\/strong>\n&#8211; Minimal setup complexity compared to running their own IdP\n&#8211; MFA and group-based access patterns are straightforward\n&#8211; Fits the OCI-first operational model<\/p>\n\n\n\n<p><strong>Expected outcomes<\/strong>\n&#8211; Reduced chance of production incidents caused by access mistakes\n&#8211; Clear onboarding pattern for new engineers\n&#8211; A baseline security posture suitable for early compliance needs<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) What is the difference between Identity Domains and OCI IAM policies?<\/h3>\n\n\n\n<p>Identity Domains handle <strong>identity and authentication<\/strong> (users, groups, MFA, federation). OCI IAM policies handle <strong>authorization<\/strong> to OCI resources (what actions are allowed in which compartments).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Is \u201cOracle Identity Cloud Service (IDCS)\u201d the same thing as IAM with Identity Domains?<\/h3>\n\n\n\n<p>IDCS is a legacy name you may see in older content. In OCI, Identity Domains are the modern construct. The exact relationship can depend on tenancy history\u2014<strong>verify in official docs and your console<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Do I need an Identity Domain to use OCI?<\/h3>\n\n\n\n<p>Many OCI tenants use Identity Domains for OCI Console sign-in and user management. Some older tenants may have different models. Check <strong>Identity &amp; Security \u2192 Domains<\/strong> in your console.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Can I create multiple identity domains?<\/h3>\n\n\n\n<p>Some tenancies support multiple domains; others do not. It can depend on subscription and tenancy configuration. Verify in your tenancy console and Oracle docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Are users and groups created in Identity Domains usable in OCI policies?<\/h3>\n\n\n\n<p>Yes in typical IAM with Identity Domains setups, groups are used by OCI policies to grant permissions. If policy syntax differs (domain-qualified names), use the OCI Console policy builder and verify with docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) How do I enforce MFA for all users?<\/h3>\n\n\n\n<p>This is usually done through domain security\/sign-on policies. Exact steps and supported MFA methods depend on your domain configuration\u2014verify in official documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) What\u2019s the recommended approach for admin access?<\/h3>\n\n\n\n<p>Use:\n&#8211; a small admin group\n&#8211; MFA enforced\n&#8211; separate admin accounts if required\n&#8211; break-glass local admin\n&#8211; dedicated compartments\/policies for security administration<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) What\u2019s a break-glass account and why do I need it?<\/h3>\n\n\n\n<p>A break-glass account is an emergency admin identity not dependent on federation. It prevents lockouts if your external IdP or federation configuration fails.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Should I federate with my corporate IdP?<\/h3>\n\n\n\n<p>If you\u2019re an enterprise, yes\u2014federation reduces password sprawl and improves offboarding. But do it carefully and test with pilot users first.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) How do I troubleshoot \u201cNot authorized\u201d errors?<\/h3>\n\n\n\n<p>Check:\n&#8211; user is in correct group\n&#8211; policy references correct group and compartment\n&#8211; policy has correct verbs (inspect\/read\/use\/manage)\n&#8211; allow time for propagation and re-login<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) Do Identity Domains replace dynamic groups and instance principals?<\/h3>\n\n\n\n<p>No. Dynamic groups and instance principals are primarily for <strong>workload identity<\/strong> (non-human principals). Identity Domains are primarily for <strong>workforce identity<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) How do I design group structure?<\/h3>\n\n\n\n<p>Align groups to:\n&#8211; job roles (DBA, NetOps, Security)\n&#8211; environment boundaries (Dev vs Prod)\n&#8211; team boundaries when needed<br\/>\nAvoid one-off \u201cspecial\u201d groups unless justified.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) How often should we review access?<\/h3>\n\n\n\n<p>Common governance is quarterly for privileged access and at least semi-annually for standard access, but follow your compliance requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) Where do I find logs for access and changes?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI API actions: <strong>OCI Audit<\/strong><\/li>\n<li>Identity actions\/sign-in events: identity domain audit\/log features (availability and export options vary\u2014verify)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">15) Can I automate user provisioning?<\/h3>\n\n\n\n<p>Often yes via SCIM provisioning patterns, but capabilities depend on domain configuration and your IdP. Validate with a sandbox and pilot.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) What\u2019s the biggest operational risk?<\/h3>\n\n\n\n<p>Lockouts due to misconfigured federation\/MFA policies, and privilege creep due to broad policies and unmanaged group membership.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) Is IAM with Identity Domains enough for full compliance?<\/h3>\n\n\n\n<p>It\u2019s foundational, but compliance requires broader controls: network segmentation, logging, vulnerability management, incident response, and data protection. IAM is one pillar.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn IAM with Identity Domains<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>OCI Identity and Access Management (IAM) Docs: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Identity\/home.htm<\/td>\n<td>Primary source for IAM concepts, policies, identity domains navigation, and security guidance<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>OCI Security Documentation (entry point): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Security\/home.htm<\/td>\n<td>Broader security context (audit, logging, cloud guard, best practices)<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>OCI CLI Installation: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/SDKDocs\/cliinstall.htm<\/td>\n<td>Useful for operational verification and automation<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Oracle Cloud Price List: https:\/\/www.oracle.com\/cloud\/price-list\/<\/td>\n<td>Authoritative list for Oracle Cloud service pricing and SKUs (verify identity-related SKUs)<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Oracle Cloud Pricing overview: https:\/\/www.oracle.com\/cloud\/pricing\/<\/td>\n<td>Explains Oracle\u2019s pricing approach and links to calculators<\/td>\n<\/tr>\n<tr>\n<td>Official cost tool<\/td>\n<td>Oracle Cloud Cost Estimator: https:\/\/www.oracle.com\/cloud\/costestimator.html<\/td>\n<td>Helps estimate total solution costs (verify availability and applicability)<\/td>\n<\/tr>\n<tr>\n<td>Official compliance<\/td>\n<td>Oracle Cloud Compliance: https:\/\/www.oracle.com\/cloud\/compliance\/<\/td>\n<td>Compliance programs and attestations relevant to IAM controls<\/td>\n<\/tr>\n<tr>\n<td>Architecture center<\/td>\n<td>Oracle Architecture Center: https:\/\/docs.oracle.com\/en\/solutions\/<\/td>\n<td>Reference architectures, including security and landing zone patterns (search for IAM, security, landing zone)<\/td>\n<\/tr>\n<tr>\n<td>Tutorials\/labs<\/td>\n<td>Oracle Cloud Free Tier &amp; Workshops (entry points): https:\/\/www.oracle.com\/cloud\/free\/ and https:\/\/www.oracle.com\/cloud\/learn\/<\/td>\n<td>Official learning paths and hands-on materials (availability varies)<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Oracle Cloud YouTube channel: https:\/\/www.youtube.com\/@OracleCloudInfrastructure<\/td>\n<td>Product walkthroughs and webinars; search within channel for \u201cIdentity Domains\u201d and \u201cOCI IAM\u201d<\/td>\n<\/tr>\n<tr>\n<td>Community (use carefully)<\/td>\n<td>Oracle Cloud community forums: https:\/\/community.oracle.com\/<\/td>\n<td>Practical Q&amp;A and troubleshooting; validate answers against official docs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>OCI fundamentals, DevOps practices, cloud security basics; verify IAM coverage<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students, engineers transitioning to DevOps<\/td>\n<td>DevOps\/SCM foundations, automation; may include cloud basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops engineers, operations teams<\/td>\n<td>Cloud operations practices, monitoring, governance; verify OCI-specific modules<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers<\/td>\n<td>Reliability engineering practices, incident response, operations; IAM governance as part of ops<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and platform teams<\/td>\n<td>AIOps concepts, monitoring, automation; may complement IAM operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<blockquote>\n<p>Certification note: Oracle offers OCI certifications. For IAM-specific certification mapping, <strong>verify current Oracle certification tracks<\/strong> on Oracle University \/ Oracle certification pages.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify specific OCI coverage)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tooling and practices (verify OCI\/IAM topics)<\/td>\n<td>DevOps engineers, students<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps consulting\/training platform (verify offerings)<\/td>\n<td>Teams seeking practical implementation help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify OCI modules)<\/td>\n<td>Ops\/DevOps teams needing hands-on support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify OCI specialization)<\/td>\n<td>Architecture, migration planning, operations setup<\/td>\n<td>OCI landing zone design, access model review, automation pipelines<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training<\/td>\n<td>Implement DevOps practices alongside cloud governance<\/td>\n<td>IAM rollout planning, CI\/CD guardrails, operational readiness<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify OCI service list)<\/td>\n<td>DevOps transformation, automation, platform enablement<\/td>\n<td>Security baseline, access governance processes, monitoring integration<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<p>To use IAM with Identity Domains effectively, learn:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI fundamentals:<\/li>\n<li>tenancies, regions, compartments, OCIDs<\/li>\n<li>IAM fundamentals:<\/li>\n<li>authentication vs authorization<\/li>\n<li>least privilege and RBAC concepts<\/li>\n<li>Basic security:<\/li>\n<li>MFA, phishing resistance, credential hygiene<\/li>\n<li>Network basics:<\/li>\n<li>public endpoints, HTTPS, DNS (for federation troubleshooting)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI policy language deeply:<\/li>\n<li>policy verbs and resource families<\/li>\n<li>compartment design patterns<\/li>\n<li>Workload identity in OCI:<\/li>\n<li>dynamic groups, instance principals<\/li>\n<li>OKE identity patterns (verify current OCI guidance)<\/li>\n<li>Security operations in OCI:<\/li>\n<li>OCI Audit, Logging, Events, Notifications<\/li>\n<li>Cloud Guard and security posture management<\/li>\n<li>Compliance practices:<\/li>\n<li>access reviews, evidence collection, change management<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ platform engineer<\/li>\n<li>Security engineer (IAM\/security governance)<\/li>\n<li>DevOps engineer \/ SRE<\/li>\n<li>Cloud solutions architect<\/li>\n<li>Compliance and audit analyst (read-only access patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (verify current)<\/h3>\n\n\n\n<p>Oracle\u2019s OCI certifications evolve. Start by verifying the latest tracks:\n&#8211; Oracle University \/ OCI certifications: https:\/\/education.oracle.com\/ (navigate to OCI certifications)<\/p>\n\n\n\n<p>A practical sequence often looks like:\n1. OCI foundations\n2. OCI architect associate\/professional (as applicable)\n3. Security specialty (if offered\u2014verify current availability)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201cnew project onboarding\u201d blueprint:<\/li>\n<li>compartments, groups, policies, tagging<\/li>\n<li>Implement SSO federation in a sandbox:<\/li>\n<li>test users, break-glass procedure, rollback plan<\/li>\n<li>Create an access review report:<\/li>\n<li>list groups, members, policies, and scope<\/li>\n<li>Build alerting for IAM changes:<\/li>\n<li>policy changes, admin group membership changes (using OCI audit + events)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM (Identity and Access Management)<\/strong>: The discipline and system for managing identities and permissions.<\/li>\n<li><strong>Identity Domain<\/strong>: A logical boundary in Oracle Cloud for managing users, groups, authentication policies, and federation.<\/li>\n<li><strong>Tenancy<\/strong>: Your Oracle Cloud account boundary that owns OCI resources, compartments, and policies.<\/li>\n<li><strong>Compartment<\/strong>: A logical container for OCI resources used for isolation and access control.<\/li>\n<li><strong>Policy<\/strong>: A statement-based authorization rule that grants permissions to groups (or other principals) in OCI.<\/li>\n<li><strong>Principal<\/strong>: An entity that can authenticate and request access (user, group membership context, or workload identity).<\/li>\n<li><strong>RBAC (Role-Based Access Control)<\/strong>: Access control model using roles\/groups rather than per-user permissions.<\/li>\n<li><strong>Least privilege<\/strong>: Grant only the minimum permissions required to perform a task.<\/li>\n<li><strong>MFA (Multi-Factor Authentication)<\/strong>: Authentication requiring more than one factor (e.g., password + OTP).<\/li>\n<li><strong>SSO (Single Sign-On)<\/strong>: Authentication once via an identity provider to access multiple services\/apps.<\/li>\n<li><strong>Federation<\/strong>: Trust relationship allowing identities from an external IdP to access Oracle Cloud.<\/li>\n<li><strong>IdP (Identity Provider)<\/strong>: System that authenticates users (e.g., enterprise SSO platform).<\/li>\n<li><strong>SAML 2.0<\/strong>: Federation protocol commonly used for enterprise SSO.<\/li>\n<li><strong>OIDC (OpenID Connect)<\/strong>: Identity layer on OAuth 2.0, often used for modern SSO.<\/li>\n<li><strong>SCIM<\/strong>: Standard protocol for provisioning users and groups between systems.<\/li>\n<li><strong>OCI Audit<\/strong>: Oracle Cloud service that records API calls and many control-plane events for security and compliance.<\/li>\n<li><strong>Break-glass account<\/strong>: Emergency admin account used when normal sign-in\/federation is unavailable.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>IAM with Identity Domains in Oracle Cloud is the practical foundation for <strong>workforce identity<\/strong>: it manages users and groups, strengthens authentication with MFA and sign-on policies, and enables SSO\/federation\u2014then ties those identities to OCI\u2019s compartment-and-policy authorization model.<\/p>\n\n\n\n<p>It matters because cloud security failures often start with identity: weak authentication, excessive permissions, and poor offboarding. With IAM with Identity Domains, you can build least-privilege access patterns that scale across teams and environments while improving auditability.<\/p>\n\n\n\n<p>Cost-wise, IAM itself is often foundational, but advanced identity features and broader governance patterns (SIEM ingestion, log retention, multiple domains) can introduce real costs\u2014so validate your pricing model using Oracle\u2019s official price list and your contract.<\/p>\n\n\n\n<p>If you want the next step after this tutorial, deepen your skills in <strong>OCI policy design<\/strong>, <strong>compartment architectures (landing zones)<\/strong>, and <strong>workload identity<\/strong> (dynamic groups\/instance principals), then add <strong>monitoring and alerting<\/strong> around IAM and policy changes using OCI Audit and your security tooling.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security, Identity, and Compliance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[62,39],"tags":[],"class_list":["post-977","post","type-post","status-publish","format-standard","hentry","category-oracle-cloud","category-security-identity-and-compliance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=977"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/977\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}