Guest Blog: Five considerations for OCI IAM in IDCS-migrated tenancies

This is a guest IAM blog written by OCI Security expert Paul Toal.

Oracle Cloud Infrastructure (OCI) comes with its own, enterprise-class Identity and Access Management (IAM) service, which is used to manage users and their permissions within OCI. It can also be used for managing access to resources, applications, and services outside OCI, including on-premises. If you have been using OCI for some time, you may be familiar with Identity Cloud Service (IDCS) and how it was used to layer additional IAM capabilities over the core OCI IAM service. The capabilities from IDCS have now been merged into OCI through the introduction of OCI IAM Identity Domains, meaning IDCS no longer exists as a separate service. There is a great FAQ posted to answer many common questions about this change, including why Oracle has made the change and the benefits of this change.

Oracle has recently undergone the process of automatically migrating all existing OCI customer tenancies from IDCS to identity domains. In this article, we will examine the implications of the migration and the best practices following a tenancy IAM migration.

If you have a new tenancy, you will only be aware of identity domains. Your tenancy will be created with a single Default identity domain, like the one shown below. If that is the case, then you don’t need to read any further.

This default domain will contain your initial administrative user and IAM policies for bootstrapping your tenancy, i.e., creating additional administrator accounts etc. There is best practice guidance on how to structure your OCI IAM configuration within the Best Practices for Identity and Access Management in Oracle Cloud Infrastructure. This includes the structure of compartments and the creation of additional identity domains for different user types and/or environments etc. It also discusses how the default domain should only be used for OCI administrators and not application users.

For many customers, their tenancies will have been migrated from IDCS tenancies. If you are one of these customers, there will be one or more additional identity domains created.

At a bare minimum, you will have two identity domains; the default one and one called OracleIdentityCloudService, as shown in the figure below.

Furthermore, if you created additional IDCS instances within your tenancy before the migration, these will also have been migrated to identity domains, with each IDCS instance created as a separate identity domain. By default, all identity domains will appear on the login screen for all users. This can be changed by configuring the domain to be hidden from the login screen within the domain configuration.

Another consideration as part of the migration is the group mappings. In pre-migrated tenancies you will likely have configured mappings between IDCS groups and OCI groups.

These mappings remain after the migration for backward support. You will likely be able to remove these mappings once you have implemented IAM policies to replace them.

So, what is the OracleIdentityCloudService identity domain? This is the primordial instance of IDCS that would have existed within your pre-migrated tenancy. It is the IDCS that would have been created automatically when your OCI tenancy was created. Previous IDCS best practice suggested that your OCI administrators should have been created within this primordial IDCS instance, and therefore, post-migration your OCI administrators will now exist within the OracleIdentityCloudService identity domain.

Therefore, with a migrated tenancy and these two identity domains, how should they be used? Here are five best practices to follow for migrated accounts:

1. Only use the Default identity domain for local, break-glass type accounts. Use the OracleIdentityCloudService identity domain for day-to-day OCI administrator accounts, and ideally integrate this with your corporate identity provider for both single sign-on and user lifecycle management.
2. Enable adaptive security with the default risk provider both of your identity domains and configure multi-factor authentication policies for both identity domains.
3. Do not delete the OracleIdentityCloudService identity domain. It contains the accounts necessary for various cloud management tasks. In addition, the user created first within this domain will be designated as the CLOUD_ADMIN. This is a bootstrap user that was created when the tenancy was created and should not be deleted. It has special privileges outside of the tenancy.
4. Continue to create separate identity domains for application users. These should be created in-line with best practices but can segregate user populations either by user type (e.g., employees vs customers) and/or by environments (e.g., production vs test).
5. Review the domain types for each migrated domain against the new domain types available for identity domains to establish whether there is a more appropriate domain that can be used, other than the original type carried over from the migrated IDCS instance.

These 5 points may seem straightforward, but they lay the foundations for a good IAM identity domain design.

I hope you found this information useful. You can read more about Oracle Cloud here, or sign-up for a free trial.