Oracle Integration Cloud (OIC) Fundamentals: Service Roles

Note – It’s been a hot minute since I’ve posted on my OIC Fundamentals series.

Whilst on the box, using Oracle Integration Cloud appears very simple – it’s just drag & drop right?! - It’s important to understand the basics (and understand them well) to ensure that your design and implementation is robust. In this blog series, I am writing articles about key functionality and/or concepts within the product that are critical to the successful of your OCI Integration implementation.

In this post, we will look at OIC Service Roles – what it is and how it should be used.

If you have not yet seen other posts in this series, check them out here:


What is a Service Role?

Once an OIC instance has been provisioned, in order for anyone to access that environment, identity and access management users will need to be added to that OCI tenancy’s identity domain by an OCI security administrator. Once that’s done, users will need to be assigned to one or more of these seven service roles depending on what tasks that they will need to do. Most will need to have some level of access to the OIC service console as well as the OIC REST APIs, but also perhaps the permission to invoke integration instances at runtime that are exposed with SOAP or REST APIs. Oracle integration provides predefined roles to govern access to various Oracle integration features.

Which Predefined Service Roles are available?

The table below outlines the predefined roles that are available in oracle integration and a general description of the tasks that the users assigned with these roles can perform. It is possible to assign more than 1 role to a user or a group.

RoleDescription
ServiceViewerA user with this role can navigate to all integration resource pages, for example: integrations, connections, lookups and libraries, but only can view those details. They’ll have limited access to read-only APIs. Essentially, the console and REST API permissions go hand-in-hand. This user cannot navigate to the administrative setting pages in the console, nor invoke any administrative APIs. In addition, their credentials cannot invoke any integrations at runtime
ServiceInvokerA user with this role cannot access the OIC console at all, nor can they invoke any of the documented Oracle integration REST APIs. Instead, their credentials provide the permission to invoke any integration flow that is exposed through SOAP or REST APIs or to trigger a scheduled integration run.
ServiceUserA user with this role has similar access to a user with the ServiceViewer role. In that, they have view-only access to the OIC console and REST APIs. The difference is that they can also run integrations. So, in effect, the ServiceUser Role combines the privileges of both the ServiceViewer and the ServiceInvoker.
ServiceMonitorA user with this role cannot access or view any design time information. However, they can monitor everything provisioned in an OIC instance from a runtime perspective. For example, they can view instances and metrics, find out response times and track whether instance creation completed successfully or failed. Essentially, they can access all of the observability information available in the monitoring dashboard or via the related REST APIs. They are not permitted to invoke any integrations. The purpose of this role is for users with limited knowledge of OIC integration, design and implementation but have a high level of knowledge of monitoring it. This use roles does not grant permissions to change anything.
ServiceDeveloperA user with this role can create, delete, edit and develop any of the resources associated with creating, activating, monitoring and troubleshooting integrations. Since this user will need to be able to test, these credentials can also be used for runtime access to invoke integrations as well. However, a user with this role cannot navigate to the administrative settings pages in the console, nor invoke any administrative APIs.
ServiceAdministratorA user with this role is essentially a superuser who can not only manager and administer everything using the OIC Service Console or REST APIs, but they also can develop and test integrations themselves since they have full developer access as well.

Do you not just have some easy to consume roles matrices?

Of course! your wish is my command!

Integrations

ActionService
Administrator
Service
Developer
Service
Monitor
Service
User
Service
Invoker
Service
Viewer
Create
Create new version
View
Edit
Delete
Activate
Reactivate
Deactivate
Clone
Run
Export
Import
Update Property Values
Configure
Assign Business Identifiers
Unlock
Add Schedule
Edit Schedule
Delete Schedule
Run Schedule
View Schedule Runs
Update Schedule Parameters

Connections

ActionService
Administrator
Service
Developer
Service
Monitor
Service
User
Service
Invoker
Service
Viewer
Create
Edit
Delete
View
Test
Clone
Unlock
Refresh Metadata

Lookups

ActionService
Administrator
Service
Developer
Service
Monitor
Service
User
Service
Invoker
Service
Viewer
Create
View
Edit
Clone
Delete
Export to CSV
Import

Packages

ActionService AdministratorService DeveloperService MonitorService UserService InvokerService Viewer
View
Create
Import
Export
Update
Delete
Configure

Agents

ActionService AdministratorService DeveloperService MonitorService UserService InvokerService Viewer
View
Edit Agent Group
Delete Agent Group
Create Agent Group
Download Connectivity Agent

Adapters

ActionService AdministratorService DeveloperService MonitorService UserService InvokerService Viewer
View
Delete
Create Connection

Libraries

ActionService AdministratorService DeveloperService MonitorService UserService InvokerService Viewer
View
Edit
Create
Import
Delete
Update
Export

Leave a comment