Identity and Access Management FAQ

FAQ topics

General

What is Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)?

OCI IAM is a native service of OCI that provides enterprise-class identity and access management features such as strong, adaptive authentication, user Lifecycle Management (LCM), and Single Sign-On (SSO) to enterprise applications. OCI IAM is deployed as identity domain(s) in OCI. Included domain(s) allow organizations to manage access to their Oracle Cloud services (network, compute, storage, etc.) and Oracle SaaS applications. Customers can choose to upgrade or create additional identity domains to accommodate other use cases such as managing workforce access to non-Oracle applications, enabling consumer access to customer-facing applications, or embedding IAM into custom-developed applications.

What are identity domains?

Each OCI IAM identity domain is a self-contained identity and access management solution that can be used to address a variety of IAM use cases. For example, you can use an OCI IAM identity domain to manage access for employees across numerous cloud and on-premises applications, enabling secure authentication, easy management of entitlements, and seamless SSO for end users. You might also want to stand up an identity domain to enable access to supply chain or ordering systems for business partners. You can also use identity domains to enable IAM for consumer-facing applications and allow consumer users to perform self-registration, social logon, and/or terms-of-use consent. Identity domains represent a comprehensive identity-as-a-service (IDaaS) solution accommodating numerous IAM use cases and scenarios.

What type of identity domain should I choose?

  • Free identity domains: Each OCI tenancy includes a free tier default OCI IAM identity domain for managing access to OCI resources (network, compute, storage, etc.) If you're only looking to manage access to OCI resources, you can use the included default domain. It provides a robust set of IAM functionality for managing access to Oracle Cloud resources. Depending on the security model and team, customers may choose to reserve this domain for OCI Administrators.
  • Oracle Apps identity domains: Numerous Oracle Cloud applications (HCM, CRM, ERP, industry apps, etc.) may include use of OCI IAM via an Oracle Apps domain. These domains are included for use with subscribed Oracle applications and provide robust IAM functionality for managing access to Oracle Cloud and SaaS services. Customers may choose to add all employees to this domain to enable SSO to an Oracle Cloud application service, and may use this domain to manage access to some or all of their OCI resources.
  • Oracle Apps Premium identity domains: If you want to extend an Oracle Apps domain with full enterprise features to manage access for Oracle applications that may not be SaaS-delivered (e.g., Oracle E-Business Suite or Oracle Databases, whether on-premises or hosted in OCI), Oracle Apps Premium domains offer the full set of OCI IAM features and capabilities for use with Oracle targets that may be deployed across hybrid cloud environments. This is a low-cost service that is full featured but is limited to use with Oracle targets.
  • External identity domains: External identity domains offer a full set of OCI IAM features and capabilities for nonemployees such as consumers accessing a retail site, governments enabling access for citizens, or businesses allowing access to business partners. There are no restrictions on which applications can be targeted. However, certain enterprise features which are generally not useful in nonemployee scenarios, such as the App Gateway and Provisioning Bridge, are not included. External domains include support for social logon, self-registration, terms-of-use consent, and profile/password management.
  • Premium identity domains: Premium identity domains offer the full set of OCI IAM features and capabilities with no restrictions on which applications can be targeted. Premium domains can be used as an enterprise IAM service managing employee or workforce access across cloud and on-premises applications enabling secure authentication, easy management of entitlements, and seamless SSO for end users.

Can I mix employees and nonemployees in a single identity domain?

No. OCI IAM considers these as separate user populations for licensing purposes. However, you can use the same OCI IAM service to manage two or more domains that can accommodate employees and nonemployees (partners, affiliates, consumers, etc.). Multiple domains can be used to access the same applications, but the rules and security policies for nonemployees typically differ from those applying to employees. Each domain has its own set of settings, configurations, and security policies that are unique for that user population. This is by design to accommodate for the widely varying requirements that are typical for different user populations.

Who has access to an identity domain?

Each OCI tenancy includes an Administrators group that provides full access to all OCI resources. It’s important to understand that all members of the OCI Administrators group have full access to manage OCI IAM identity domains. Oracle recommends careful use of this group. Administrative privileges can be granted within each domain via Administrator Roles which allow for separation of duties between groups of people. See Understanding Administrator Roles for more details.

Does OCI IAM provide high availability and/or disaster recovery?

Within each OCI region, there are either multiple Availability Domains (ADs) or Fault Domains (FD) (in single-AD regions). ADs and FDs serve similar functions, but FDs are physically closer together than ADs. Identity domains are deployed with redundant installations in each region (two across the AD/FDs) that provide high availability. OCI IAM identity domains also offer cross-region disaster recovery (DR) via an active-passive approach leveraging high-performance data replication. This provides reliable data recovery for identity domains in the unlikely event that an entire OCI region becomes unavailable. This DR is delivered through a single URL making it transparent to applications.

