Integrate with Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)

You can establish a connection between Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) and Oracle Access Governance as an authoritative source and as a managed system. To achieve this, use the Orchestrated Systems functionality available in the Oracle Access Governance Console.

The OCI Orchestrated System supports the following modes and both included, by default:

  • Authoritative Source: You can use OCI as an authoritative (trusted) source of identity information for Oracle Access Governance.
  • Managed System: You can manage OCI IAM groups and application roles, including certifying policies and group membership using Oracle Access Governance. See Supported Operations for Oracle Cloud Infrastructure (OCI).

Note:

Earlier releases of Oracle Access Governance used API Key Access to connect with OCI IAM. This method is now deprecated and is replaced with Resource Principal Access. Details of how to setup a new orchestrated system using this method is provided in Configure Integration with OCI IAM. If you have existing orchestrated systems using the deprecated API Key Access you should migrate to the new method by following the instructions in How To Migrate API Key Access To Resource Principal Access.

Terminology

Before configuring integration of Oracle Access Governance with OCI IAM you should have an understanding of the following terms:

Table - Terminology

Term Description
OCI Orchestrated System Represents an OCI tenancy integrated with Oracle Access Governance.
Requesting Tenancy Tenancy of the Oracle Access Governance Service Instance that needs to access OCI IAM API in the same or a different tenancy to retrieve/update IAM entities being governed.
Responding Tenancy Customer tenancy where OCI IAM identity data is present.
Intra Tenant Access Use case when you have a single OCI tenancy acting as Requestor and Responder.
Cross Tenant Access Use case when you have multiple OCI tenancies, and the Requesting Tenancy is a separate instance from the Responding Tenancy.
Resource Principal A principal type in OCI IAM that eliminates the need to create and manage OCI User credentials for integration access.

Prerequisites

Before you can establish a connection, you need to create OCI policies that allow your orchestrated system to access the OCI instance you want to integrate with.

General Requirements

General prerequisites required to integrate Oracle Access Governance with OCI IAM include:

  • Your cloud account must use Identity Domains to manage identities on OCI.
  • As a cloud administrator, you must be able to manage policies in the root compartment of your tenancy.
  • If the responding OCI Tenancy being governed is outside the region of the requesting Oracle Access Governance Service Instance, then it must subscribe to a tenancy residing in the region of the requesting Oracle Access Governance Service Instance.

How Oracle Access Governance Connects With Target OCI IAM Instances

In order to integrate Oracle Access Governance with OCI IAM orchestrated systems, you need to configure a connection using the OCI IAM API and Resource Principal authentication. Resource principal is a principal type in OCI IAM that eliminates the need to create and manage OCI user credentials for integration access. In order to configure resource principal authentication you need to generate and deploy a set of policies to the tenancy or tenancies involved in your orchestrated system. The placement of these policies is explained in the following diagrams:

Policy Placement when Oracle Access Governance Service Instance (Requester) and OCI Tenancy (Responder) being governed are in the same tenancy

You can have a use case where a single OCI tenancy performs both of the following functions:
  • Host tenancy on which the Oracle Access Governance Service Instance resides. This is the requesting tenancy which needs to access the OCI IAM API from a responding tenancy, so that data can be retrieved/updated for the identities that are being governed.
  • Tenancy where OCI IAM identity data is present.

In this use case you only have to deploy the generated policies to the one tenancy. They will cover the access required for the tenancy as both requestor and responder.

Single Tenancy

Policy Placement when Oracle Access Governance Service Instance (Requester) and OCI Tenancy (Responder) being governed are in different tenancies

You can also have a use case where the requesting tenancy and responding tenancy reside on separate OCI tenancies. In this case, you need to deploy policies on the relevant tenancy depending on their function:
  • Policies relevant to the requesting tenancy should be deployed to the OCI where your Oracle Access Governance Service Instance resides.
  • Policies relevant to the responding tenancy should be deployed to the tenancy where your OCI IAM identity data is present.

AG SI/External

How To Setup Required Policies For OCI IAM Integration With Oracle Access Governance

Before you can establish a connection, you need to create OCI policies that allow your orchestrated system to access the target system.

To setup the required policies for integration of OCI IAM with Oracle Access Governance you need to perform the following steps:
  1. Obtain the policy statements generated in the Integration Settings of your orchestrated system. Depending on the use case this may be a single set of statements for a Single Tenancy integration, or two sets of statements for an AG Service Instance/External Tenancy setup. The policies for your specific configuration are generated based in information you provide during the creation of your orchestrated system, details of which are provided in Configure Integration with OCI IAM for the Integration Settings dialog. Ensure that you copy the statements exactly as they are shown in the Integration Settings.
  2. Create the policies in the root compartment of the relevant tenancy.

Configure Integration with OCI IAM

Integration with Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) is achieved by configuring a new orchestrated system with the Oracle Access Governance Console.

Navigate to the Orchestrated Systems Page

