Data Integration Policies

To control access to Data Integration and the type of access each group of users has, you must create policies.

By default, only the users in the Administrators group can access all Data Integration resources. For everyone else who's involved with Data Integration, you must create policies that gives them proper access to Data Integration resources.

For a complete list of Oracle Cloud Infrastructure policies, see policy reference.

Resource-Types

Data Integration offers both aggregate and individual resource-types for writing policies.

You can use aggregate resource-types to write fewer policies. For example, instead of allowing a group to manage dis-workspaces and dis-work-requests, you can write a policy that allows the group to manage the aggregate resource-type, dis-family.

Aggregate Resource-Type Individual Resource-Types
dis-family

dis-workspaces

dis-work-requests

The APIs covered for the aggregate dis-family resource-type cover the APIs for dis-workspaces and dis-work-requests. For example,
allow group dis-admins to manage dis-family in compartment <compartment_name>
is the same as writing the following two policies:
allow group dis-admins to manage dis-workspaces in compartment <compartment_name>
allow group dis-admins to manage dis-work-requests in compartment <compartment_name>

Supported Variables

To add conditions to your policies, you can use either Oracle Cloud Infrastructure general or service specific variables.

Data Integration supports all the general variables (see General Variables for All Requests), plus additional ones listed here:

Operations for This Resource Type...Can Use These Variables...Variable TypeComments
dis-workspacetarget.workspace.idEntity (OCID)Not available to use with CreateWorkspace

