Introduction

So now you have a cloud account and you need to start on-boarding employees to manage and administrator all the different services within Oracle Cloud Infrastructure (OCI).  What do you do next? When deciding how to on-board and manage users it is important to get this right.  Setting up your identity posture will lay the foundation for securing OCI artifacts as well as your applications in the cloud.

This post will guide you through with recommendations to help simplify your identity posture.

Initial setup

Each cloud account is provisioned with a 'primordial' Identity Cloud Service (IDCS) stripe.  The multi-striping feature allows you to create multiple instances of IDCS within your tenancy.

For every new instance of IDCS you will need to provide the license type, the administrator's e-mail address and whether this is a Enterprise (E) or Consumer (C) instance.  Each instance is a standalone instance with a single administrator user as defined during creation. 

For details on the the pricing model and how to set up secondary strips click here.

Why do I need to create another IDCS instance?  How many do I need?

Let's say we have four environments and two sets of users; Employees and Customers. Do we want to separate each user base with their own IDCS instance?  If we did that we might have something like:

This is definitely an option; but is is needed?  In this scenario, there are nine IDCS instances.  Each with their own administrators and user base.  Each user profile may also have passwords for every environment; which can be a management nightmare.  However, IDCS now has functionality to sync users and groups between IDCS instances but still is all this necessary?

Let's look at a sample use case.

Use Case

Again let's say customer Acme has two sets of users; Employees and Customers.  Acme would like to create four roles for their user base:

• Administrators (OCI, IDCS, Applications)
• Developers for their applications
• Employee protected applications
• Customer protected applications

How can we structure Acme's identity posture to minimize the number of IDCS instance and to streamline management? 

First let's discuss the four roles above in more detail.

Administrators

OCI

At the very least you will need administrators for OCI and IDCS.  For OCI you have two options where the administrator profiles are stored:

1. OCI IAM - these are local OCI users.
2. IDCS as an IdP - These can be local or federated users within IDCS.  The federated users can also live in a different IDCS stripe or any Identity Provider (IdP).  Group information must be passed and mapped to OCI to define different roles within OCI.  Check out the official docs here.

IDCS

A local admin user that was given during creation of the stripe will be created initially as an super admin.  You can then add users and designate them as administrators with IDCS.

Developers

This role defines the developers within the organization.  In this case only certain employees are designated as Developers.  In our example, this can be any Employee based role.

Employees

The source of truth for all Employees. This include passwords that are stored in IDCS or even federated accounts in some situations.

Consumers

The source of truth for all Consumers.  These can be external users/vendors/customers of Acme etc.

Now let's take a look at how we might simplify the number of IDCS stripes.  In the diagram above; we went from nine strips to five (see diagram below).  We still have the primordial stripe, two production stripes and two internal stripes.  The production stripes will be the source of truth for all users and their credentials.  The internal stripes can be shared between all non-production environments.  You may choose to store passwords in the internal stripes or you can federate to production where the passwords are stored.  I recommend that you use the primordial stripe to store OCI Admin groups that will be used to administer OCI components.  Again you can use the SCIM interface to sync users to multiple stripes as needed.  In the diagram below the SCIM interface is used to sync only administrator user's of OCI.  Once they are synced the IDCS admin will place those users in groups to be federated to OCI for access.

There is nothing that prevents you to store everything in a single IDCS insance; however it may prove difficult from a manageability perspective. Also 'separation of duties' maybe be a requirement; where one administrator can create a user in the employee stripe and another administrator can assign that employee to a group for OCI access.

Conclusion

At a high level the recommendation is as follows:

• One stripe for OCI administrators; where they can define the groups required to protect OCI.
• One stripe for Employees as the source of truth.
• One stripe for Consumers as the source of truth and
• Two internal stripes that represent each user type (Employees and Consumers).