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.

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.