What are the key terms and concepts of Oracle Identity and Access Management?

The key concepts of IAM are:

  • Account or Tenancy - When you sign up for OCI, Oracle creates a tenancy for your company, which is an isolated partition within OCI where you can create, organize, and administer your cloud resources. This is sometimes called an OCI account.
  • Compartment - A logical container within an OCI account for Oracle Cloud resources. Administrators can create one or more compartments within an OCI account to organize and manage resources. For example, compartments can be used to enforce Separation of Duties between different types of administrators (network, compute, storage, etc.)
  • Root Compartment - The top-level compartment within an OCI account. The root compartment is created for you automatically when your account is provisioned.
  • Identity domains - An identity domain represents a user population in OCI and associated configurations and security settings. Each account includes a default identity domain allowing customers to manage access to OCI resources. Customers can elect to create additional identity domains based on their specific needs. Identity domains are created inside of a compartment and access to manage domains is tied to compartment permissions. OCI access policies can be written to allow users in a given compartment/domain to access resources in other compartments.
  • User - An entity that can be authenticated. A user can be either a person or a machine account. Each user has a unique name in your account and a globally unique identifier. Users can be given passwords to access the web console and keys to access the services through the APIs.
  • Group - A set of users. Groups are used to simplify access management. For example, software developers can be grouped together as members of a "developers" group, which allows them to read and/or modify code. A single user can be a member of multiple groups.
  • Policy - A document that specifies who can access which OCI resources and what privileges they have. A policy is comprised of policy statements that leverage natural language syntax.

What is unique about Oracle Cloud Infrastructure's approach to Identity and Access Management?

With OCI IAM, you can leverage a single model for authentication and authorization across all Oracle Cloud and Cloud Application services. OCI IAM makes it easy to manage access for organizations of all sizes, from one person working on a single project to large companies with many groups working on many projects at the same time, all within a single account. Resource management and authorization can happen at the account level or at the compartment level, while still allowing central auditing and billing. OCI IAM was built from the ground up to allow you to enforce the security principle of least privilege; by default, new users are not allowed to perform any actions on any resources. Administrators can then grant each user only the access appropriate for that specific user.

And in addition to managing OCI resources, OCI IAM puts an enterprise-class IDaaS solution at your fingertips. With the click of a button, you can deploy a robust IAM solution that can be used to address many IAM requirements across employee/workforce, partner, or consumer use cases.

How does Oracle Cloud Infrastructure support multi-factor authentication?

OCI IAM provides broad support for multi-factor authentication (MFA) that includes a mobile MFA application offering options for push or one-time-passcode, support for FIDO2 authenticators, and support for SMS, Email, Phone Call, and more. OCI IAM also includes context-aware adaptive security that reduces risk without introducing hurdles to the end-user experience. Adaptive Security evaluates the user's device, network, location, and past behavior to create a risk score for the user's session. Administrators can configure MFA policies that may differ for specific applications or for specific groups of users.

Are changes to users, groups, compartments, and policies recorded for debugging and auditing purposes?

Yes. To support enterprise requirements for auditing and compliance, all changes are recorded and these records can be made available to you at no additional cost.

How do I get started with OCI IAM?

OCI IAM is enabled by default at no additional charge. The very first user in your account is the default Administrator. All subsequent users are created through the IAM service, where you explicitly grant them privileges to interact with specified cloud resources.

You can access Oracle IAM using the Console, Rest API, or SDKs.

As an Oracle Cloud Infrastructure user, how do I reset my password?

To reset your password for Oracle Cloud Infrastructure, you must first ensure that you have associated an email address with your account. Visit the user profile page for your Oracle Cloud Infrastructure account and add an email address that only you have access to. You will receive an email to confirm that you intended to register that address with your account. Then, you can reset your password with your email account unless it has been disabled by your tenant administrator.

Compartments

What problems are compartments designed to solve?

A compartment is a secure logical container within your account used to host your infrastructure resources (such as compute, storage, and network), along with a set of access management policies for these resources. Compartments allow you to logically organize your cloud resources to support a wide variety of use cases.

The following are a few common ways to use compartments to:

  • Separate your software development environments for simple administration. For example, you might have separate compartments for dev, test, and production; or, you may have separate compartments to support blue/green deployment.
  • Simplify permission management. For example, you might create a separate compartment for your networking resources (VCNs, subnets, internet gateways, and so on), and then allow only network administrators to access that compartment.
  • Meter usage separately for distinct business units in order to properly charge those business units for their cloud resource consumption.
  • Minimize the set of resources visible to certain sets of users. For instance, you might want to have a separate compartment for your Finance team that is only visible to certain employees.

Can compartments contain resources in multiple Availability Domains?