Navigate to the Orchestrated Systems page of the Oracle Access Governance Console, by following these steps:
  1. From the Oracle Access Governance navigation menu icon Navigation menu, select Service Administration → Orchestrated Systems.
  2. Click the Add an orchestrated system button to start the workflow.

Select system

On the Select system step of the workflow, you can specify which type of application you would like to onboard.

  1. Select Oracle Cloud Infrastructure.
  2. Click Next.

Enter details

On the Enter Details step of the workflow, enter the details for the orchestrated system:
  1. Enter a name for the system you want to connect to in the What do you want to call this system? field.
  2. Enter a description for the system in the How do you want to describe this system? field.
  3. Click Next.

Add owners

You can associate resource ownership by adding primary and additional owners. This drives self-service as these owners can then manage (read, update or delete) the resources that they own. By default, the resource creator is designated as the resource owner. You can assign one primary owner and up to 20 additional owners for the resources.

Note:

When setting up the first Orchestrated System for your service instance, you can assign owners only after you enable the identities from the Manage Identities section.
To add owners:
  1. Select an Oracle Access Governance active user as the primary owner in the Who is the primary owner? field.
  2. Select one or more additional owners in the Who else owns it? list. You can add up to 20 additional owners for the resource.
You can view the Primary Owner in the list. All the owners can view and manage the resources that they own.

Account settings

On the Account settings step of the workflow, enter details of how you would like to manage accounts with Oracle Access Governance when configured as a managed system:
  1. Select to allow Oracle Access Governance to create new accounts when a permission is requested, if the account does not already exist. By default this option is selected meaning that an account will be created if it does not exist, when a permission is requested. If the option is unselected then permissions can only be provisioned where the account already exists in the orchestrated system. If permission is requested where no user exists then the provisioning operation will fail.
  2. Select where and who to send notification emails when an account is created. The default setting is User. You can select one, both, or none of these options. If you select no options then notifications will not be sent when an account is created.
    • User
    • User manager
  3. When an identity leaves your enterprise you should remove access to their accounts. You can select what to do with the account when this happens. Select one of the following options:
    • Delete
    • Disable
    • No action

    Note:

    The options above are only displayed if supported in the orchestrated system type being configured. For example, if Delete is not supported, then you will only see the Disable and No action options.
  4. When all permissions for an account are removed, for example when moving from one department to another, you may need to adjust what accounts the identity has access to. You can select what to do with the account when this happens. Select one of the following options:
    • Delete
    • Disable
    • No action

    Note:

    The options above are only displayed if supported in the orchestrated system type being configured. For example, if Delete is not supported, then you will only see the Disable and No action options.
  5. If you want Oracle Access Governance to manage accounts created directly in the orchestrated system you can select the Manage accounts that are not created by Access Governance option. This will reconcile accounts created in the managed system and will allow you to manage them from Oracle Access Governance.

Note:

If you do not configure your system as a managed system then this step in the workflow will display but is not enabled. In this case you proceed directly to the Integration settings step of the workflow.

Note:

If your orchestrated system requires dynamic schema discovery, as with the and integrations, then only the notification email destination can be set (User, Usermanager) when creating the orchestrated system. You cannot set the disable/delete rules for movers and leavers. To do this you need to create the orchestrated system, and then update the account settings as described in Configure Orchestrated System Account Settings.

Integration settings

On the Integration settings step of the workflow, enter the configuration details required to allow Oracle Access Governance to connect to the system.

  1. What is the OCID of the OCI tenancy being integrated?: Enter the OCID for the responding tenancy. For further information regarding OCIDs see Oracle Cloud Identifier, OCID Syntax, and Where to Get the Tenancy's OCID and User's OCID.

    Note:

    You cannot create multiple orchestrated systems using the same tenancy ID. Use a unique tenancy for each system.
  2. What is the OCI tenancy's home region?: Enter the home region for the target OCI tenancy, using the region identifier. The region identifier for your home region can be found in Regions, the identifier for US East (Ashburn) is us-ashburn-1, for example. For further information on home region, see The Home Region, and How do I find my tenancy home region?.
  3. Which domain names should be included?: By default, all domains in the tenancy will be ingested when you run a data load into Oracle Access Governance. If you have multiple domains you may want to restrict which domains are loaded. This parameter allows you to specify which domains you want to load. Select the domains from which you want to ingest data. If this is left blank, then all domains will be included.
  4. Based on the information you have entered in the previous steps, the policy statements required to configure Resource Principal access will be displayed under the Required OCI policies drop down. Copy these exactly as generated and apply in the root compartmen of the relevant tenancy. Further details on the required policies can be found in How Oracle Access Governance Connects With Target OCI IAM Instances. See Managing Policies for details on how to apply the policies to your tenancy.
  5. Optionally you can test the connection by clicking the Test integration button.
  6. If you are happy with your settings click Add.

Finish Up

