OCI Identity Domains Guide

Introduction to OCI Identity Domains

OCI Identity Domains is Oracle's unified identity and access management service that provides user authentication, authorization, single sign-on (SSO), multi-factor authentication (MFA), and identity federation in a single managed platform. Identity Domains replaced the legacy Oracle Identity Cloud Service (IDCS) and is now the default identity provider for all OCI tenancies.

Each OCI tenancy has a default identity domain that manages users, groups, and authentication policies. You can create additional identity domains for different environments, business units, or external user populations. Each domain is an isolated identity boundary with its own users, groups, applications, sign-on policies, and MFA configuration.

This guide covers identity domain types and licensing, user and group management, sign-on policies, MFA configuration, SAML and OIDC federation with external identity providers, SCIM provisioning for automated user lifecycle, and production best practices for identity management on OCI.

Understanding Domain Structure

An identity domain is a self-contained identity management boundary. Resources within a domain include users, groups, applications (SSO integrations), sign-on policies, identity providers (federation), and network perimeters (trusted IP ranges).

The default domain is created automatically with your tenancy and cannot be deleted. It contains the tenancy administrator user and the built-in administrator groups. You should use the default domain for OCI console access and administrative users, and create additional domains for application users, partners, and external contractors.

# List identity domains
oci iam domain list \
  --compartment-id <tenancy-ocid> \
  --query 'data[].{"display-name":"display-name", "lifecycle-state":"lifecycle-state", "home-region":"home-region", type:type}' \
  --output table

# Create a new identity domain
oci iam domain create \
  --compartment-id $C \
  --display-name "app-users-domain" \
  --description "Identity domain for application end users" \
  --home-region "us-ashburn-1" \
  --license-type "free" \
  --admin-email "admin@example.com" \
  --admin-first-name "Domain" \
  --admin-last-name "Admin" \
  --admin-user-name "domain-admin" \
  --is-hidden-on-login false \
  --wait-for-state AVAILABLE

# Get domain details
oci iam domain get \
  --domain-id <domain-ocid> \
  --query 'data.{"display-name":"display-name", url:url, type:type, "home-region":"home-region"}'

# Enable replication to another region
oci iam domain enable-replication-to-region \
  --domain-id <domain-ocid> \
  --replica-region "us-phoenix-1"

User and Group Management

Users in OCI Identity Domains have profiles that include contact information, credentials, group memberships, application access, and MFA enrollment. Users can be created manually, imported in bulk, synchronized from an external directory via SCIM, or federated through SAML/OIDC.

Groups organize users for access management. IAM policies reference groups to grant permissions, so group membership determines what resources a user can access. Use descriptive group names that align with roles (e.g., NetworkAdmins, DatabaseOperators, ReadOnlyAuditors) rather than organizational structure.

# Create a user in the default domain
oci iam user create \
  --compartment-id <tenancy-ocid> \
  --name "jane.smith@example.com" \
  --description "Platform Engineer" \
  --email "jane.smith@example.com"

# Create a group
oci iam group create \
  --compartment-id <tenancy-ocid> \
  --name "PlatformEngineers" \
  --description "Platform engineering team with infrastructure access"

# Add a user to a group
oci iam group add-user \
  --group-id <group-ocid> \
  --user-id <user-ocid>

# List users
oci iam user list \
  --compartment-id <tenancy-ocid> \
  --query 'data[].{name:name, email:email, "lifecycle-state":"lifecycle-state"}' \
  --output table

# List groups
oci iam group list \
  --compartment-id <tenancy-ocid> \
  --query 'data[].{name:name, description:description}' \
  --output table

# List group memberships
oci iam user-group-membership list \
  --compartment-id <tenancy-ocid> \
  --group-id <group-ocid> \
  --query 'data[].{"user-id":"user-id"}'

# Disable a user (prevent login without deleting)
oci iam user update \
  --user-id <user-ocid> \
  --description "DISABLED - Left company 2026-03-14"

# Delete a user
oci iam user delete \
  --user-id <user-ocid> \
  --force

Sign-On Policies

Sign-on policies control how users authenticate to OCI and applications. They define conditions under which different authentication requirements apply, such as requiring MFA for all logins, allowing passwordless authentication from trusted networks, or blocking access from specific geographic locations.

Policies are evaluated in priority order. Each policy has one or more rules, and each rule specifies conditions (such as user group membership, network perimeter, or device type) and the resulting authentication requirements. The first matching rule determines the authentication experience.