Yes. Compartments are logical groupings of resources distinct from the physical constructs of Availability Domains. An individual compartment can contain resources across Availability Domains.

How are compartments used for access control?

All policies are attached to either the root compartment or a child compartment. Each policy consists of one or more policy statements that follow this basic syntax:

Allow group to in compartment

Policy statements allow you to use compartments to simplify permission management; for instance, you can write a policy that allows the group HRAdministrators to manage all resources in the compartment HRCompartment.

Can I delete compartments?

Yes, you can delete compartments.

Can I move entire compartment trees and their included resources?

Yes, you can move entire compartment trees and their included resources to other parent compartments.

Can I move resources, such as a compute instance or block volume, from one compartment into another?

Yes, you can move resources from one compartment into another.

Can I create a hierarchy of compartments?

Yes, you can create a hierarchy of compartments by nesting them. With hierarchical or nested compartments, the system administrator is able to organize resources and enable lower-level administrators to do the same, while still retaining full visibility and control via policy.

How many levels deep can you nest compartments?

The maximum depth of a nested compartment is six.

Do policies on a higher-level compartment apply to a sub compartment?

Yes, policies on higher-level compartments do get inherited by sub compartments.

Am I able to track costs and usage by compartments?

Yes, you can track costs and usage by compartments in My Services.

What is the root compartment?

For each account, Oracle Cloud Infrastructure automatically creates a top-level compartment known as the root compartment. Much like the root folder in a file system, the root compartment behaves exactly like its child compartments, except for a few special characteristics:

  • Because permissions are hierarchical, group permissions in the root compartment will apply to all child compartments. For example, if group NetworkAdmins is given permission to manage Virtual Cloud Networks (VCN) in the root compartment, that group will be able to manage VCNs in all compartments.
  • Currently, all users and groups are created inside the root compartment. Policies can be used to grant them access to only specific child compartments.

Note: Currently, you can create additional compartments only within the root compartment, and not within other compartments.

When should I create resources in the root compartment and when should I create them in a child compartment?

Generally, resources should be created in a compartment that is not the root compartment. It is best to design your compartment hierarchy before you begin creating compartments and resources.

Users

What can a Oracle Cloud Infrastructure Console user do?

A user is someone who can successfully authenticate against OCI IAM, and who has sufficient privileges to either consume or manage cloud resources within your account. Administrators can create one or more users within their account and assign them to groups in order to give them permissions to resources in specific compartments.

Who is able to create and manage users?

Your account is provisioned with a single user: the default administrator, and a single group: Administrators, of which the default administrator user is a member. This group (Administrators) has full access in your account. This special user (default administrator) must create any additional users, or grant permission to other users to create new users.

What access does a new user have upon creation?

By default, a new user does not have permission to use any resource or service within your account – all permissions must be explicitly granted. This approach allows you to adhere to the security principle of least privilege whereby you grant each user only the access required for that specific user. You must either explicitly add the user to an existing group or create a new group for them, and then assign appropriate permissions to that group through a policy.

Can I enable and disable user access?

Administrators can deactivate or lock a user to disable their access temporarily. They can also reset user passwords or remove keys.

Can we set passwords to expire? How can I rotate credentials?

Yes, password policies allow you to set an expiration time for passwords. You can also automate password resets, key changes, or edits to users and group memberships through REST API and SDKs.

Policies

What is a policy?

A policy is a document consisting of descriptive policy statements that grant specific permissions to groups of users. They are written with an easy-to-understand SQL-like syntax. Example policies might enforce:

  • System Administrators can "terminate" or "reboot" your bare metal compute instances.
  • Network Administrators can fully administer all network-related infrastructure resources.
  • IT Administrators can create users and edit group memberships

A policy allows a group to work in certain ways with specific types of resources in a particular compartment. Optionally, policies can contain a conditional clause ("where ...") that further restricts the policy statement. Policies adhere to the following syntax:

Allow group to in compartment [where]

For example, here is a policy statement that grants permissions to use compute instances:

Allow group Developers to use instances in compartment ProjectA

  • "group_name" is the name of the group being granted permissions.
  • "verbs" are actions you can take on resources, for example: inspect, read, use, or manage.
  • "resource-type" is the cloud resource to which permissions are being granted. Example resource-types include: instances, volumes, and route-tables.
  • "compartment_name" is the name of the compartment in which the resources are organized.
  • "conditions" are further specifications that narrow the scope of the policy statement. Examples include: "where request.user.id=target.user.id" or "where target.group_name != Administrators".

For more details, see the OCI IAM section of the Oracle Cloud Infrastructure documentation.

Are policies for the root compartment inherited by child compartments?

Yes. A policy granting permissions in the root compartment automatically grants the same permissions for all child compartments. For example, the following policy gives permission to all users in the group "InstanceAdmins" to manage instances in the root compartment as well as all child compartments:

Allow Group InstanceAdmins to manage instances in tenancy

Can policies be limited to specific compartments?

Yes. Each policy is "attached" to a compartment. Where you attach it controls who can then modify it or delete it. If you attach a policy to the root compartment, then anyone with access to manage policies in the root compartment can change or delete it. If you instead attach the policy to the compartment, then anyone with access to manage policies in that compartment can change or delete it. In practical terms, this means it is easy to give compartment administrators (i.e., a group with access to "manage all-resources" in the compartment) access to manage their own compartment's policies, without giving them broader access to manage policies that reside in the account.

Where can I learn more about writing policy statements?

For more information about policy and policy statements, see "Getting Started with Policies" and "Common Policies" in the Oracle Cloud Infrastructure documentation.

IAM deny policy

OCI Identity and Access Management deny policy FAQs

These FAQs guide users through Oracle Cloud Infrastructure (OCI) Identity and Access Management deny policies, which allow users who can manage policies to explicitly block actions, enhancing security and simplifying access control in OCI tenancies. For more details, see the OCI Identity and Access Management documentation.

Getting started with IAM Deny

How do I enable the IAM Deny feature in OCI?

IAM Deny is an opt-in feature that must be explicitly enabled by a tenancy administrator via going to the OCI Console, then Policies, then Actions, then Policy settings. It can’t be enabled by regular users or policy authors. Once enabled, the feature becomes a permanent part of the tenancy’s IAM framework and can’t be disabled via the UI. However, a tenancy administrator with the ability to write deny policies can effectively control the use of deny policies by writing a root-level deny policy that blocks all users from creating or modifying deny policies, except for the default administrator group. An example is Deny any-user to manage policies in tenancy where target.policy.type='DENY'

When IAM Deny is enabled

  • OCI automatically seeds a default deny policy at the root compartment for safe usage.
  • Only the default administrator group and the tenancy administrator who enabled IAM Deny retain permissions to configure and manage deny policies.
  • The tenancy administrator can then update the default deny policy to allow authorized users—such as administrator groups in the Banking, Investments, and Compliance compartments—to write deny policies in the OCI Console.

What are OCI Identity and Access Management deny statements?

With OCI Identity and Access Management deny statements, you can write explicit deny policies to block specific actions in OCI tenancies, complementing OCI Identity and Access Management allow statements for precise access control. For example, you can use Deny any-user to inspect all-resources in tenancy where request.service='streaming' to set a guardrail preventing all access to the OCI Streaming service across your tenancy, while allowing other permissions via allow statements.

What are the limits for IAM deny policies?

IAM deny policies share the same limits as allow policies. A tenancy can have up to 100 IAM policy objects, each containing up to 50 policy statements (deny or allow), but the total number of policy statements across all objects in the tenancy is limited to 100.

Which meta-verbs are supported by IAM deny policies, and are they new or existing?

IAM deny policies use the existing meta-verbs: manage, use, read, and inspect. No new meta-verbs are introduced. Unlike allow statements, which grant permissions additively (for example, manage includes all lower permissions), deny statements are subtractive, blocking only the specified permission and any higher level in the hierarchy.

For example, the policy Deny group DevOps to manage instance in compartment Prod blocks only the manage permission, allowing DevOps to perform use, read, and inspect actions. However, denying inspect blocks all permissions, as it’s the base-level permission.

Policy creation and management

Where do I write deny policies in the OCI Console?

Deny policies are created in the same OCI Console interface as allow policies. Navigate to Identity & Security, then Policies, select a compartment, and use the policy editor to add the deny keyword alongside allow. The process requires no separate interface.

Is there a separate policy object for deny policies?

No, deny policies use the same policy object as allow policies. Both are managed within the same policy object, simplifying administration.

Can I include deny and allow statements in a single IAM policy object?

Yes, you can combine deny and allow statements in one policy object for flexible access control.

For example, a single policy could include allow and deny statements as shown below:

Deny group Interns to use instance in compartment Finance
Allow group Admins to manage all-resources in compartment Finance

These policies allow Admins to manage all resources in the Finance compartment while preventing Interns from doing any write operation on instances, streamlining access control.

How can I prevent users who can manage policies from writing deny policies?

To prevent policy users who can manage policies from writing deny policies, create a deny policy at root level to block deny policy creation.

Example: Deny group PolicyAdmins to manage policies in tenancy where target.policy.type='DENY'

This policy ensures PolicyAdmins can’t create or modify deny policies while still allowing them to manage allow policies. Default administrator groups remain exempt and can write deny policies if needed.

How can I block an entire OCI service using an IAM deny policy?

To block an entire OCI service, create a deny policy at the root compartment targeting the service’s resources or actions using a condition such as request.service.name.

