Since we provide support for several clients in OCI, we regularly need to login into different OCI-tenancies.

How nice would it be to have Single Sign-On (SSO) functionality between these different customer environments. Just 1 credential for all environments, granting and revoking access a lot easier. Also no need to bother the customers administrator to create an account for a new colleague who might (or might not) need to login the environment. And of course the benefit to be able to have more strict rules on how to logon (MFA, only within IP-bounderies or certain hours).

Luckily I found out that Oracle has some pretty good documentation on this. This documentation will be the basis of this blog, flavored with my own experience, thoughts and explanations.

The situation:

We have our own AMIS tenancy which will hold the user accounts for the admin-team, who need to be able to login in into any customer OCI environment.  On the other side of the playfield we have the tenancy of our customer where the work needs to be executed.

First we start with the preparation in our AMIS tenant

1. Create user accounts

First step is to create an account for all colleagues in the AMIS-tenancy. This can be done manually, but if it is more then a few accounts you can also use the import functionality. Log into IDCS, open the “Admin Console” and click on users. Create the required user-accounts (either manually or via import). No need to grant access to groups or applications on this point.

2. Create “Confidential Application”

A confidential application is the linking pin between 2 tenancies. It allows the customer tenancy to validate a user against our AMIS tenancy.

Still in IDCS, open the hamburger menu en click on “Applications”. Click on the “+ Add” button, and click on “Confidential Application”.

• Give the application a name ( I use SSO_<customer_name> to clarify what it is about) and optionally add a description. Leave the rest untouched and click on the <Next> button.
• On the next screen select “Configure this application as a client now”. Tick the checkbox for “Client Credentials”. Scroll down and click on the <+ Add> button below “Grant the client access to Identity Cloud Service Admin APIs”. In the pop-up window select the “Identity Domain Administrator” and click <Add>.

Click <Next> on top of the screen

• Click <Next>, <Next> and <Finish>
• In the popup window a Client ID and Client Secret are shown. Copy these, you will need them later.
• Close the popup window and click <Activate> on top of the screen to activate this application. Of course we click <OK> to confirm we want the application to be active.

3. Create group

Next step has a design decision in it. I prefer to have a group per customer. Any colleague added to this group will have access to the customer environment. Not all colleagues need access to every environment. Another choice would be to create 1 group with all colleagues in it and grant this group access to all customers. Third (but not advised) would be granting each individual access to each application.

Still in IDCS, open the hamburger menu en click on “Groups”. Click on the “+ Add” button.

• Give the group a reasonable name (I use SSO_<customer_name> here also)
• Click <Next>
• Select the users that should be in this group (and thus get access to the specific customer environment)
• Click <Finish> to create the group

While still in the Group screen, click on the <Access> tab, followed by a click on the <+ Assign> button.

• Scroll down to the application created earlier (SSO_<customer_name) and click on the <Assign> button on the right of it.
• If you want more application to be assigned to this group, go ahead.
• Click <OK> when finished.
  

4. Record IDCS Base URL

To be able to tell the customer where to find the tenancy to federate to, you need the IDCS Base URL. While still in IDCS, you can simply copy this from the address bar from the browser ?.

It should look similar to this:

https://idcs-00a0a0000a000aa0000000aaaaaa000.identity.oraclecloud.com

Be sure there is no / on the end.

All preparations are done now, next we log into OCI console of the customer environment with an account which has administrator privileges

5. Add new Identity provider

From the hamburger menu select “Identity & security” followed by “Federation”

• Click on the <Add Identity Provider> button
• Give the provider a reasonable name (I use amis_beheer) and description
• Select “Oracle Identity Cloud Service”
• In the next 3 fields we need to provide the results we captured in previous steps (step2 & 6).
• Leave the other options untouched, and click <Continue>

Last step is to create a mapping between the groups in your IDCS environment (like the SSO_<customer_name> group we created) and the group in OCI which actually gives the permissions (via policies).

• Simply select the correct group(s) on the left and right side of the screen. Most easy would be to select the created SSO_<customer> group on the left, and the Administrators on the right.
• When finished click <Add Provider>.

All done, time to test!

Open a new browser and navigate to https://www.oracle.com/cloud/sign-in.html?accountname=<customer-account>. You will notice that in the SSO screen an extra identity provider is present:

Select the new identity provider and login with the credentials from the main tenancy.

What’s next?

Of course there is a lot to improve on the solution we created above, highly depending on the situation. Maybe you need more segregation of duty by creating multiple groups in both tenancies. Also on the customer side in OCI one can use policies to restrict access to specific compartments and/or components