Oracle ERP Cloud Integration Security Roles: Minimum Privilege Design

TL;DR

• Bottom line: Create custom integration roles by copying predefined duty roles and stripping unnecessary privileges rather than assigning broad seeded job roles like Financial Application Administrator to integration users.
• Key limit: Integration users require BOTH function security privileges (what actions) AND data security policies (which data) -- function security alone does not grant data access.
• Watch out for: Seeded roles include far more privileges than integrations need -- the Integration Specialist role includes UI navigation and approval privileges that create SoD violations when assigned to service accounts.
• Best for: Any Oracle Fusion Cloud ERP integration using REST APIs, SOAP web services, FBDI file imports, or BI Publisher report extracts.
• Authentication: OAuth 2.0 (JWT assertion for server-to-server), SAML for SOAP, or basic auth over HTTPS -- all require the integration user to have the correct role assignments in Security Console.

System Profile

Oracle Fusion Cloud ERP uses a layered RBAC (Role-Based Access Control) model where security is enforced through job roles, duty roles, and privileges organized in a strict hierarchy. Integration security applies across all modules -- Financials, Procurement, Supply Chain Management, HCM, and Project Management. This card covers Release 24A through 25D. On-premise Oracle E-Business Suite uses a fundamentally different security model and is not covered here.

API Surfaces & Capabilities

Oracle ERP Cloud exposes multiple integration surfaces, each requiring different security role configurations. The security model applies consistently across all surfaces, but the specific duty roles and privileges differ.

Rate Limits & Quotas

Per-Request Limits

Rolling / Daily Limits

Authentication

Authentication Gotchas

• JWT assertion flow requires registering a confidential application in Oracle Identity Cloud Service (IDCS) or OCI IAM -- the client ID and secret must be managed as secrets, not embedded in integration code. [src1]
• The integration user must be a separate, dedicated user -- never share a human user's credentials for integrations because it breaks audit trails and complicates role certification. [src7]
• Session timeout settings configured by the Oracle Cloud administrator affect all authentication flows -- if sessions are shortened for security, integration tokens may expire mid-batch. [src1]

Constraints

• Integration users must have both function security privileges AND data security policies -- function security alone allows the API call but returns empty results without data security.
• Predefined (seeded) roles cannot be modified -- you must copy them first in Security Console before customizing.
• Duty roles cannot be assigned directly to users -- they must be nested inside job roles or abstract roles.
• Role changes require user re-provisioning -- the integration user must sign out and back in for new role assignments to take effect.
• FBDI imports require ESS (Enterprise Scheduler Service) scheduling privileges in addition to the module-specific import duty roles.
• REST API endpoints each have their own duty role -- a role granting access to GL journals does not automatically grant access to AP invoices.
• Cross-module integration users accumulate privileges that may trigger SoD (Segregation of Duties) violations.

Integration Pattern Decision Tree

START -- Design security roles for Oracle ERP Cloud integration
|-- What integration surface?
|   |-- REST API
|   |   |-- Identify each REST endpoint your integration calls
|   |   |-- Map endpoints to API-specific duty roles (see Quick Reference)
|   |   |-- Create custom job role -> nest required API duty roles
|   |   |-- Assign data security policies for each business unit/ledger
|   |   +-- Authentication: OAuth 2.0 JWT assertion (recommended)
|   |-- SOAP Web Services
|   |   |-- Identify WSDL services required
|   |   |-- Map to service operation privileges
|   |   |-- Create custom job role -> nest service duty roles
|   |   +-- Authentication: SAML assertion
|   |-- FBDI (File-Based Data Import)
|   |   |-- Identify import templates needed
|   |   |-- Assign module-specific import duty roles
|   |   |-- Add ESS scheduling privilege
|   |   |-- Add UCM content access privileges
|   |   +-- Authentication: Basic auth (upload) + ESS job scheduling
|   +-- BI Publisher (BIP) Extracts
|       |-- Identify reports needed
|       |-- Assign BI Consumer or BI Author role
|       +-- Authentication: Basic auth or OAuth
|-- How many modules?
|   |-- Single module -> one custom integration job role
|   |-- Multiple modules -> evaluate SoD risk first
|   |   |-- Option A: one integration user per module (safest)
|   |   +-- Option B: one integration user, multi-module role (faster, riskier)
+-- What data scope?
    |-- Single business unit -> restrict data role to that BU
    |-- Multiple business units -> create data role per BU
    +-- All business units -> use "Grant on all values" (audit carefully)