For example, to block the OCI Streaming service tenancywide

Deny any-user to inspect all-resources in tenancy where request.service.name='streaming'

This policy prevents all access to the OCI Streaming service, which is useful for compliance in industries such as healthcare. Place the policy at the root compartment to ensure it applies across all compartments, reducing policy sprawl.

How can I deny a group from managing resources in a specific region?

To prevent a group from managing resources in a specific region, use a deny policy with a request.region condition.

For example, if you want to prevent a group from performing any actions beyond read-only access in a specific region, you can write a deny policy like this:

Deny group RegionalAdmins to use all-resources in tenancy where request.region='sa-saopaulo-1'

This policy blocks the RegionalAdmins group from using resources in the São Paulo region but allows use, read, and inspect permissions. It’s ideal for financial institutions addressing compliance with regional data residency laws.

How can I deny a group from accessing compute instances in a specific compartment?

To deny a group from accessing compute instances in a specific compartment, use

Deny group DevTeam to inspect instance in compartment ProjectX

This policy blocks all permissions (inspect, read, use, manage) on compute instances in the ProjectX compartment. For example, a technology company can use this to prevent the DevTeam from accessing production instances, isolating development and production environments for enhanced security.

How can I deny a group from managing object storage in a specific compartment?

To deny a group from managing object storage resources in a specific compartment, use

Deny group StorageUsers to inspect object-family in compartment DataLake

This policy blocks all permissions (inspect, read, use, manage) on object storage resources in the DataLake compartment. For example, a healthcare organization can apply this to prevent StorageUsers from accessing sensitive patient data, supporting compliance with privacy regulations.

How can I delegate tasks to users who can manage policy in a child compartment without allowing them to modify certain resources or write deny policies?

To delegate tasks securely to users who can manage policy in a child compartment, you can

  • Grant specific permissions for designated compartments or resources using allow policies.
  • Restrict deny policy authorship to prevent users who can manage policy in a child compartment from creating disruptive policies.
  • Use deny policies to block access to sensitive resources.

For example, to allow users who can manage policy in a child compartment to manage compute resources in a compartment while restricting network changes and deny policy creation, use the following policies:

Deny group ProjectAdmins to manage network-family in compartment ProjectX Deny group ProjectAdmins to manage policies in compartment ProjectXwhere target.policy.type='DENY'

Allow group ProjectAdmins to manage instance-family in compartment ProjectX

These policies enable ProjectAdmins to manage instances in ProjectX, block them from modifying networks, and prevent them from writing deny policies, supporting secure delegation. A financial organization might use this approach to allow sub-admins to manage compute resources while maintaining strict control over network configurations and policy management.

Safety and recovery mechanisms

Are deny policies evaluated before allow policies?

Yes, OCI Identiy and Access Management uses a deny first evaluation model, where deny policies are evaluated before allow policies in the compartment hierarchy. If a request matches a deny policy, access is blocked, regardless of any allow policies. Default administrator groups are exempt from deny policies to prevent lockouts.

For example, the following policies may exist in the Prod compartment:

Deny group Devs to manage instance-family in compartment Prod
Allow group Devs to manage all-resources in compartment Prod

The deny policy blocks Devs from managing instances, while default admins can still manage instances.

What happens if a user who can manage policies writes a deny policy that locks out all users in the tenancy?

The default administrator group is exempt from deny policies, so its members can log in, view, and edit policies to resolve lockouts. This safeguard helps prevent tenancywide outages.

Example: If Deny any-user to inspect all-resources in tenancy is applied, default admins group users can still log in and access the policy editor to remove or adjust it.

How do I recover from a tenancywide deny policy that locks out all users?

A tenancywide deny policy, such as Deny any-user to inspect all-resources in tenancy, can block all user access, causing an outage. To recover:

1. Log in as a member of the default administrator group (exempt from deny policies).
2. In the OCI Console, go to Identity & Security, then Policies.
3. Locate the problematic policy in the root compartment.
4. Edit or delete the policy (for example, change Deny any-user to inspect all-resources in tenancy to Deny group Interns to inspect all-resources in tenancy).
5. Alternatively, use the following OCI command-line interface: oci iam policy update --policy-id --statements '["Deny group Interns to inspect all-resources in tenancy"]

For example, if a user who can manage policy in a child compartment accidentally applies Deny any-user to inspect all-resources in tenancy, a default admin group user can log in and modify it to target only the Guests group, preventing future lockouts. To avoid such issues, test policies thoroughly and limit deny policy authorship.

Permission effects

What happens if I deny the “manage” permission?

Denying manage blocks only the manage permission, leaving use, read, and inspect intact.

Example: Deny group DevOps to manage instance in compartment Production prevents DevOps from managing instances but allows them to use, read, or inspect them.

