Starting with a brand new Oracle Cloud Infrastructure (OCI) tenancy is an exciting opportunity. You have all the permissions and can do whatever you want. Your team members are interested and you grant them the access you have to it, and within a blink of an eye, chaos is there.
Granting the same permissions to all OCI users, i.e. allowing them to manage all resources of an OCI tenancy, allows them to work on components not managed by them. Imagine a development user who accidently selected the production compartment and deleted the production database in error. Or, the rogue undercover user, who deletes every resource on purpose. Both scenarios are disastrous for any business. To prevent these scenarios (and everything in between) we need to implement the same, already present, restrictions we use in the Enterprise, in OCI, too.
There are great papers that explain how to implement such a structured usage of OCI: For example, the Best Practices for Identity and Access Management (IAM) in Oracle Cloud Infrastructure white paper or the Oracle Cloud Infrastructure Compartments blog by my team mate Andre Correa.
But how to integrate your OCI structure with your Enterprise Identity Provider and assign the enterprise users to the related OCI groups? This article explains the usage of OCI Federation and Role Mapping to achieve this.
For simplification, we reuse the Scenario for Compartment and Policy Design from figure 3 in the white paper. It consists of these components:
The complete scenario structure is shown in Figure 1 below.
Figure 1: The complete scenario structure.
Federating OCI with an existing Enterprise Identity Provider allows us to combine both components easily. The Enterprise Identity Provider holds the Enterprise users with their credentials and roles. Adding OCI to the provider scope allows us to quickly grant OCI access to these users with the related permissions.
In order to make the integration of the Enterprise Identity Provider as easy as possible, some groups should be created in there.
A good practice is to keep the OCI group naming scheme and prefix it with OCI_ (for example):
Depending on their role within the OCI scenario, Enterprise users are assigned to the groups that grant the needed access.
For example, UserA is allowed to administer the DepartmentA compartment and needs to be a member of the OCI_DepartA_Admin group, while UserB who is allowed to administer the DepartmentB compartment needs to be a member of the OCI_DepartB_Admin group. Both groups are clearly separated from each other and members are allowed to manage their compartment, but not to do anything on the other compartments.
The Federation Setup requires a SAML 2.0 compatible Identity Provider. The steps to add the Enterprise Identity Provider to OCI are listed below. If Oracle Identity Cloud Service is preconfigured and fulfills our needs, we can skip this section.
The advantage of Group Mapping is that existing Enterprise User Configuration processes work as already known. You only have to adjust the list of required groups when needed. Once the Group Mapping has been configured in OCI, everything can be used as usual.
There are two ways to configure the Group Mapping in OCI:
When done, we have mappings like these:
To test the setup, we use the Enterprise Access Management to assign some users to the related OCI_* groups.
In this test, you pick an enterprise user that is not assigned to an OCI_* group, say UserNoOCI:
In this test, you pick an enterprise user that is assigned to the OCI_DepartA_Admin group, say UserDepartAAdmin:
In this article we showed how to integrate OCI and its groups with your Enterprise Identity Provider and your group management processes. You can add or remove users from your Enterprise Group and quickly grant or revoke the associated permissions in OCI automatically.