Quick Reference

Key Predefined Integration Roles by Module

Duty Roles Commonly Needed for REST API Access

Step-by-Step Integration Guide

1. Create a Dedicated Integration User

Create a separate user account exclusively for the integration. Never reuse a human user account. [src7]

Navigation: Setup and Maintenance > Manage Users
1. Click "Add User" or use SCIM REST API
2. Set User Name: INT_<SYSTEM>_<MODULE> (e.g., INT_OIC_FINANCIALS)
3. Set a strong password (if using basic auth) or leave password-less for OAuth-only
4. Do NOT assign any seeded job roles at this stage

Verify: Navigate to Security Console > Users > search for the new user -> user should exist with zero roles assigned.

2. Design a Custom Integration Job Role

Create a minimal custom job role that nests only the required duty roles. [src2, src4]

Navigation: Tools > Security Console > Roles > Create Role
1. Role Name: Custom <Module> Integration Role
2. Role Code: CUSTOM_INT_GL (your naming convention)
3. Role Category: Common
4. Click "Duty Roles" tab > Add Duty Role
5. Search and add ONLY the duty roles your integration needs
6. Click "Function Security Policies" tab
7. Verify only necessary privileges are inherited
8. REMOVE any unnecessary privileges (UI navigation, approvals)

Verify: Security Console > Roles > search your custom role > "Privilege" tab -> verify no unnecessary privileges exist.

3. Configure Data Security Policies

Data security defines WHICH data the integration can access. Without this, the integration user calls APIs but gets empty results. [src1, src6]

Navigation: Security Console > Roles > [Your Custom Role] > Data Security Policies
1. Click "Create Data Security Policy"
2. Database Resource: select the business object (e.g., "Ledger", "Business Unit")
3. Dataset: select the condition
   - "Select by instance set" -> specific ledger(s) or BU(s)
   - "Grant on all values" -> all records (use sparingly)
4. Actions: select only needed actions (Read, Manage)
5. Repeat for each business object the integration touches

Verify: Sign in as the integration user -> call the REST API -> confirm response contains only expected records.

4. Assign the Custom Role to the Integration User

Assign only the custom role -- no seeded job roles. [src2]

Navigation: Security Console > Users > [Integration User] > Roles > Add Role
1. Search for your custom role (e.g., "Custom GL Integration Role")
2. Click "Add Role Membership"
3. Set Provisioning Status to "Provisioned"
4. Click Save

Verify: Security Console > Users > [Integration User] > "Roles and Role Memberships" tab -> confirm only your custom integration role appears.

5. Configure FBDI-Specific Privileges (If Using File Import)

FBDI requires additional privileges beyond module-level duty roles. [src3]

Add these duty roles to your custom integration job role:
1. "Manage File Import and Export" (for UCM file staging)
2. "Run <Module> Scheduled Processes" (for ESS job submission)
3. "Import <Object>" privilege specific to your import template
Add UCM content security for relevant content folders.

Verify: Sign in as the integration user -> navigate to Scheduled Processes -> confirm only relevant import jobs are visible.

6. Validate and Test the Configuration

Test all API endpoints the integration will use with the actual integration user credentials. [src7]

# Test REST API access with the integration user
curl -X GET \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/journals" \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json"
# Expected: 200 OK with journal data for assigned ledgers only
# 403 = missing function security; 200 with empty items[] = missing data security