What happens if I deny the “use” permission?

Denying use blocks both use and manage permissions, but read and inspect are still allowed.

Example: Deny group Testers to use bucket in compartment QA stops Testers from using or managing buckets but permits reading or inspecting them.

What happens if I deny the “read” permission?

Denying read blocks read, use, and manage permissions, but inspect is still allowed.

Example: Deny group Auditors to read logs in compartment Logging prevents Auditors from reading, using, or managing logs but allows inspection.

What happens if I deny the “inspect” permission?

Denying inspect blocks all permissions (inspect, read, use, manage) since inspect is the base-level permission.

Example: Deny group Viewers to inspect instance in compartment Public completely blocks Viewers from accessing instances.

Advanced use cases and troubleshooting

How do I monitor deny policies to ensure they work as intended?

Review OCI audit logs to track actions blocked by deny policies. If a policy such as Deny any-user to inspect cloud-shell in tenancy causes issues, refine it to Deny group Interns to inspect cloud-shell in tenancy. Set up alerts for policy changes to stay proactive.

Example: Monitor logs to adjust Deny group Drivers to manage instance-family in compartment Fleet if it blocks legitimate tasks.

What are common mistakes to avoid with deny policies?

OCI’s deny first model prioritizes deny policies over allow policies, which can lead to disruptions if policies are overly broad. Common mistakes include applying tenancywide or compartmentwide lockouts or using overly broad tag-based conditions.

For example, a policy such as Deny any-user to inspect all-resources in tenancy can block all access, causing a tenancywide lockout. Instead, use targeted policies, such as the following:

Deny group Interns to inspect all-resources in compartment Public

This restricts access for the Interns group only, avoiding unintended disruptions. A technology company might use this approach to limit guest access while preserving functionality for other users. To prevent issues, test policies in a sandbox environment, keep them simple, and restrict deny policy authorship.

Are deny statements supported for cross-tenancy use cases?

Yes, deny statements support cross-tenancy scenarios. A single deny endorse or deny admit statement can block cross-tenancy requests, unlike endorse/admit pairs requiring both to be satisfied.

The following source tenancy is an example:

Endorse group Devs to use object-family in tenancy PartnerTenancy Deny endorse group Devs to manage object-family in tenancy PartnerTenancy

This allows Devs to use object storage in the PartnerTenancy but blocks management actions. A partner organization can use this to enable data sharing while maintaining control over resources.

How do deny policies interact with OCI Zero Trust Packet Routing?

OCI Zero Trust Packet Routing operates at layer 4 (network level) of the Open Systems Interconnection model while IAM deny policies enforce access at layer 7 (application level). If OCI Zero Trust Packet Routing allows communication, IAM deny policies can still block actions.

Example:

  • OCI Zero Trust Packet Routing policy: Allow dynamic-group FrontEnd in VCN web:vcn to connect to backend:server-instance in VCN vcn:server permits network traffic.
  • IAM policy: Deny dynamic-group FrontEnd to manage instance-family in compartment ProjectA blocks instance management despite OCI Zero Trust Packet Routing allowance.

OCI Zero Trust Packet Routing and IAM policies are evaluated sequentially, with IAM as the final gatekeeper.

How do system-defined policies interact with deny policies?

Standard system policies always override user-defined deny policies to ensure essential services function (for example, Allow any-user to read domains in tenancy where target.domain.id='request.domain.id').

Example: A deny policy such as Deny group Users to read domains in tenancy won’t block a standard system policy allowing domain access.

Are deny policies evaluated differently from allow policies?

OCI Identity and Access Management uses a deny first evaluation model, where deny policies are evaluated before allow policies in the compartment hierarchy. If a request matches a deny policy, access is blocked, regardless of any allow policies. System-defined policies may override user-defined denies (see question 27). Default administrator groups are exempt from deny policies, so they can manage policies during lockouts.

Example: If Deny group Users to manage instance-family in compartment Prod exists alongside Allow group Users to manage all-resources in compartment Prod, the deny policy blocks instance management.

Does IAM Deny override Oracle identity domain administration roles (for example, identity domain administrator, security administrator, and user manager)?

In the current release, IAM Deny policies don’t override Oracle Identity Cloud Service administration roles (for example, identity domain administrator, security administrator, and user manager). This is a limitation. In the next release, IAM Deny will take precedence over Oracle Identity Cloud Service administration roles for consistent access control.

How can I use IAM Deny so that access to a service only happens through the new OCI Private Service Access?

OCI Private Service Access allows access to Oracle services over a private network path instead of through the public internet. OCI Private Service Access is designed for customers who want private connectivity between their workloads and Oracle services—for compliance, performance, or security reasons.

