Control Who Can Edit, View, and Monitor in a Project

Capabilities

RBAC-enabled projects provide the following capabilities:

Support project isolation
Project isolation enables multiple users and groups to work in the same Oracle Integration instance, with access to only the projects to which they are assigned. This enables multiple groups (for example, ERP and HCM) to work on the same Oracle Integration instance and only edit, view, and monitor project resources assigned to their group.

Support for setting restriction levels within a project

You can assign users and groups to specific project permissions based on their needs. For example, you assign project editor permissions to some users and groups to create and edit projects and invoke integrations, while you assign project monitor permissions to other users and groups to only monitor integration instances at runtime.

Project permissions are similar to the Oracle Integration service roles (for example, ServiceDeveloper, ServiceMonitor, ServiceInvoker, and others) that the user with the ServiceAdministrator role first assigns to other users and groups from the Oracle Cloud Infrastructure Console in an Oracle Identity Cloud Service or identity domain environment. See Manage Access and Assign Roles in Provisioning and Administering Oracle Integration 3.

Project permissions are essentially a layer of permissions on top of service roles.

Once you assign these service roles to users and groups, the user with the ServiceAdministrator role or the project owner can assign these users and groups with project permissions inside a specific project. Project access is restricted based on a user's service role, plus their project permissions.

The following project permissions are available:

Project Permission	Description
Owner	Enables you to perform all available actions on the project (as a project-level super user), including associating groups/users with each project permission. The project creator (owner) is automatically set as a project-level super user. Modification of project permissions is restricted to the user with the ServiceAdministrator role (system super user) and the project owner (project-level super user). Only a user with the ServiceAdministrator role or a ServiceDeveloper who is an owner/editor of a project can export the project to another Oracle Integration instance.
Editor	Enables you to edit certain metadata in a project, create projects, and create, remove, edit, and run project resources. You can view runtime metrics and perform actions against runtime instances. You cannot modify the assigned project permissions.
Viewer	Enables you to view certain metadata in a project and discover and view project resources. You cannot add, remove, edit, run, export, or import a project or project resources.
Monitor	Enables you to monitor runtime metrics in a project and perform actions (for example, abort, retry, and discard) against runtime instances. You cannot access the Design and Deploy tabs of a project.
None	A user without any project permissions (owner, editor, viewer, monitor) can see the project name when viewing the main Projects page. However, the user cannot do the following: Access the project details page to retrieve any details or query details with a REST API. View instance monitoring details (for example, integration statistics, instances, errors, and more) outside the project under the Observability tab.

Support RBAC for projects created prior to version 23.06
After version 23.06 patching, projects created in versions 23.04 and earlier automatically include the Share panel inside the project. These earlier projects automatically inherit the Everyone project permission. This setting makes everyone with the correct service role an owner who can edit, view, and monitor project resources. You can then restrict access if necessary by assigning users and groups to each project permission. If you are happy with your pre-23.06 permissions, you can also leave things as they are. Assigning specific project permissions is not required.
Enforce the rule that a user's assigned service roles (ServiceDeveloper, ServiceMonitor, ServiceInvoker, and others) always takes precedence over their assigned project permissions. For example:
- Assume a user with the ServiceMonitor service role is assigned the editor project permission in the Can edit field.
  
  However, because this user is only assigned the ServiceMonitor service role, their permissions in the project are not elevated to allow them to create, update, or delete project resources; they can only monitor the project.
Support projects on a single Oracle Integration instance that are both unrestricted and restricted for use by one or more groups.
When you create a project, import a project, or convert a package to a project, you can select the Anyone can edit, view, and monitor check box if you want to make a project unrestricted to all users with the correct service roles. See Create or Import a Project and Convert a Package to a Project.
Allow users with the ServiceAdministrator role to perform all actions in a project, regardless of project permissions.
Filter the ability to call REST APIs.
For example, a user in an ERP group who invokes the /ic/api/integration/v1/monitoring/instances API only returns flow instance data from integrations attached to their group.
Support having zero or more project owners.
If zero, then project owner defaults to the user with the ServiceAdministrator role. Only administrators have the unique privilege to update project-level access control. Project owners are essentially project-level super users.

RBAC-Enabled Projects FAQ

