OIC Gen3 - Understanding of OIC Service roles

In Oracle Cloud Infrastructure (OCI) Gen 3, service roles are specialized permissions that allow users to perform specific operations within the Oracle Integration Cloud (OIC) service. These roles help manage user access at a granular level, ensuring only authorized users can perform certain tasks within OIC. Here’s an overview of the key service roles:

1. Service Administrator

• This role grants full access to the OIC service.
• Users with this role can configure, monitor, and manage integrations, processes, and visual applications.
• They have permissions to access and modify all aspects of the OIC environment, including integration flows, settings, connections, and monitoring tools.
• Ideal for IT administrators or DevOps personnel responsible for end-to-end management of the integration platform.

2. Service Developer

• Designed for users who need to create and manage integrations, process flows, and visual applications.
• Developers can create connections, build integrations, set up orchestrations, and configure REST/SOAP services.
• However, they typically lack permissions for high-level administrative tasks that alter the environment or user access.

3. Service Monitor

• This role is focused on monitoring and viewing capabilities.
• Service Monitors can track the status of integrations, view performance metrics, and analyze logs.
• They cannot make changes to the configurations or deploy new integrations.
• Ideal for support staff or business analysts who need insights into integration performance without administrative rights.

4. Service User(service viewer + service invoker)

• This is the most limited role, often given to end-users who interact with OIC applications or APIs.
• Users with this role may only access integrations that are exposed to them but do not have permissions to modify or configure services.
• Useful for business users or consumers of APIs who need to access OIC features without any administrative control.

5. Service Viewer (OCI Role)

• The Service Viewer role in OCI generally grants view-only access to the resources and configuration of a service.
• In OIC, this type of role would allow users to view configurations, integrations, and monitoring dashboards without the ability to create, edit, or execute integrations.
• However, OIC itself does not explicitly use a “Service Viewer” role; instead, the Service Monitor role serves a similar purpose for monitoring within OIC.
• For broader access at the OCI platform level, Service Viewer can be useful for administrators who need a read-only view into multiple OCI services, including OIC.

6. Service Invoker (OCI Role)

• The Service Invoker role allows users or services to invoke actions within a service, typically through API calls.
• In OIC, this type of role could correspond to allowing a user or a process to invoke integrations or access APIs exposed by OIC.
• Though OIC does not have a dedicated Service Invoker role, permissions for invoking integrations or APIs are often managed through the Service User role or specific policies granting invoke access.
• At the OCI level, Service Invoker can be applied to service principals (e.g., functions, other cloud services) to allow automated interactions with OIC.

Configuring OCI Roles for OIC Access

To grant Service Viewer or Service Invoker-like access to OIC in an OCI tenancy, you can create IAM policies in OCI that assign these roles to specific users or groups.

For example, you could write policies like:

Allow group Viewers to read integration-instances in compartment <compartment_name>

Allow group Invokers to use integration-instances in compartment <compartment_name>