Streamline Enterprise Access Management and Oracle Cloud Infrastructure Access Management with Federated Group Mapping

Introduction

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.

OCI Environment Design Scenario

For simplification, we reuse the Scenario for Compartment and Policy Design from figure 3 in the white paper. It consists of these components:

• Tenancy ACME – ACME has three departments named DepartA, DepartB, DepartC.
• Compartments – For each ACME department, we have CompartmentA, CompartmentB, CompartmentC, respectively.
• Groups – For each compartment, we have a number of groups, like DepartA_Admin, DepartB_Admin, DepartC_Admin. Additional groups for network, storage, security administration, and the tenancy administrator group (Network_Admin, Storage_Admin, Security_Admin, Administrators).
• Policies – Related policies that define the required permissions are created and assigned to the groups.
• Users – The users are already present in your Enterprise Identity Provider and need to be assigned to related groups in there.

The complete scenario structure is shown in Figure 1 below.

Figure 1: The complete scenario structure.

Federation

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.

Enterprise Identity Provider Preparation

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):

• OCI_Administrators
• OCI_Network_Admin
• OCI_Storage_Admin
• OCI_Security_Admin
• OCI_DepartA_Admin
• OCI_DepartB_Admin
• OCI_DepartC_Admin

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.

Federation Setup

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.

1. Open the OCI Console
2. From the menu in the upper left select Identity > Federation.
3. To get the OCI Service Provider metadata, find the link Download the document at the bottom of the Federation table. Follow that link and download the XML metadata file.
4. Configure your Enterprise Identity Provider as needed.
5. In the Federation table click on the Add Federation Provider button.
6. In the Add Provider window enter the following information
   • Name – A name that identifies the provider. Use a name that easily tells its purpose, because you'll find it on the OCI login window later.
   • Description – Anything that helps you to remember what and why you did this.
   • Type – If you don't use IDCS for it, select Microsoft Active Directory Federation Service (ADFS) or SAML 2.0 Compliant Identity Provider.
   • XML – Click on the Browse button to upload your IDP metadata XML file.
   • Click on Continue to go to the Group Mapping (continued in the next section).

Group Mapping

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:

1. While setting up the federation: For each mapping provide the Identity Provider Group Name and the related OCI group name.
2. Or, for an existing Identity Provider configuration, select Group Mappings from the Resources list, click on the Edit Mapping button and add the new mapping.

When done, we have mappings like these:

Testing the Setup

To test the setup, we use the Enterprise Access Management to assign some users to the related OCI_* groups.

Test Case: User not assigned to any OCI group

In this test, you pick an enterprise user that is not assigned to an OCI_* group, say UserNoOCI:

1. Open the OCI Console
2. Select your Identity Provider and click Continue.
3. In the Identity Provider's login screen provide the required credentials.
4. In the OCI Console this user can look around, but will not be able to do anything.

Test Case: User assigned to an OCI_DepartA_Admin compartment group

In this test, you pick an enterprise user that is assigned to the OCI_DepartA_Admin group, say UserDepartAAdmin:

1. Open the OCI Console
2. Select your Identity Provider and click Continue.
3. In the Identity Provider's login screen provide the required credentials.
4. In the OCI Console this user can select the any category, open any menus and submenus.
5. In the DepartA compartment this user can read, user, modify and manage the related resources.
6. In any other compartment this user can't read, user, modify nor manage any of the related resources.

Summary

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.

References

• Best Practices for Identity and Access Management (IAM) in Oracle Cloud Infrastructure
• Oracle Cloud Infrastructure Compartments
• Oracle Cloud Infrastructure - Federating with Identity Providers