Can you import a standalone integration into an RBAC-enabled project?
Only a user with the ServiceAdministrator role or a user with the ServiceDeveloper role that has the owner or editor project permission can import a standalone integration into an RBAC-enabled project.
Are project permissions moved from development to test to production environments in a CICD pipeline?
Project permissions are not moved to test and production. The users and groups have different permissions in different environments. However, if a user sets up permissions in production, they are carried forward for future project updates. When a project is imported for the first time, it is owned by whoever imported it. That user must set the project permissions. If a project is re-imported, the permissions are left alone.
Do standalone (non-project) integrations use RBAC?
Integrations created outside of a project do not support RBAC. Non-project or global resources are restricted by existing service roles.
Are there limits on the number of users and groups you can assign to a project?
You can assign a maximum of five users and/or groups (any combination) to each of the project roles.
Do I need to use RBAC with my projects
No, using RBAC is optional. If you do not want to use it, you can ignore Share in the project.
Can members of a project see the other members and their project permissions?
Only a user with the ServiceAdministrator role or a ServiceDeveloper who is the project owner can see other assigned members. For these two conditions only, Share is editable.
Do project permissions take precedence over service roles?
No. Service roles (ServiceDeveloper, ServiceMonitor, ServiceInvoker, and others) always takes precedent over the assigned project permissions. For example, if a user with the ServiceMonitor service role is assigned the editor project permission, they cannot access the Design and Deploy tabs of a project.
Can restrictions be enforced at the REST API level? For example, can lookup update/delete only be assigned to a specific user and restricted from another?
No. If both users have editor permissions on one type of resource, they have permissions on all types of resources.
If you have the editor permission in project A and want to invoke a child integration (set as publicly available) in project B, but you only have the monitor permission (or perhaps, no permission) in project B, can you do so? Or do you need to update your permissions in project B to match those in project A?
You can discover and invoke the child integration in project B without setting any additional project permissions.
Any special permissions for project deployment? Can only a user with the edit permission create a deployment?
To create a project deployment, you must have the ServiceAdministrator role or the ServiceDeveloper role plus the project owner/editor permission.
Can a user create groups and assign permission to groups rather than assigning users?
Yes, the entries can be Oracle Identity Cloud Service or identity domain users or groups.
Can a user with the ServiceMonitor service role see all integrations?
From monitoring pages under Observability, the user with the ServiceMonitor service role cannot see all the integrations. They cannot see integrations that are part of a project on which they do not have any permissions. The same applies to integration instances.
Are project roles applied in a production system?
Project roles are still applicable. For example, the HCM_monitor group can monitor HCM projects, but not the finance project.
What can a user with no project permissions do?
They can see the existence of the project on the main Projects page, but cannot perform any actions and are not allowed to access the project details page. They also cannot see monitoring resources (for example, integration statistics, instances, errors, and others) for the project under the Observability tab.

Select Who Can Edit, View, and Monitor a Project

The user with the ServiceAdministrator role or the project owner can select the users and groups who can view, edit, and monitor the page.

In the navigation pane, click Projects.
Click the project name or click .
In the upper right corner, click Share .
The Share panel is displayed.

Assign users and groups to the project permissions, and click Share

.

Note:

You must have already created users and groups to which you assigned those users before they are visible for selection in this dialog. See Manage Access and Assign Roles in Provisioning and Administering Oracle Integration 3.

Field	Description
Owners	Begin typing to search for users and groups to own the project. By default, the user who created the project is an owner. The user with the ServiceAdministrator service role is also automatically an owner. The owner can perform all available actions, including associating users and groups with each of the project permissions.
Can edit	Begin typing to search for users and groups to which to assign the editor permission. If you select a user or group that includes users that do not have the ServiceDeveloper role, those users are unable to edit the project.
Can view	Begin typing to search for users and groups to which to assign the viewer permission.
Can monitor	Begin typing to search for users and groups to which to assign the monitor permission.

Best Practices

Provide project access only to users that need it.
Give users the minimal permissions necessary to perform their responsibilities. For example, if a user only needs to monitor integrations, don't give them the permission to edit integrations.
Give projects nonsensitive names. For example, don't specify names such as employeeSalaries, employeeRatings, and so on. Even if users don't have access to projects, they can still see the project names listed on the Projects page.

RBAC-Enabled Project Use Case

This use cases provides a high level example of creating an RBAC-enabled project. It demonstrates what users can and cannot do based on their assigned project permissions.

Neeharika, the user with the ServiceAdministrator role, performs the following tasks:

