Accessing Oracle Cloud Infrastructure (OCI) using Google G Suite SSO

Posted in: Cloud, Oracle


One of the nice things about so many web apps these days is how easily they integrate with Google authentication and Single Sign-on (SSO). This is thanks to web-based authentication and authorization technologies such as SAML and OAuth.

So the logical question is: if our organization uses Google G Suite as our directory service, can we configure G Suite users for Oracle Cloud Infrastructure (OCI) authentication and access? So OCI cloud admins won’t have to manage and enter OCI specific credentials but rather can just click on their G Suite SSO user to log into OCI?

The Oracle documentation talks about identity federation with Oracle Identity Cloud Service or Microsoft Active Directory but mentions nothing about Google G Suite. Fortunately, though, both OCI and G Suite are SAML (Security Assertion Markup Language) 2.0 compliant so the answer is clearly “YES”.

Hence, setting up OCI access using G Suite authentication is possible and actually pretty simple.


Implementation summary

The implementation is really only a one-time setup process but does require administrative access to both OCI and G Suite. For SAML, there are three entities involved:

  • Users: the cloud infrastructure administrators who need to connect to OCI.
  • Identity Provider: in this case, the IdP is Google G Suite.
  • Service Provider: in this case, the SP will be OCI, of course.

The process can be summarized as:

  1. Configuring G Suite to accept authentication requests from, and send the pertinent data back to, your OCI Tenancy.
  2. Adding G Suite group(s) to manage OCI users in the G Suite directory service. (Optional: implement as necessary.)
  3. Federate OCI as an SP using G Suite as the IdP.
  4. Map G Suite groups to OCI groups as necessary.
  5. Add the necessary policy statements to the OCG groups as necessary.


Setup details

Setup starts on the OCI Federation screen. Using the OCI sidebar, navigate to Identity -> Federation:


Here you likely only have one federated identity provider, “Oracle Identity Cloud Service”:


The key is the link in the bottom right for downloading metadata required for setup with other SAML 2.0-compliant identity providers. Choose the Download this document link and open the resulting XML file.

Near the top, you’ll see a URL labelled “entityID” which includes your Tenancy OCID. For example:


You’ll need this URL for the G-Side side of the setup – G Suite doesn’t have an option to import this data.

The format is clearly:


Hence, the same data could have been manually constructed instead of downloading and analyzing the metadata XML.

Another URL that will be needed later is in the AssertionConsumerService XML element. However, inspection shows that the URL is exactly the same and the entityID URL.

