Oracle introduced OCI Identity Domain which provides OCI native identity experience with a complete feature set of an Identity as a Service (IDaaS) system.
IAM in a brand new OCI tenancy which now comes with Identity Domains looks like this -
An Oracle cloud tenancy that supports Identity domains comes with a bootstrap instance called the 'Default' domain. The default domain is 'Free' but poses limits on the number of users/apps/external integrations supported. The purpose of the default domain is to provide all the ncecessary features needed to control access for managing OCI resources.
Customers may choose to create additional domains of different types depending on their specific use cases.
Identity domains support various complex use cases. For example - protecting Oracle packaged apps on-premise or in OCI, Oracle or non-Oracle SaaS Apps and the user life cycle management for these applications.
The goal of this post is to share the 10 best practices to consider when working with Identity Domains.
OCI resources/services can be accessed in two ways - 1) Control plane – Administrative/developer access either via the console or APIs/Terraform to manage resource/service instances. 2) Data plane – Runtime or end user access to OCI resources/services.
For example – Creating a VM instance via OCI console or APIs is considered a control plane access whereas an end user using an SSH key to login to a VM is a data plane access.
Following is a very high level guideline to decide if a default identity domain is sufficient or an additional domain should be created :
Example - control plane : Manage VMs, VCNs or Load balancers.
Example - Managing Oracle Analytics Cloud instances and accessing analytics cloud dashboard.
Example - VBCS application extending SaaS.
This depends on each SaaS service and is out of scope for this post.
A cloud account administrator gets full access to the tenancy and can decide which other users get what level of access. It is important to understand that there are 2 ways to extend this access.
Allow group administrators to manage all-resources in tenancy. This policy cannot be removed. Which means any user that belongs to the 'administrators' group in the default domain can manage all OCI resources in that tenancy. An identity domain administrator can add more users to the ‘administrators’ group, but it is important to ensure that only a small number of users have this highest level of privilege. It is possible to create another group and provide the same level of access as a tenancy administrator, but that is not generally recommended and if you really need to, ensure that the members of that new group are kept to a minimum.
Most mid-size to large customers have a SSO system that they use to login to various third party and in-house applications. Identity domains support industry standard protocols like SAML 2.0 and OIDC to delegate authentication to an external SSO system/Identity provider. This ensures we do not hamper user experience or security by maintaining another password in an identity domain. Most users should login via the federated login method. For SSO via an external provider to work, all the federated users still need to have a footprint in the domain.
There are various ways to bring users into an Identity domain. E.g., SCIM APIs, JIT, AD bridge, provisioning bridge or CSV import. Manual user creation or CSV import should be the last resort for obvious reasons. If the source system is MS Active Directory or LDAP directory, you may use AD bridge or provisioning bridge respectively but in most cases, automating user lifecycle management using SCIM APIs is the best choice. Widely used identity providers like Okta, Azure AD support SCIM integration with OCI Identity domains. Curious to know why JIT may not be sufficient for you ? Read my earlier post here to know more.
When user password is managed by an external system and users are brought into an Identity domain, these users should not have a password in the identity domain. Whenever ‘IsFederated’ attribute is set to true at user creation, such users do not receive Welcome/Password Reset email notifications and they can not set a password locally. Identity domain administrators are a special case! They have a local password in the domain even when they login via a federated Identity Provider and even if ‘isFederated’ flag is set to true.So, ensure that you enable MFA for all administrators and any local users that may need to exist in your identity domain. Ideally the number of administrators/local users should be very small.
CIS recommends a password policy that requires minimum length of 14 or greater, expires passwords within 365 days and prevents password reuse.
Password expiry rule is no longer recommended by NIST - https://pages.nist.gov/800-63-FAQ/#q-b05 .
There are conflicting views in the industry about password expiry enforcement. Organizations have different compliance requirements based on the type of data and workloads deployed in the cloud. Please choose an appropriate password policy defined by your company’s compliance and security requirements.
By default any new Identity domain Default or otherwise comes with a sign-on policy that enforces MFA for OCI Console Application. You may need to alter this policy to enforce MFA for local users only if an external IDP enforces MFA already.
OCI IAM supports various credentials that users could use to authenticate to the system. For managing OCI resources via OCI SDKs/Terraform or directly invoking APIs, a user requires an API key set in the profile. There is no way to enforce an additional authetication factor when an API key is used. For this reason, it is important to ensure that an API key is not set on a tenancy administrator user. If someone manages to get hold of the private key, it would give them access to your OCI kingdom. It is best to set a strong password and enforce MFA for the tenancy administrator. Additionally, the second factor could be a hard token and both password and the physical token can be stored separately in an enterprise safe/vault. For API invocation, service level administrators with specific authorizations/IAM policies should be created.
To protect various PaaS/SaaS and Oracle packaged or custom applications, create additional domains in environment specific compartments.
Many customers have a centralized SIEM system to collect, organize and analyze various security events. The OCI Audit service provides visibility into activities related to your resources and your tenancy. Audit log events can be used for security audits, to track usage of and changes to Oracle Cloud Infrastructure resources, and to help ensure compliance with standards or regulations. IAM domain events can be monitored the same way. Audit logs and SIEM integration pattern is available here . If a customer does not have a SIEM , it is worth considering to use Logging Analytics. A blog post by my colleague Gustavo explains how to setup this integration.
In this post, I made an effort to go through ten design considerations that an IAM admin or cloud account admin should keep in mind when working with Identity domains and before adding more users and granting access to other team members to OCI tenancy.
OCI IAM best practices covering all the OCI IAM components can be found here
and a great post on IAM authorization policy best practices is available here