OCI IAM Identity Domains Best Practices

September 27, 2023 | 7 minute read
Text Size 100%:

Introduction

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 -

 

OCI IAM

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.

  1. Default Domain should be exclusively used for OCI control plane access to manage OCI resources.

    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 :

    1. IaaS resources – Default domain for control plane access. Data plane access varies depending on the resource type. 

      Example - control plane :  Manage VMs, VCNs or Load balancers.

    2. Generic PaaS – Default domain for control plane and data plane.

      Example - Managing Oracle Analytics Cloud instances and accessing analytics cloud dashboard. 

    3. SaaS extensions – A new domain with synchronized identities from SaaS for both control plane and data plane.

      Example - VBCS application extending SaaS.

    4. SaaS – Default domain for control plane. May have an independent identity layer for data plane.

      This depends on each SaaS service and is out of scope for this post.

  2. Number of tenancy administrators should be kept to a minimum.

    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. 

    1. By assigning a specific domain role in the Default domain :  The cloud account admin gets the Identity domain administrator access in the Default domain.You may need additional administrators to manage other specific things in a domain a 'Security Administrator'  to manage the security configuration like setting up Federation/MFA. You may want to add a couple of 'User Manager' users to manage users belonging to a certain group. Creating IAM Admins using a combination of 'User Manager' and 'Security Administrator' roles is recommended. It is best to manage most users via an automated process with corporate user repository as the source. 

       

    2. Via group membership to 'administrators' group in the Default domain : The cloud account owner is also added as a member of the 'administrators' group in the domain which gives that user the OCI tenancy administrator access based on a built-in IAM policy that says - 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.

       

  3. Most domain users should login via a federated Identity provider.

    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.

  4. User life cycle management should be automated. 

    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. 

  5. 'isFederated' attribute should be set to true for all federated and externally managed users.

    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.

  6. A strong password policy should be attached to Identity Domain Administrators or  other local users. 

    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.

  7. MFA for all local users logging into OCI console should be enabled.

    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. 

  8. Setting an API key on a tenancy administrators’ profile should be avoided

    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.  

  9. Create additional domains that are environment specific (Dev/Test/Prod)

    To protect various PaaS/SaaS and Oracle packaged or custom applications, create additional domains in environment specific compartments.  

  10. Identity domain audit logs should be collected and retained in a SIEM system of your choice 

          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. 

Summary

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. 

Want to know more?

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

 

Manasi Vaishampayan


Previous Post

Understanding SSO Behavior in Web Pages Embedded Fusion Application in a Hybrid Environment

Siming Mu | 4 min read

Next Post


IAM Policy for Moving a Secondary Private IP Address to a Different VNIC in OCI

Amit Chakraborty | 2 min read