Verify: Response contains data ONLY for the assigned ledgers/business units.

Code Examples

Python: Audit Integration User Privileges via REST API

# Input:  Oracle ERP Cloud instance URL, OAuth access token
# Output: List of all roles and privileges assigned to integration user

import requests

base_url = "https://<instance>.fa.ocs.oraclecloud.com"
token = "<oauth_access_token>"
username = "INT_OIC_FINANCIALS"

headers = {
    "Authorization": f"Bearer {token}",
    "Content-Type": "application/json"
}

resp = requests.get(
    f"{base_url}/hcmRestApi/resources/latest/userAccounts",
    params={"q": f"Username={username}", "expand": "roles"},
    headers=headers
)

if resp.status_code == 200:
    user_data = resp.json()
    for item in user_data.get("items", []):
        print(f"User: {item.get('Username')}")
        for role in item.get("roles", []):
            print(f"  Role: {role.get('RoleName')} ({role.get('RoleCode')})")
else:
    print(f"Error: {resp.status_code} - {resp.text}")

cURL: Test Integration User REST API Access Per Module

# Input:  Instance URL, integration username, password
# Output: HTTP status codes per module endpoint

# Test GL access
curl -s -o /dev/null -w "%{http_code}" \
  -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/journals?limit=1"

# Test AP access
curl -s -o /dev/null -w "%{http_code}" \
  -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/invoices?limit=1"

# Verify data scope: count accessible ledgers
curl -s -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/ledgers" \
  | python -c "import sys,json; d=json.load(sys.stdin); print(f'Accessible ledgers: {d.get(\"count\",0)}')"

Data Mapping

Security Object Hierarchy

Data Type Gotchas

• Function security privileges are cumulative (additive) -- there is no "deny" privilege. To restrict access, do not include the privilege in the role. [src1]
• Data security policies use conditions referencing "set" columns (SetId, BusinessUnitId, LedgerId). If using reference data sets, the integration user needs access to both the transaction BU and the reference data set. [src6]
• Role inheritance is unlimited depth. When auditing privileges, trace the full inheritance chain using Security Console > "Privilege" tab > "Inherited Roles" view. [src5]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Silent data filtering: REST APIs return 200 OK with empty results when data security is missing. Fix: Always validate record counts against a known baseline after role changes. [src1]
• Role provisioning delay: After assigning a new role, the user must log out and back in before privileges take effect. Fix: Run the "User and Roles Synchronization" ESS job to force re-provisioning. [src2]
• Quarterly update privilege changes: Oracle updates can rename or deprecate duty roles and privileges. Fix: After every quarterly update, run a privilege comparison report using Security Console "Compare Roles" feature. [src4]
• FBDI "Insufficient Privileges" error: Integration user has module duty roles but is missing the ESS scheduling privilege. Fix: Add "Run <Module> Scheduled Processes" duty role to the integration job role. [src3]
• Cross-module SoD violations: Integration user touching both AP and GL may trigger SoD alerts. Fix: Use separate integration users per module or document the exception with compensating controls. [src7]

Anti-Patterns

Wrong: Assigning Seeded Job Roles Directly to Integration Users

# WRONG -- assigning broad seeded roles
Security Console > Users > INT_OIC_ALL > Add Role
  Role: "General Accountant"        # 200+ privileges, includes approvals
  Role: "Accounts Payable Manager"  # includes payment approvals and UI nav
  Role: "Procurement Manager"       # includes sourcing and negotiation

Correct: Creating Minimal Custom Integration Roles

# CORRECT -- custom role with only needed duty roles
Security Console > Roles > Create Role
  Role Name: "Custom Financials Integration Role"
  Duty Roles:
    - "General Accounting Duty"        # journal operations only
    - "Accounts Payable Invoice Duty"  # invoice CRUD only, no approvals
    - "Run Financials Scheduled Processes"  # ESS for FBDI
  Data Security:
    - Ledger: "US Primary Ledger" only
    - Business Unit: "US Business Unit" only