Creates the following user and service role assignments in the Oracle Cloud Infrastructure Console:
- Vijaya: ServiceDeveloper
- Bipin: ServiceDeveloper
- Sumit: ServiceDeveloper
Goes to the Projects page, and clicks Add.
Creates two new projects:
- HCM Project12
- FinancialServiceLocalInvoke
Opens HCM Project12.
In the upper right corner, clicks Share .

Assigns the following users to each project permission. By default, Neeharika is the owner because she created the HCM Project12 project.

The Share panel shows fields for Owners (Neerharika is entered, Can edit (vijaya is entered), Can view (Bipin is entered), and Can monitor (Sumit is entered).

This configuration creates the following similarities between the service roles and the project permissions:

User	Service Role	Project Permission
Vijaya	ServiceDeveloper	Editor
Bipin	ServiceDeveloper	Viewer
Sumit	ServiceDeveloper	Monitor

Does not make any project permission updates under Share of the FinancialServiceLocalInvoke project.
Because Neeharika created this project, she is listed as the owner. The Can edit (for the editor permission), Can view (for the viewer permission), and Can monitor (for the monitor permission) fields remain empty.

With project permission assignments complete, Vijaya (editor permission), Bipin (viewer permission), and Sumit (monitor permission) log in and see their capabilities and restrictions.

What the Vijaya (ServiceDeveloper with the editor project permission) can do:
1. Opens the HCM Project12 project and goes to Share . Because Vijaya has editor permissions, she can edit, view, and monitor resources in the project.
2. Clicks Actions in the Integrations section and notes that all edit actions are listed and can be performed.
3. Moves around the project and successfully performs assorted editor tasks without any restrictions, such as the following:
  - Adds new project keywords in the Details section.
  - Imports a schedule integration and updates the schedule.
  - Deletes a library.
4. Exits the HCM Project12 project.
5. Attempts to open the FinancialServiceLocalInvoke project. This is the project described in Step h to which no project permissions were assigned.
  Because Vijaya is not assigned any permissions on this project, the following error is displayed:
```
User Vijaya does not have sufficient privilege to perform this action.
```
What Bipin (ServiceDeveloper with the viewer project permission) can do:
1. Opens the HCM Project12 project and, clicks Share . Because Bipin has viewer permissions, he can only view resources in the project.
2. Clicks Actions in the Integrations section and notes that no edit actions are listed; only the View and Schedule (for viewing the schedule) actions can be performed.
3. Clicks the Deploy tab.
4. Clicks Actions and notes that no edit actions are listed; only the View action can be performed.
5. Clicks the Observe tab.
6. Clicks Actions and notes that no edit actions such as abort or retry are listed; only the Schedule (to view a schedule) and View child instances actions can be performed.
What Sumit (ServiceDeveloper with the monitor project permission) can do:
1. Opens the HCM Project12 project. Because Sumit has monitor permissions in the project, only the Observe tab is accessible. The Design and Deploy tabs are both disabled.
2. Clicks Observe.
3. Clicks View details to view the activity stream.
4. Click Actions and notes that Retry, Abort, Schedule, and View child instances can all be performed.
5. Clicks the Future runs and Audit tabs to view future scheduled runs and audit details, respectively.
6. In the navigation pane, clicks Observability, then Dashboards for a global view of aggregated data for all integrations in the instance (whether or not they are in a project). All integrations are visible to Sumit regardless of his project permissions.
7. In the navigation pane, clicks the Integrations tab to view all integration instances except for instances in projects in which Sumit does not have project permissions.
  For example, if Sumit clicks Filter , selects a project on which he does not have any permissions, and clicks Apply, the following error is displayed:
```
User Sumit does not have sufficient privilege to perform this action.
```
8. Clicks Actions to view the instance statistics for an integration instance that is part of the HCM Project12 project.
9. Selects the Edit schedule option, but receives the following error:
```
User Sumit does not have sufficient privilege to perform this action.
```
  The restriction occurs because Sumit's monitor permissions do not support this task.
10. In the navigation pane, clicks the Instances tab to view all tracking instances except for instances in projects in which Sumit does not have project permissions.
11. Performs monitoring tasks successfully:
  - Views the activity stream.
  - Aborts and retries instances.
12. In the navigation pane, clicks the Errors tab to view all instances in error except for instances in projects in which Sumit does not have project permissions.
13. Performs monitoring tasks successfully:
  - Views the activity stream.
  - Aborts and retries instances.