Finally, you are given a choice whether to further configure your orchestrated system before running a data load, or accept the default configuration and initiate a data load. Select one from:
  • Customize before enabling the system for data loads
  • Activate and prepare the data load with the provided defaults

How To Migrate API Key Access To Resource Principal Access

If you have existing OCI orchestrated systems that use the API Key access method to connect, then you should migrate at your earliest convenience to Resource Principal access method. While the API Key access method will continue to function, no edits to the existing configuration can be made. The API Key access method will, in time. be deprecated and Resource Principal is the required method moving forward.

In order to migrate from API Key access to Resource Principal access you should complete the following tasks:
  1. Navigate to the Integration settings page following the instructions given in Configure Orchestrated System Integration Settings.
  2. On the Integration settings page you will see a deprecation warning if the orchestrated system is using the API Key access method. To initiate the migration process click on the Learn more about migrating button. The policies required to update your OCI tenancies to use Resource Principal access will be displayed and should be copied and applied exactly as generated. Further details on the required policies can be found in How Oracle Access Governance Connects With Target OCI IAM Instances. See Managing Policies for details on how to apply the policies to your tenancy.
  3. Once you have applied your policies, click the Test integration button to check the connection. If you have any errors or messages, review your configuration. You will not be able to complete the migration until the test is successful.
  4. If your connection is confirmed then click on the Migrate button to start the migration.
  5. When the migration completes, you will see a message confirming that the integration is now using the required access method.

Note:

Once you have completed migration to the Resource Principal method you cannot reverse the procedure and reinstate API Keys method on your orchestrated system.

Supported Operations for OCI

The Oracle Cloud Infrastructure Orchestrated System supports the following account operations when provisioning a user.

Group Provisioning - Assign Groups to Users

You can assign multiple OCI IAM groups for an OCI domain from Oracle Access Governance. For example, you can provision developers working on multiple projects to different OCI IAM resources, each group associated with specific resources.

To do this:
  • Create an access bundle for the OCI orchestrated system and select the OCI IAM groups available in the domain. For details, see Create Access Bundle.
  • To assign users in OCI with OCI groups:
    • Create an Oracle Access Governance policy and associate the groups part of the access bundle with identity collection in that policy. For details, see Manage Policies and Create Identity Collections.
    • You may also request access bundles or roles directly by raising a request from the self service flows. For details, see Request Access.

You may certify identity access reviews for the groups granted through access request by Oracle Access Governance. For more information, see Eligible System Oracle Cloud Infrastructure.

Application Role Provisioning - Assign Roles

Using Oracle Access Governance, you can provision OCI application roles to OCI identities for services running in an OCI domain. You can even use this to provision Oracle Access Governance roles to other identities. For example, you can package relevant Oracle Access Governance application roles and provision the access bundle to an IAM Specialist group.
  • Create an access bundle for the OCI orchestrated system and select application roles for services available in the domain. For details, see Create Access Bundle.
  • To assign users in OCI with application roles:
    • Create an Oracle Access Governance policy. Associate access bundles comprising application roles with an identity collection in that policy. For details, see Manage Policies and Create Identity Collections.
    • You may also request this access bundle or role directly by raising a request from the self service flows. For details, see Request Access.

You may further certify identity access reviews for the roles granted through access request by Oracle Access Governance. For more information, see Eligible System Oracle Cloud Infrastructure.

OCI Policy Reviews : Revoke Over-privileged Policy Statements from OCI Policies

Using Oracle Access Governance, you can certify OCI policies by creating on-demand policy review campaigns from the Oracle Access Governance Console. For example, you may run quarterly reviews on the defined network and storage policy of your tenancy to assess if these meet the principle of least privilege and applicable regulatory requirements.

Create a policy review campaign for OCI policies. Based on the prescriptive insights and recommendations, reviewers can make informed decision to either Approve or Reject entire policy at once, or make decision to Approve or Reject specific policy statement in that policy.

For more information, see Review Access to Systems Managed by Oracle Cloud Infrastructure (OCI) and Create Policy Review Campaigns.

Group Membership Reviews: Accept or Revoke Membership Access from OCI IAM Group

Using Oracle Access Governance, you can certify membership for OCI IAM groups by creating on-demand Identity Collection Review campaigns. For example, you may run group membership reviews to certify that only eligible members are part of the Database Administrator group, managing and maintaining the database infrastructure for your project. An identity with the Sales Analyst role should not be associated with this group.

Create an identity collection review campaign for OCI IAM Groups. Based on the prescriptive insights and recommendations, reviewers can make informed decision to either Approve or Revoke members of the group. If you choose to review OCI IAM groups and it contains a few members provisioned from Oracle Access Governance, then with this review, you can only accept or revoke directly assigned members. For members provisioned from Oracle Access Governance, choose to review the OCI Access Bundles using the Which permissions? tile. For more information, see Review Access to Systems Managed by Oracle Cloud Infrastructure (OCI) and Create Identity Collection Review Campaigns.