Key policy configurations include:

MFA Enforcement: Require MFA for all users, specific groups, or users accessing from outside a trusted network.

Network Perimeters: Define trusted IP ranges (corporate networks, VPNs) where reduced authentication requirements apply.

Adaptive Security: Automatically increase authentication requirements based on risk signals such as unfamiliar device, unusual location, or impossible travel.

# Sign-on policies are configured through the Identity Domain admin console
# or the SCIM/REST API at the domain URL

# Access the Identity Domain admin console:
# https://<domain-url>/ui/v1/adminconsole

# Common sign-on policy patterns:

# 1. Require MFA for all users:
# Rule: All users -> Require MFA (TOTP, Push, or FIDO2)
# Priority: 1

# 2. Skip MFA for trusted networks, require everywhere else:
# Rule 1: Users from corporate network (10.0.0.0/8) -> Allow password only
# Rule 2: All other users -> Require MFA
# Priority: 1 for Rule 1, 2 for Rule 2

# 3. Block access from high-risk countries:
# Rule 1: Users from blocked countries -> Deny access
# Rule 2: All other users -> Require MFA
# Priority: 1 for Rule 1, 2 for Rule 2

# 4. Adaptive authentication:
# Low risk -> Password only
# Medium risk -> Password + MFA
# High risk -> Block access

# Create a network perimeter (trusted IP range)
# Through the admin console:
# Security > Network Perimeters > Add
# Name: "Corporate Network"
# IP Addresses: 203.0.113.0/24, 198.51.100.0/24

Multi-Factor Authentication (MFA)

OCI Identity Domains supports multiple MFA factors that provide different levels of security and convenience:

TOTP (Time-Based One-Time Password): Uses authenticator apps like Oracle Mobile Authenticator, Google Authenticator, or Microsoft Authenticator. Generates a new 6-digit code every 30 seconds. Does not require network connectivity.

Push Notifications: Sends a push notification to the Oracle Mobile Authenticator app. The user approves or denies the login with a single tap. Requires network connectivity on the mobile device.

FIDO2/WebAuthn: Uses hardware security keys (YubiKey, Google Titan) or platform authenticators (TouchID, Windows Hello) for phishing-resistant authentication. This is the most secure MFA method.

SMS/Email OTP: Sends a one-time password via SMS or email. Less secure than other methods due to SIM-swapping and email compromise risks, but provides a fallback for users without authenticator apps.

Security Questions: Knowledge-based authentication using pre-configured questions. Least secure method and should only be used as a last-resort recovery option.

# MFA configuration is managed through the Identity Domain admin console
# https://<domain-url>/ui/v1/adminconsole

# Navigate to: Security > MFA

# Recommended MFA configuration:
# 1. Enable: TOTP, Push Notification, FIDO2
# 2. Disable: SMS, Email (if security requirements allow)
# 3. Set enrollment: Required for all users
# 4. Grace period: 7 days
# 5. Trusted devices: Allow for 30 days

# MFA API operations (using SCIM):
# GET https://<domain-url>/admin/v1/MfaSettings
# PATCH https://<domain-url>/admin/v1/MfaSettings

# Check user MFA enrollment status via API:
# GET https://<domain-url>/admin/v1/Users/<user-id>/MfaStatus

# Reset a user's MFA enrollment (admin operation):
# DELETE https://<domain-url>/admin/v1/Users/<user-id>/MfaDevices

# List MFA devices for a user:
# GET https://<domain-url>/admin/v1/Users/<user-id>/MfaDevices

Federation with External Identity Providers

Identity federation enables users from external identity providers (IdPs) to access OCI resources without creating separate OCI user accounts. OCI Identity Domains supports federation using SAML 2.0 and OpenID Connect (OIDC), allowing integration with enterprise IdPs like Microsoft Entra ID (Azure AD), Okta, OneLogin, and Google Workspace.

In a federated setup, the external IdP handles user authentication, and OCI trusts the IdP's assertions. Users authenticate with their existing corporate credentials and are mapped to OCI groups based on IdP attributes (such as group memberships or SAML attributes).

# Federation is configured through the Identity Domain admin console
# https://<domain-url>/ui/v1/adminconsole
# Navigate to: Security > Identity Providers

