
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:
- Creating an Oracle Integration 3 Instance in Oracle Cloud
- OCI Integration Fundamentals: Versioning
- OCI Integration Fundamentals: Global Fault Handler
- OCI Integration Fundamentals: Scope Fault Handler
- More to follow (I will update this post with all relevant posts once they are created)
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.
| Role | Description |
|---|---|
| ServiceViewer | A 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 |
| ServiceInvoker | A 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. |
| ServiceUser | A 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. |
| ServiceMonitor | A 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. |
| ServiceDeveloper | A 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. |
| ServiceAdministrator | A 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
| Action | Service 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
| Action | Service Administrator | Service Developer | Service Monitor | Service User | Service Invoker | Service Viewer |
|---|---|---|---|---|---|---|
| Create | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Edit | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Delete | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| View | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Test | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Clone | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Unlock | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Refresh Metadata | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Lookups
| Action | Service Administrator | Service Developer | Service Monitor | Service User | Service Invoker | Service Viewer |
|---|---|---|---|---|---|---|
| Create | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| View | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Edit | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Clone | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Delete | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Export to CSV | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Import | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Packages
| Action | Service Administrator | Service Developer | Service Monitor | Service User | Service Invoker | Service Viewer |
|---|---|---|---|---|---|---|
| View | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Create | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Import | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Export | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
| Update | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Delete | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Configure | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Agents
| Action | Service Administrator | Service Developer | Service Monitor | Service User | Service Invoker | Service Viewer |
|---|---|---|---|---|---|---|
| View | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Edit Agent Group | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Delete Agent Group | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Create Agent Group | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Download Connectivity Agent | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Adapters
| Action | Service Administrator | Service Developer | Service Monitor | Service User | Service Invoker | Service Viewer |
|---|---|---|---|---|---|---|
| View | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
| Delete | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Create Connection | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Libraries
| Action | Service Administrator | Service Developer | Service Monitor | Service User | Service Invoker | Service Viewer |
|---|---|---|---|---|---|---|
| View | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |
| Edit | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Create | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Import | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Delete | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Update | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Export | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ |