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.
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.
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.
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.
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.
The key concepts of IAM are:
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.
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.
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.
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.
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.
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:
Yes. Compartments are logical groupings of resources distinct from the physical constructs of Availability Domains. An individual compartment can contain resources across Availability Domains.
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.
Yes, you can delete compartments.
Yes, you can move entire compartment trees and their included resources to other parent compartments.
Yes, you can move resources from one compartment into another.
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.
The maximum depth of a nested compartment is six.
Yes, policies on higher-level compartments do get inherited by sub compartments.
Yes, you can track costs and usage by compartments in My Services.
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:
Note: Currently, you can create additional compartments only within the root compartment, and not within other compartments.
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. Currently, resources cannot be moved from one compartment to another, and compartments cannot be edited or deleted.
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.
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.
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.
Administrators can deactivate or lock a user to disable their access temporarily. They can also reset user passwords or remove keys.
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.
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:
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
For more details, see the OCI IAM section of the Oracle Cloud Infrastructure documentation.
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
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.
For more information about policy and policy statements, see "Getting Started with Policies" and "Common Policies" in the Oracle Cloud Infrastructure documentation.
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.
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.
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.
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.
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.
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.
Yes. Federated users can access the Oracle Cloud Infrastructure Console.
Yes. Federated users can access the Oracle Cloud Infrastructure SDK and CLI.
Federated users cannot change nor reset their passwords in the Oracle Cloud Infrastructure 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.
There is no limit to the number of federated users who can be given access to the console.
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.