If you’re using OCI Private Service Access to securely access a service (such as OCI Object Storage or OCI Streaming), you may want to enforce that all access must go through OCI Private Service Access. With IAM Deny, you can explicitly block all non-OCI Private Service Access traffic to a service, even if allow policies exist.

For example, to allow access to OCI Object Storage only through OCI Private Service Access, use

Deny any-user to access object-family in tenancy where any {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

This policy prevents users from accessing OCI Object Storage unless their traffic is routed through an OCI Private Service Access endpoint. It’s especially useful if you’ve configured an OCI Private Service Access setup for sensitive data and want to eliminate the risk of access via unintended public routes.

What’s the difference between OCI Identity and Access Management deny policies and Oracle Security Zones, and when should I use them?

OCI offers IAM deny policies and Oracle Security Zones to secure your tenancy by preventing unsafe actions. While both strengthen your security, they differ in how they work and their flexibility.

  • Similarities: Both IAM deny policies and Oracle Security Zones block specific actions to protect your resources and enforce security best practices in your OCI tenancy.
  • Key differences
    • IAM deny policies: You create custom policies to block actions based on conditions such as user identity, resource type, IP address, or tags. These policies act as guardrails, and starting in the next release they will take precedence over all IAM policies. For example, you can block a specific user group from deleting critical resources if the resource has a specific tag, such as environment:production.
    • Oracle Security Zones: These apply predefined security rules to compartments or the entire tenancy. When enabled, Oracle Security Zones automatically enforces restrictions for some set of OCI services, such as preventing public subnets or disabling encryption. You don’t need to write policies—the rules are built-in and automatically check resource settings.
  • When to use
    • Use IAM deny policies for custom, targeted restrictions, such as blocking specific users or actions based on your defined conditions.
    • Use Oracle Security Zones for automatic, ready-made security rules to enforce best practices with minimal setup.
    • Combine both for stronger protection. Enable Oracle Security Zones for broad, baseline guardrails and add IAM deny policies for specific, tailored controls.

Get help with OCI Identity and Access Management deny policies

For further assistance, visit the OCI Identity and Access Management documentation or contact your OCI account team.

Groups

What is a group?

A group is a collection of users who need similar access privileges to either use or manage a specific resource within your account. Users can be in multiple groups. Permissions are additive. For example, if membership in one group allows a user to use compute instances, and membership in a second group allows that user to manage block volumes, then the user is permitted to manage both instances and block volumes.

Administrators write policies that specify groups (not individual users) with the required access they need, whether to a specific compartment or the account. Administrators then add users to the appropriate groups.

Can I have multiple Administrators?

Yes. Your account is provisioned with a single default administrator who belongs to an Administrators group within your root compartment. This group has full privileges to create and manage all Oracle Cloud Infrastructure resources in your account, including users, groups, policies, and compartments, as well as all other cloud infrastructure resources within any compartments. You can add additional users to this Administrators group.

Features

How does OCI IAM address requirements for password expiration?

Password policies allow you to set an expiration time for passwords. A default password policy sets passwords to expire after 120 days. This is configurable and different policies can be applied to subsets of users.

How can I run tasks on compute instance without embedding user credentials into them?

Use dynamic resource groups to assign a set of compute resources to a group. You can then assign that group permissions through a policy. This enables a compute instance to access other OCI resources in a secure manner without embedding credentials into scripts.

Federation

What is identity federation in Oracle Cloud Infrastructure?

Identity federation is a mechanism to delegate user management for your Oracle Cloud Infrastructure tenancy to another entity called an Identity Provider or IdP. This is useful to companies that have an existing Identity system they would like to use, rather than creating and maintaining a new set of users. Federation requires a one-time configuration between Oracle Cloud Infrastructure and the IdP known as a Federation Trust.

What are federated users?

Federated users (external identities) are users you manage outside of Oracle Cloud Infrastructure (for example, in your corporate directory), but to whom you grant access to your Oracle Cloud Infrastructure account. They differ from Oracle Cloud Infrastructure users, which are created and maintained in your Oracle Cloud Infrastructure account.

Can federated users access the Oracle Cloud Infrastructure Console?

Yes. Federated users can access the Oracle Cloud Infrastructure Console.

Can federated users access the Oracle Cloud Infrastructure SDK and CLI?

Yes. Federated users can access the Oracle Cloud Infrastructure SDK and CLI.

What actions can Oracle Cloud Infrastructure users perform in the Console that federated users cannot perform?

Federated users cannot change nor reset their passwords in the Oracle Cloud Infrastructure Console.

How do I control what a federated user is allowed to do when signed-in to the console?

You use the same Oracle Cloud Infrastructure policies to manage federated users that you use to manage native users. You map roles and groups in your Identity Provider to groups in Oracle Cloud Infrastructure. When a federated user logs in, the Oracle Cloud Infrastructure Console then applies policies based on their Oracle Cloud Infrastructure group membership, just as with native users. See the documentation for examples.

A single role or group in your Identity Provider can be mapped to multiple Oracle Cloud Infrastructure groups. Also, multiple roles or groups in your Identity Provider can be mapped to a single Oracle Cloud Infrastructure group.

How many federated users can I give access to the Oracle Cloud Infrastructure Console?

There is no limit to the number of federated users who can be given access to the console.

Which Identity Providers do you support?

OCI IAM supports any SAML 2.0-, Open ID Connect-, or OAuth- compliant identity provider including popular solutions such as Oracle Access Manager, Microsoft Active Directory Federation Services (AD FS), and Okta.

Multifactor authentication

What is multifactor authentication (MFA), and why is it important?

Historically, accounts were secured with a simple username and password. But passwords can be difficult to remember and relatively easy to capture using common cyberattack techniques, such as network sniffing, phishing, and brute-force attacks. If somebody steals your credentials, they can impersonate you and access all of your accounts and resources.

Multifactor authentication (MFA) is a popular security feature that helps reduce the risk of account takeover by strengthening the assurance that an application user is who they claim to be. MFA requires users to provide more than one authentication factor. There are three categories of authentication factors: something you know (such as a password or PIN), something you have (such as a security token or mobile phone), and something you are (such as biometric data like a fingerprint or face scan). With MFA enabled, even if an attacker manages to obtain your password, they will not be able to authenticate as you without also providing the additional evidence required by MFA. This can help prevent unauthorized access and protect against sensitive information being compromised or inappropriate actions being taken. Enabling MFA also helps address regulatory compliance requirements and adherence to industry standards, such as those provided by the National Institute of Standards and Technology (NIST).

Who should use MFA?

Oracle recommends enabling MFA for all users. At a minimum, you should enable MFA for users with administrative privileges, such as the ability to create and manage OCI resources. You should also require MFA for access to any application that hosts sensitive information or allows for high-risk actions.

What is the end user experience when administrators enable MFA?

When MFA is enabled for the first time by an administrator, users will be prompted to enroll in MFA during their next sign-in. After initial enrollment, users will be challenged for MFA during the sign-in process on each subsequent visit. If the administrator enables Trusted Devices, users will have an option to select "trust this device," which removes the requirement for MFA if the user returns on the same device.

For more information, users can reference the following guidance:

Is MFA mandatory in all circumstances?

No. MFA is not strictly mandatory in all circumstances. If you are granting access to a public website, for example, you typically would not require any authentication. If you want users to sign in when making a purchase so you know which account to charge and where to deliver products, perhaps a username and password are sufficient. But, if that same user wants to change the payment method or delivery address, or if the application allows actions that could impact your organization, then MFA is recommended.

Oracle strongly recommends that you enable MFA for all cloud and application administrators. Ultimately, you should evaluate whether to enforce MFA based on your organization's internal security policies and risk assessment. But it's a good practice to start with a policy that MFA is always mandatory and require executive approvals for any applications for which you want to make MFA optional.

Which MFA factors are available to me? Is there a cost?

To fully understand available factors and cost, it's important to first understand which type of OCI tenancy you have. To determine if your tenancy has OCI Identity and Access Management (IAM) with identity domains or if it has OCI IAM without identity domains, review this documentation.

  • If your tenancy has OCI IAM with identity domains, all identity domain types support MFA at no additional cost. Identity domains of type Free are not able to use SMS as an authentication factor but other factors are available. For full details, please review the OCI IAM with identity domains MFA documentation.
  • If your tenancy has OCI IAM without identity domains, you have two options for MFA:
    • Enable MFA for direct user sign-in via the OCI IAM service. This option offers a limited set of authentication factors at no additional cost. For full details, please review the OCI IAM without identity domains MFA documentation.
    • Leverage Oracle Identity Cloud Service (IDCS) to authenticate users into OCI. This option offers more MFA features and authentication choices.
  • If you are using IDCS to authenticate, there are two license types:
    • IDCS Foundation (free-tier) supports MFA only for access to the OCI console, at no cost, with a limited set of authentication factors as documented here. To protect other applications, you would need to upgrade to IDCS Standard.
    • IDCS Standard supports a broad range of MFA options for any protected service or application at no additional cost. For full details, please review the Identity Cloud Service (IDCS) MFA documentation.

Where can I learn more about how to implement MFA?

The specific instructions for implementing MFA vary depending on which type of OCI tenancy you have. To determine if your tenancy has OCI IAM with identity domains or if it has OCI IAM without identity domains, review this documentation.

What happens if I don’t implement MFA?

If you don't implement MFA, you will have an increased risk that a targeted account takeover attack could succeed. But with MFA, your tenancy and/or other authentication processes will continue to operate normally.