# SAML Federation with Microsoft Entra ID:
# 1. In OCI: Create a SAML Identity Provider
#    - Upload the Entra ID Federation Metadata XML
#    - Map Entra ID groups to OCI groups
#    - Configure attribute mappings
# 2. In Entra ID: Create an Enterprise Application
#    - SAML SSO URL: https://<domain-url>/fed/v1/sp/sso
#    - Entity ID: https://<domain-url>/fed
#    - Configure group claims
# 3. Test: Login to OCI using "Sign in with <IdP-name>"

# OIDC Federation with Okta:
# 1. In Okta: Create an OIDC application
#    - Redirect URI: https://<domain-url>/oauth2/callback
#    - Note: Client ID and Client Secret
# 2. In OCI: Create an OIDC Identity Provider
#    - Discovery URL: https://<okta-domain>/.well-known/openid-configuration
#    - Client ID and Secret from step 1
#    - Map Okta groups to OCI groups

# Group mapping configuration:
# External IdP Group -> OCI Group
# "Cloud-Admins"    -> "Administrators"
# "Network-Team"    -> "NetworkAdmins"
# "Dev-Team"        -> "Developers"
# "Audit-Team"      -> "ReadOnlyAuditors"

# CLI identity provider operations:
oci iam identity-provider list \
  --protocol "SAML2" \
  --compartment-id <tenancy-ocid> \
  --query 'data[].{name:name, "lifecycle-state":"lifecycle-state"}' \
  --output table

SCIM Provisioning

System for Cross-domain Identity Management (SCIM) enables automated user provisioning and deprovisioning between OCI Identity Domains and external identity providers. When a user is created, updated, or disabled in your corporate directory, SCIM automatically synchronizes those changes to OCI, ensuring that user access is always current.

SCIM provisioning eliminates manual user management and reduces the risk of orphaned accounts. When an employee leaves the organization and is disabled in the corporate directory, SCIM automatically disables their OCI access within minutes.

# SCIM endpoint for OCI Identity Domains:
# https://<domain-url>/admin/v1

# Common SCIM operations:

# Create a user via SCIM:
# POST https://<domain-url>/admin/v1/Users
# {
#   "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
#   "userName": "jsmith@example.com",
#   "name": {"givenName": "Jane", "familyName": "Smith"},
#   "emails": [{"value": "jsmith@example.com", "primary": true}],
#   "active": true
# }

# List users via SCIM:
# GET https://<domain-url>/admin/v1/Users?filter=userName eq "jsmith@example.com"

# Update a user via SCIM:
# PATCH https://<domain-url>/admin/v1/Users/<user-id>
# {
#   "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
#   "Operations": [{"op": "replace", "path": "active", "value": false}]
# }

# Create a group via SCIM:
# POST https://<domain-url>/admin/v1/Groups
# {
#   "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
#   "displayName": "DevOps-Team",
#   "members": [{"value": "<user-id>", "type": "User"}]
# }

# SCIM provisioning with Entra ID:
# 1. In Entra ID: Enable provisioning on the Enterprise Application
# 2. Set SCIM URL: https://<domain-url>/admin/v1
# 3. Generate an OAuth2 bearer token for authentication
# 4. Map Entra ID attributes to SCIM attributes
# 5. Set provisioning interval (default: 40 minutes)
# 6. Start provisioning

Production Best Practices

Implementing identity management in production requires careful planning for security, compliance, and operational efficiency:

Federate Early: Set up federation with your corporate IdP before creating individual OCI users. This ensures consistent identity management and avoids maintaining separate credentials. Use SCIM for automated provisioning to eliminate manual user management.

Enforce MFA Everywhere: Enable MFA for all users, not just administrators. Use FIDO2/WebAuthn for the highest security or TOTP for broad compatibility. Block SMS- based MFA if your security requirements allow, as it is vulnerable to SIM-swapping attacks.

Implement Least Privilege: Create specific groups for each role and grant only the minimum necessary permissions. Review group memberships quarterly and remove access that is no longer needed. Use compartment-scoped policies to limit the blast radius of compromised credentials.

Monitor Authentication Events: Configure audit logging for all authentication events including successful logins, failed logins, MFA challenges, and password changes. Set up alerts for suspicious patterns such as multiple failed login attempts, logins from unusual locations, or impossible travel scenarios.

Break-Glass Accounts: Maintain one or two emergency local administrator accounts that bypass federation for use when the external IdP is unavailable. Store these credentials in a physical safe or hardware security module, not in a digital password manager. Enable MFA on these accounts and audit their usage.

Regular Access Reviews: Conduct quarterly access reviews where group owners verify that all members still require their current level of access. Automate deprovisioning for users who leave the organization using SCIM integration with HR systems.