Next, setup on the G Suite side is required. From G Suite, log into the Admin console ( choose Apps -> SAML apps from either the main landing page icon or the menu:


From the SAML apps page, choose Add a service/App to your domain (or press the yellow plus button).

Oracle isn’t a known service/app so choose the SETUP MY OWN CUSTOM APP button at the bottom:


We need to save the G Suite Identity Provider (IdP) XML metadata so it can be loaded into OCI. Choose Option 2 IDP Metadata from the Step 2 screen:


On the Step 3 screen, enter in a name for the new SAML app. For example: OCI-<tenancy name>. Upload a logo if desired.


In Step 4, enter the OCI URL determined earlier (that contains your tenancy OCID) for both the ACS URL and the Entity ID fields:


Step 5 asks for optional Attribute Mappings – none are required for OCI SSO.


Press Finish and observe a confirmation that the new SAML app has been created:


At this point, the service needs to be enabled and a G Suite group should be configured specifically for OCI admin (it’s recommended but not mandatory to specify a new G Suite group – an existing one could be reused):


Navigate to your G Suite groups page and choose to create a new group. Enter an appropriate name such as oci-<tenancy_name>-<functional_purpose> :


Add the required G Suite users or groups to the new group:


Lastly, the new G Suite service needs to be enabled for the appropriate users. From the Admin console navigate back to the SAML Apps :


Choose the ellipses on the right and the option ON for some. Then turn on the necessary G Suite organizations:


Press APPLY and then TURN ON from the subsequent screen. Notice the warning that it may take some time for the change to come into effect (but likely not 24 hours).


The remaining setup is done on the OCI side. Back at the OCI Federation page choose Add Identity Provider (we can have more than one).

Add a new name for your IdF. For example, in the format: G_Suite-<domain>. Choose the second radio button and browse to and upload the G Suite IdF metadata XML file you downloaded from G Suite earlier and press Continue.


At this point, you need to map the new G Suite group to an OCI group (which can be existing or new). It is recommended to not use the existing default OCI Administrators group but instead to use something else/new:


At this point the new identity provider appears so we have to configure the OCI group and policies:


Navigating in OCI to Identify -> Groups shows that the new group was automatically created:


There’s no need to create OCI users since they come from G Suite (which is the point). But we do need to add the required OCI IAM policy for it.

Navigate in OCI to Identity -> Policies and choose the Create Policy button. Enter the name, description and policy statements:


Note: you may want to have a more restrictive policy or policies than shown in sample screenshot above!


At this point, the setup is complete. Now it’s time to log in to OCI using G Suite SSO.


Logging into OCI using G Suite SSO

Navigate to the OCI login screen using a URL in the form of https://console.<home_region> and enter your tenancy name and press Continue:


Now in the SSO section, we can use the IDENTITY PROVIDER pull down and choose the new G Suite federated provider we added and press Continue:


This leads us to the familiar Google Account selection screen where we can select the G Suite user we configured for OCI access:


After clicking on the appropriate Google account you’re logged into to OCI!

Clicking on the OCI Profile icon at the top right, we can confirm who we connected as:


As can be seen, the user is in the form of <OCI_federation_name>/<G_Suite_user>.



As was shown, there are a number of one-time administrative setup steps to be done both on the OCI and G Suite sides to allow Google SSO to OCI.

But once the initial setup and configuration is done, logging in is trivially simple and user management can be fully controlled by the federated IdP – in this case G Suite.



Interested in working with Simon? Schedule a tech call.

About the Author

Simon describes himself as a technology enthusiast who is passionate about collecting and sharing interesting database tips. If you want to see his eyes light up, let him teach you something new. Based out of Calgary, Alberta, Simon is known for his contributions to various online Oracle communities, and being very thorough in his work. A self-proclaimed stereotypical Canadian, Simon can be found watching hockey with his family in his spare time.

11 Comments. Leave new

Hi Simon,
Great article. I was able to Federate OCI with G Suite. Logged on to OCI with G Suite.
But Group Mapping of G Suite group to OCI group is not working. Mapped to default Administrator group, also created a new group as you mentioned in the post but no luck.

It says
” Nothing here? Possible reasons:
No resources exist in this Compartment, in this Region.
You don’t have access to view this resource in this Compartment.
Contact your administrator if you have questions about your access.

I am looking at the right Region & compartment. Everything is there was i login to OCI with my local account.

In OCI, when i go to Identity > Group > Administrators> IdP Mapped Groups > my GSuite group is listed here.

Do you know what could be the cause? Have you experienced this before?



Try assigning the policy statement explicitly to the federated group like I show in the examples. If you just provide a lower level permission such as INSPECT then that will at least tell you that the policy is in effect and that other permissions are not possible as they lack an associated policy statement.


I’m trying to configure but the gsuite groups, users and permissions can’t work. Login with gsuite works perfect but the another parts no. Pls gave me some light!!!

Pedro Henrique Feliciano da Silva
May 28, 2020 7:40 pm

Hello Simon, how are you?
This is amazing POST .. Congrats :)
I was also able to configure the LOGIN SSO through GSUITE,

Could you explain more about how to use GSUITE groups to integrate with OCI and separate permissions?

Tks agains


Unfortunately the group mapping has become an issue lately with OCI and the process described in this blog. And I have not yet been able to resolve that with the current OCI functionality. Might need to federate through IDCS instead – not sure it’s still going to work the way described here given the current state of the technology.


Everything works, but permission to manage resources Doesn’t

I created the group on GSUITE, added the group to the federation and applied the permission.

Still unsuccessful


As mentioned, I think the group-mapping functionality is now broken and I have not been able to resolve within the current OCI functionality. IDCS federation may provide a workable solution but I have not tested yet.

Cédric Carré
June 19, 2020 8:51 am

Hello Simon,

Nice how to :). I need to enable SSO with Gsuite for my company but didn’t suceed :( . I have “NotAuthenticated” error.

I read that group-mapping is not working anymore but did you succeed to have SSO working without that ? If yes, How ?

Thanks for help.


No, not working without the group mapping. Federation of G Suite through IDCS might be an option that works but haven’t yet tried.

Cédric Carré
June 19, 2020 10:15 am

Hmmm that’s embarrassing for me … Our company refuse to use others than Gsuite SAML. That’s a security prerequisite.

Correct me if I’m wrong but by IDCS ,you mean Oracle Identity Cloud Service right ?


Correct. There are ways to federate an external system to IDCS and then use IDCS to log into OCI. So kind of “two hops” in federation vs one. Of course the “one hop” would be easier and cleaner but we need to work out the group mapping issue.


Leave a Reply

Your email address will not be published. Required fields are marked *