Operations for This API Path...Can Use These Variables...Variable TypeComments
/workspaces/{workspaceId}/applications/{applicationKey}/*target.application.keyEntity (Key)Not available to use with ListApplications, CreateApplication
/workspaces/{workspaceId}/projects/{projectKey}/*target.object.keyEntity (Key)
/workspaces/{workspaceId}/folders/{folderKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateFolder
/workspaces/{workspaceId}/dataflows/{dataflowKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateDataflow, UpdateDataflow
/workspaces/{workspaceId}/tasks/{dataflowKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateTask, UpdateTask
/workspaces/{workspaceId}/dataAssets/{dataAssetKey}/*target.object.keyEntity (Key)
/workspaces/{workspaceId}/connections/{connectionKey}/*

target.object.key

target.folder.key

Entity (Key)target.folder.key only available to use on CreateConnection, UpdateConnection

Details for Verbs + Resource-Type Combinations

There are various Oracle Cloud Infrastructure verbs and resource-types that you can use to create a policy.

The following tables show the permissions and API operations covered by each verb for Data Integration. The level of access is cumulative as you go from inspect to read to use to manage. A plus sign (+) in a table cell indicates incremental access compared to the cell directly above it, whereas "no extra" indicates no incremental access.

dis-work-requests
Permission APIs Fully Covered

INSPECT

DIS_WORK_REQUEST_INSPECT ListWorkRequests
ListWorkRequestErrors
ListWorkRequestLogs

READ

INSPECT +

INSPECT +

DIS_WORK_REQUEST_READ GetWorkRequest

USE

no extra no extra

MANAGE

no extra no extra
Note

Each permission for dis-work-requests fully covers one or more APIs. There are no partially covered APIs for dis-work-requests permissions.
dis-workspaces
Permission APIs Fully Covered

INSPECT

DIS_WORKSPACE_INSPECT ListWorkspaces
DIS_WORKSPACE_OBJECT_INSPECT ListProjects
ListFolders
ListDataFlows
ListTasks
ListTaskValidations
ListApplications
ListPublishedObjects
ListDependentObjects
ListTaskRuns
ListTaskRunLogs
ListDataAssets
ListConnections
ListSchemas
ListDataEntities
ListConnectionValidation
ListDataFlowValidations
ListExternalPublications
ListExternalPublicationValidations
ListReferences
ListPatchChanges
READ

INSPECT +

INSPECT +

DIS_WORKSPACE_READ GetWorkspace
DIS_WORKSPACE_OBJECT_READ GetCountStatistic
GetProject
GetFolder
GetDataFlow
GetTask
GetTaskValidation
GetApplication
GetPatch
GetPublishedObject
GetDependentObject
GetTaskRun
GetDataAsset
GetConnection
GetSchema
GetDataEntity
GetConnectionValidation
GetDataFlowValidation
GetExternalPublication
GetExternalPublicationValidation
GetReference

USE

READ +

READ +

DIS_WORKSPACE_EXECUTE ExecuteTask
DIS_WORKSPACE_UPDATE UpdateWorkspace
DIS_WORKSPACE_OBJECT_EXECUTE CreateTaskRun
UpdateTaskRun
DIS_WORKSPACE_OBJECT_UPDATE UpdateProject
UpdateFolder
UpdateDataFlow
UpdateTask
UpdateApplication
UpdateDataAsset
UpdateConnection
UpdateReference
UpdateExternalPublication
DIS_WORKSPACE_OBJECT_CREATE CreateProject
CreateFolder
CreateDataFlow
CreateTask
CreateTaskValidation
CreatePatch
CreateApplication
CreateDataAsset
CreateConnection
CreateEntityShape
CreateConnectionValidation
CreateDataFlowValidation
CreateExternalPublication
CreateExternalPublicationValidation
DIS_WORKSPACE_OBJECT_DELETE DeleteProject
DeleteFolder
DeleteDataFlow
DeleteTask
DeleteTaskValidation
DeleteApplication
DeletePatch
DeleteTaskRun
DeleteDataAsset
DeleteConnection
DeleteConnectionValidation
DeleteDataFlowValidation
DeleteExternalPublication
DeleteExternalPublicationValidation

MANAGE

USE +

USE +

DIS_WORKSPACE_CREATE CreateWorkspace
DIS_WORKSPACE_DELETE DeleteWorkspace
DIS_WORKSPACE_MOVE ChangeCompartment
DIS_WORKSPACE_START StartWorkspace
DIS_WORKSPACE_STOP StopWorkspace
Note

Each permission for dis-workspaces fully covers an API. There are no partially covered APIs for dis-workspaces permissions.

Permissions Required for Each API Operation

The following table lists the API operations for Oracle Cloud Infrastructure Data Integration in a logical order, grouped by resource-type.

The resource-types are dis-workspaces and dis-work-requests.

For information about permissions, see Permissions.

This table lists the API operations in a logical order, grouped by resource-type and the permissions required for dis-workspaces and dis-work-requests:

Required Permissions
API Operation Permissions
ListWorkspaces DIS_WORKSPACE_INSPECT
GetWorkspace DIS_WORKSPACE_READ
UpdateWorkspace DIS_WORKSPACE_UPDATE
DeleteWorkspace DIS_WORKSPACE_DELETE
CreateWorkspace DIS_WORKSPACE_CREATE
ChangeCompartment DIS_WORKSPACE_MOVE
StartWorkspace DIS_WORKSPACE_START
StopWorkspace DIS_WORKSPACE_STOP
ListWorkRequests DIS_WORK_REQUEST_INSPECT
GetWorkRequest DIS_WORK_REQUEST_READ
ListWorkRequestErrors DIS_WORK_REQUEST_INSPECT
ListWorkRequestLogs DIS_WORK_REQUEST_INSPECT
GetCountStatistic DIS_WORKSPACE_OBJECT_READ
ListProjects DIS_WORKSPACE_OBJECT_INSPECT
CreateProject DIS_WORKSPACE_OBJECT_CREATE
GetProject DIS_WORKSPACE_OBJECT_READ
UpdateProject DIS_WORKSPACE_OBJECT_UPDATE
DeleteProject DIS_WORKSPACE_OBJECT_DELETE
ListFolders DIS_WORKSPACE_OBJECT_INSPECT
CreateFolder DIS_WORKSPACE_OBJECT_CREATE
GetFolder DIS_WORKSPACE_OBJECT_READ
UpdateFolder DIS_WORKSPACE_OBJECT_UPDATE
DeleteFolder DIS_WORKSPACE_OBJECT_DELETE
ListDataFlows DIS_WORKSPACE_OBJECT_INSPECT
CreateDataFlow DIS_WORKSPACE_OBJECT_CREATE
GetDataFlow DIS_WORKSPACE_OBJECT_READ
UpdateDataFlow DIS_WORKSPACE_OBJECT_UPDATE
DeleteDataFlow DIS_WORKSPACE_OBJECT_DELETE
ListTasks DIS_WORKSPACE_OBJECT_INSPECT
CreateTask DIS_WORKSPACE_OBJECT_CREATE
GetTask DIS_WORKSPACE_OBJECT_READ
UpdateTask DIS_WORKSPACE_OBJECT_UPDATE
DeleteTask DIS_WORKSPACE_OBJECT_DELETE
CreateTaskValidation DIS_WORKSPACE_OBJECT_CREATE
ListTaskValidations DIS_WORKSPACE_OBJECT_INSPECT
GetTaskValidations DIS_WORKSPACE_OBJECT_READ
DeleteTaskValidation DIS_WORKSPACE_OBJECT_DELETE
ListApplications DIS_WORKSPACE_OBJECT_INSPECT
CreateApplication DIS_WORKSPACE_OBJECT_CREATE
GetApplication DIS_WORKSPACE_OBJECT_READ
UpdateApplication DIS_WORKSPACE_OBJECT_UPDATE
DeleteApplication DIS_WORKSPACE_OBJECT_DELETE
ListPatches DIS_WORKSPACE_OBJECT_INSPECT
CreatePatch DIS_WORKSPACE_OBJECT_CREATE
GetPatch DIS_WORKSPACE_OBJECT_READ
DeletePatch DIS_WORKSPACE_OBJECT_DELETE
ListPatchChangesDIS_WORKSPACE_OBJECT_INSPECT
ListPublishedObjects DIS_WORKSPACE_OBJECT_INSPECT
GetPublishedObject DIS_WORKSPACE_OBJECT_READ
ListDependentObjects DIS_WORKSPACE_OBJECT_INSPECT
GetDependenObject DIS_WORKSPACE_OBJECT_READ
ListTaskRuns DIS_WORKSPACE_OBJECT_INSPECT
CreateTaskRun DIS_WORKSPACE_OBJECT_EXECUTE
GetTaskRun DIS_WORKSPACE_OBJECT_READ
UpdateTaskRun DIS_WORKSPACE_OBJECT_UPDATE
DeleteTaskRun DIS_WORKSPACE_OBJECT_DELETE
ListTaskRunLogs DIS_WORKSPACE_OBJECT_INSPECT
CreateDataAsset DIS_WORKSPACE_OBJECT_CREATE
ListDataAssets DIS_WORKSPACE_OBJECT_INSPECT
GetDataAsset DIS_WORKSPACE_OBJECT_READ
UpdateDataAsset DIS_WORKSPACE_OBJECT_UPDATE
DeleteDataAsset DIS_WORKSPACE_OBJECT_DELETE
CreateConnection DIS_WORKSPACE_OBJECT_CREATE
ListConnections DIS_WORKSPACE_OBJECT_INSPECT
GetConnection DIS_WORKSPACE_OBJECT_READ
UpdateConnection DIS_WORKSPACE_OBJECT_UPDATE
DeleteConnection DIS_WORKSPACE_OBJECT_DELETE
GetSchema DIS_WORKSPACE_OBJECT_READ
ListSchemas DIS_WORKSPACE_OBJECT_INSPECT
ListDataEntities DIS_WORKSPACE_OBJECT_INSPECT
CreateEntityShape DIS_WORKSPACE_OBJECT_CREATE
GetDataEntity DIS_WORKSPACE_OBJECT_READ
CreateConnectionValidation DIS_WORKSPACE_OBJECT_CREATE
ListConnectionValidations DIS_WORKSPACE_OBJECT_INSPECT
GetConnectionValidation DIS_WORKSPACE_OBJECT_READ
DeleteConnectionValidation DIS_WORKSPACE_OBJECT_DELETE
CreateDataFlowValidation DIS_WORKSPACE_OBJECT_CREATE
ListDataFlowValidations DIS_WORKSPACE_OBJECT_INSPECT
GetDataFlowValidation DIS_WORKSPACE_OBJECT_READ
DeleteDataFlowValiation DIS_WORKSPACE_OBJECT_DELETE
ListReferencesDIS_WORKSPACE_OBJECT_INSPECT
GetReferenceDIS_WORKSPACE_OBJECT_READ
UpdateReferenceDIS_WORKSPACE_OBJECT_UPDATE
ListExternalPublicationsDIS_WORKSPACE_OBJECT_INSPECT
CreateExternalPublicationDIS_WORKSPACE_OBJECT_CREATE
GetExternalPublicationDIS_WORKSPACE_OBJECT_READ
UpdateExternalPublicationDIS_WORKSPACE_OBJECT_UPDATE
DeleteExternalPublicationDIS_WORKSPACE_OBJECT_DELETE
ListExternalPublicationValidationsDIS_WORKSPACE_OBJECT_INSPECT
CreateExternalPublicationValidationDIS_WORKSPACE_OBJECT_CREATE
GetExternalPublicationValidationDIS_WORKSPACE_OBJECT_READ
DeleteExternalPublicationValidationDIS_WORKSPACE_OBJECT_DELETE

Creating a Policy

To create a policy:

  1. In the Console navigation menu, in the Governance and Administration section, go to Identity and click Policies.
  2. Click Create Policy.
  3. Enter a name and description for the policy.
  4. In Policy Builder, click Customize (Advanced).
  5. Enter a policy rule. For example:
    allow <subject> to <verb> <resource-type> in <location> where <conditions>
    Conditions are optional.
  6. Click Create.

For more information on creating policies, see how policies work, policy syntax and policy reference.

Policy Examples

The syntax for a policy is:

allow <subject> to <verb> <resource-type> in <location> where <condition>

For complete details, see policy syntax. For more information about creating policies, see how policies work, policy reference, and policy details for Object Storage.

Here are some simple policy examples for Data Integration.

Policy Examples to Enable Access to Data Integration

To use Data Integration, you need to create policies.

Enable Access to View Workspaces

To allow a group to simply view the list of all Data Integration workspaces, you can use inspect.

To view workspaces in a specific compartment:

allow group <group-name> to inspect dis-workspaces in compartment <compartment-name>
Enable Access to Get Workspace Details

To allow a group to simply view the list of all Data Integration workspaces, you can use inspect.

The verb, read, for dis-workspaces includes the same permissions and API operations as inspect, plus the permission, DIS_WORKSPACE_READ, and the API operations that it covers.

To allow a group to list and get details for dis-workspaces in a specific compartment, you can use the verb, read:

allow group <group-name> to read dis-workspaces in compartment <compartment-name>

To allow a group to list and get details for dis-workspaces and the objects it contains in the tenancy, you can use:

allow group <group-name> to read dis-workspaces in tenancy
Enable Access to Update Workspaces

To allow a group to update workspaces and the objects they contain, you can use the verb, use.

The verb, use, for dis-workspaces includes the same permissions and API operations as read and inspect, plus the permission, DIS_WORKSPACE_UPDATE, and the API operations that it covers.

To allow a group to update dis-workspaces in a specific compartment, you can use:

allow group <group-name> to use dis-workspaces in compartment <compartment-name>

To allow a group to update dis-workspaces and the objects it contains in the tenancy, you can use:

allow group <group-name> to use dis-workspaces in tenancy

To allow a group to update a specific workspace and not any other workspace:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

To allow a group to update a set of specified workspaces:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')
Note

You can copy your workspace OCID from the Console.
Enable Access to Manage Workspaces

To allow a group to manage workspaces and the objects they contain, you can use the verb, manage.

The verb, manage, for dis-workspaces includes the same permissions and API operations as inspect, read, and useplus the permissions, DIS_WORKSPACE_CREATE and DIS_WORKSPACE_DELETE, and the API operations that it covers.

To allow a group to manage dis-workspaces in a specific compartment, you can use :

allow group <group-name> to manage dis-workspaces in compartment <compartment-name>

To allow a group to manage dis-workspaces and the objects it contains in the tenancy, you can use:

allow group <group-name> to manage dis-workspaces in tenancy

To allow a group to manage a specific workspace and not any other workspace:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

To allow a group to manage a set of specified workspaces:

allow group <group-name> to manage dis-workspaces in compartment <compartment-name> where ANY (target.workspace.id = '<workspace-1-ocid>', target.workspace.id = '<workspace-2-ocid>')
Note

You can copy your workspace OCID from the Console.
Policy Permission and API Examples

Here are some examples using permissions in a condition:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_READ'
allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.permission = 'DIS_WORKSPACE_UPDATE'

Here are some examples to using API operations in a condition:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'GetWorkspace'
allow group <group-name> to use dis-workspace in compartment <compartment-name> where request.operation = 'UpdateWorkspace'
Note

A permission can have more than one API related to it. If you use a permission and not a specific API in a policy, check Permissions Required for Each API Operation to ensure that your policy covers the APIs that you intend.
Policy Conditional Examples
Note

You can copy your workspace OCID from the Console.

Policies with conditional statements have a where clause. For example, to allow a group to update a specific workspace and not any other workspace:

allow group <group-name> to use dis-workspace in compartment <compartment-name> where target.workspace.id = '<workspace-ocid>'

To allow only the group who creates a workspace to use it:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where target.workspace.createdBy = request.user.id

To allow a group to manage all Data Integration resources, except for deleting workspaces:

allow group <group-name> to manage dis-family in compartment <compartment-name> where request.permission! = 'DIS_WORKSPACE_DELETE'

Policy statements that use a key in a where clause allow users in a group to use workspaces in a compartment where the request has that specific key. For example, you can allow a group to operate only in a specific Application.

To restrict a group to only execute tasks in an Application:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.application.key='<application-key>'}

To allow a group to create objects (such as tasks and data flows) only in a folder:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.folder.key='<folder-key>'}

To allow a group to update or delete a specific object such as a data flow:

allow group <group-name> to use dis-workspaces in compartment <compartment-name> where any {target.object.key='<object-key>'}
Policy Examples to Enable Access to Oracle Object Storage

Data Integration needs specific permission to Oracle Object Storage to access metadata, and read and write data.

To create an Object Storage data asset and browse its schemas, you must belong to a user group that has permission to read Object Storage. See On Behalf Of Policy Examples.

To test a the Object Storage connection, ensure that your Data Integration workspace or compartment has, at minimum, READ access to objectstorage-namespaces. See Resource Principal Policy Examples.

To create and execute a data flow using Object Storage as a source or target, your workspace or compartment must have all policies mentioned in Resource Principal Policy Examples.

Note

The WHERE clause content is optional but required to limit the resources that access Oracle Object Storage. You can use it to fine tune access according to your needs. To apply a policy statement to:
  • All workspaces, use WHERE ALL {request.principal.type='disworkspace'}
  • A specific workspace, use WHERE ALL {request.principal.id='<workspace-OCID>'}

    You can copy your workspace OCID from the Console.

  • All workspaces in a specific compartment, use WHERE ALL {request.resource.compartment.id = '<compartment-OCID>'}
Resource Principal Policy

These policies allow a Data Integration workspace or its compartment to validate connections to Oracle Object Storage, and read and write data.

The policies differ slightly when the Data Integration workspace and Object Storage data asset belong to the same tenancy versus when they are in different tenancies.

Within the same tenancy

If your Data Integration workspace and Object Storage data source are in the same tenancy, then you must create the following policies:

allow any-user to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.operation = 'GetBucket'}
allow any-user to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
Within different tenancies

If your Data Integration workspace and Object Storage data source are in different tenancies, then you must create the following policies:

In the workspace tenancy:


Endorse any-user to read buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}

Endorse any-user to manage objects in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}

Endorse any-user to manage buckets in tenancy <tenancy-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}

In the Object Storage tenancy:

Admit any-user of tenancy <tenancy-name> to read buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.operation = 'GetBucket'}

Admit any-user of tenancy <tenancy-name> to manage objects in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>'}

Admit any-user of tenancy <tenancy-name> to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-OCID>', request.permission = 'PAR_MANAGE'}
On Behalf Of Policy Examples

These policies allow the logged-in user to list and browse compartments, Object Storage buckets, and objects based on the permissions already assigned to the user.

The policies differ slightly when the Data Integration workspace and Object Storage data asset belong to the same tenancy versus when they are in different tenancies.

Within the same tenancy

If the Data Integration workspace and Object Storage data asset belong to the same tenancy, then the user (or the group the user belongs to) must have access to Object Storage:

allow group <group-name> to use object-family in compartment <compartment-name>
Within different tenancies

If your Data Integration workspace and Object Storage data asset are in different tenancies, then you must create the following policies:

In the workspace tenancy:

Define tenancy <name> as <object-storage-tenancy-OCID>
Endorse group <group-name> to inspect compartments in tenancy <tenancy-name>
Endorse group <group-name> to use object-family in tenancy <tenancy-name>

In the Object Storage tenancy:

Define tenancy <tenancy-name> as <workspace-tenancy-OCID>
Define group <workspace-tenancy-group-name> as <workspace-tenancy-group-OCID>
Admit group <group-name> of tenancy <tenancy-name> to inspect compartments in tenancy
Admit group <group-name> of tenancy <tenancy-name> to use object-family in compartment <compartment-name>
Policy Examples to Use Autonomous Databases as Targets

When you use Autonomous Data Warehouse or Autonomous Transaction Processing databases as a target database in Data Integration, Oracle Object Storage is used for staging data and completing the operations. To allow pre-authentication for such requests, you need the following policy.

allow any-user to manage buckets in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>', request.permission = 'PAR_MANAGE'}

While working with Autonomous Databases in Data Integration, Object Storage is also used. So, you must create all the required Object Storage policies.

Policy Examples for Publishing to the Data Flow Service

Before you can publish tasks from OCI Data Integration to OCI Data Flow, ensure that you have the following policies.

allow any-user to manage dataflow-application in compartment <compartment-name> where ALL {request.principal.type = 'disworkspace', request.principal.id = '<workspace-ocid>'}
allow group <group-name> to read dataflow-application in compartment <compartment-name>
allow group <group-name> to manage dataflow-run in compartment <compartment-name>