Wrong: Using "Grant on All Values" for Data Security

# WRONG -- granting access to ALL business units/ledgers
Data Security Policy:
  Database Resource: Business Unit
  Condition: "Grant on all values"  # sees ALL BUs globally

Correct: Restricting Data Security to Specific Business Units

# CORRECT -- granting access only to required business units
Data Security Policy:
  Database Resource: Business Unit
  Condition: "Select by instance set"
  Business Units: ["US Business Unit", "UK Business Unit"]

Wrong: Sharing a Human User Account for Integrations

# WRONG -- using a named user for integration
Integration Connection:
  Username: "john.smith"     # human user
  # breaks audit trail, SoD conflict, breaks when John leaves

Correct: Using Dedicated Integration Service Accounts

# CORRECT -- dedicated service account
Integration Connection:
  Username: "INT_OIC_GL"           # dedicated, non-human user
  Auth: OAuth 2.0 JWT assertion    # no password to rotate
  Roles: "Custom GL Integration Role" only

Common Pitfalls

• Copying too much from seeded roles: Copied roles inherit ALL duty roles from the seeded role. Fix: Start with an empty custom role and ADD only the duty roles you need. [src4]
• Forgetting data security for REST APIs: Function security controls which endpoints the user can call; data security controls which records are returned. Fix: For every duty role added, identify the corresponding data security policy and add both. [src1]
• Testing with admin credentials: Developers test with their own admin accounts, then integration fails in production with the minimal integration user. Fix: Always test API calls using the actual integration user credentials before go-live. [src7]
• Ignoring quarterly update impact: Quarterly updates can introduce new privileges or restructure duty role inheritance. Fix: Re-validate integration user access after every quarterly update. [src4]
• Over-provisioning to "make it work": Adding broader roles when an integration fails creates security liability and SoD violations. Fix: Use Security Console "Analyze Roles" to identify the specific missing privilege. [src2]
• Not managing multiple environments: Role definitions do not auto-migrate between environments. Fix: Export role definitions using the "Security Setup Data" implementation project task. [src1]

Diagnostic Commands

# List all roles assigned to integration user
curl -s -u "admin_user:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/hcmRestApi/resources/latest/userAccounts?q=Username=INT_OIC_FINANCIALS&expand=roles" \
  | python -m json.tool

# Test function security: attempt GL journal query
curl -s -w "\nHTTP Status: %{http_code}\n" \
  -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/journals?limit=1"

# Test data security: count accessible ledgers
curl -s -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/ledgers" \
  | python -c "import sys,json; d=json.load(sys.stdin); print(f'Accessible ledgers: {d.get(\"count\",0)}')"

# Check ESS scheduling privilege (for FBDI)
curl -s -w "\nHTTP Status: %{http_code}\n" \
  -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/erpintegrations"

# Verify data scope: list accessible business units
curl -s -u "INT_OIC_FINANCIALS:<password>" \
  "https://<instance>.fa.ocs.oraclecloud.com/fscmRestApi/resources/latest/businessUnits" \
  | python -c "import sys,json; d=json.load(sys.stdin); [print(i['BusinessUnitName']) for i in d.get('items',[])]"

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• Quarterly updates are mandatory in Oracle Cloud ERP -- you cannot defer them. Every update can modify duty roles, privileges, or data security enforcement. Integration roles must be re-validated after each update.
• This card covers Oracle Fusion Cloud ERP only. Oracle E-Business Suite (EBS), PeopleSoft, and JD Edwards use fundamentally different security models.
• Data security policies use database-level SQL conditions. Complex conditions require careful testing to avoid performance degradation.
• Oracle provides over 3,000 predefined duty roles and 12,000+ function security privileges. Role codes referenced here are current as of Release 25D but may change in future releases.
• SoD analysis is not covered in this card but is critical for integration users spanning multiple modules. Use Oracle Risk Management Cloud or third-party tools for SoD analysis.