Google Project with consent set to internal / Who is a "member of my organization" and how do I manage members?

5
votes

Disclaimer: https://console.cloud.google.com/support/community leads here. Google's documentation is horrific so giving this a whirl on the off chance that I don't get downvoted to the depths of dev/null

Out of impending necessity I am migrating a private application that monitors our Gmail accts to OAuth 2, and as part of this process it was necessary to create an OAuth consent screen. Since this application will only be used internally it makes the most sense to choose "Internal" for Application Type - which is described as follows:

Only users with a Google Account in your organization can grant access to the scopes requested by this app.

The users on this Project consist of two "owners" — myself using my personal Gmail acct, and another employee who is part of the company G Suite account.

My question is who qualifies as a "user in my organization"? Is this based on the project owners? Does my non-G-Suite account (which is an owner of the project) qualify? Does the inclusion of one member in a G Suite account automatically associated the other employee accounts? Is the anywhere to actually see these users or manage them directly?

I'd actually like to add another couple accounts to the mix but still keep the application private, but I'm confused about how Google determines which gmail accounts will be able to authorize the app.

UPDATE: To clarify, when I visit the consent page while logged in as a member of our G Suite on the same domain as the project owner, everything is fine. However, we have other members managed in the same G Suite account who are under a different domain and for these I get the message:

Error 403: org_internal This client is restricted to users within its organization.

Furthermore, I am not even able to grant access using my own email which is the creator and owner of the application. I'd like to know how I can add myself and the other G Suite members to be able to grant access to the application without making it public. It was suggested below that I add them (or their domain) to Google Cloud IAM but I'm unclear about how to get this working. My own email does already exist in IAM with role of "owner" and apparently that doesn't satisfy the requirement.

3
google-cloud-platformgoogle-oauthgoogle-workspacegoogle-iamgoogle-cloud-iam
The role Owner is a legacy role. This role does not have all permissions. The answer to how depends on how you have your account setup. If this is an Organization in the Google Cloud definition, then you need to add your IAM Member ID at the Organization level with the Organization Administrator role. – John Hanley
The description of Project Owner is "Full access to all resources" i.stack.imgur.com/ezHJX.png - also, this appl is fairly new, I'm not sure why this would be considered a legacy role – Eaten by a Grue
"you need to add your IAM Member ID" - as I mentioned in the question I used my personal Gmail account to set this up. I am not a member of the linked G Suite account. – Eaten by a Grue
G Suite is a source of identities and is NOT the only one. Please reread my comments and my answer. You can use your Gmail email address. You just need to place it at the correct level in the organization with the correct role. I will repeat - 1) Owner does not have all permissions in Google Cloud. There are permissions above Owner. 2) Owner can grant itself more permissions. cloud.google.com/resource-manager/docs/quickstart-organizations – John Hanley
Ok, I've added my personal email with the role "Organization Administrator" via IAM. I can now see I have access to all organization resources in the cloud console. However, the consent page still returns an error: "Authorization Error - Error 403: org_internal This client is restricted to users within its organization." – Eaten by a Grue

3 Answers

4
votes

In order for internal apps to be used for OAuth, the project must belong to the organization associated with the same GSuite customer as all the users.

non-GSuite accounts cannot be used by internal apps. There's more information about this here: https://support.google.com/cloud/answer/6158849#public-and-internal.

4
votes

Who is a member of my organization?

Anyone that you have added to Google Cloud IAM for a project, folder or at the organization level. This can include Google Accounts (Gmail email addresses), G Suite and Google Identity. The last two use a domain name (example.com) and anyone with an identity in that domain ([email protected]).

Google's goal is to tighten up security for Google Cloud Platform. In the past anyone with a Google Accounts email address could use your projects OAuth to request access. The level of access is controlled by OAuth Scopes. Today, granting that access results in a Consent Screen with an unverified application warning. To get beyond (remove) that warning often requires a security audit of your application with a cost estimated at $75,000 USD.

How do I manage members?

Through Google Cloud IAM. You can add and remove members; assign and remove IAM roles attached to member IDs. Through G Suite or Google Identity by adding or removing member accounts. Don't forget that members can be part of a Google Group and part of a Domain each of which are also an identity in Google Cloud Platform.

1
votes

For GSuite Users:

Cloud IAM only deals with authorisation you would need to handle authentication elsewhere. By default GSuite integrates with CloudIAM as a default authentication provider.

For Non-GSuite Users:

You can use cloud identity free edition but users will have to manage separate set of credentials.

Single Sign On without GSuite

If you want Single Sign On Option you can also use Google Cloud Directory Sync to sync with your on-premise Active Directory or LDAP server for authentication. So users can keep their login details.

That's how authentication works on GCP. As for authorisation you have CloudIAM where you can manage access through Predefined Roles, Primitive Roles and Custom Roles.

Cloud IAM and Authorisation

Typically you assign access using google groups and resource hierarchy to make it easier for you to manage user access. But bear in mind that if you grant an access to something through a ascenstor folder in resource hierarchy then you can't deny access downstream. So you need to plan access hierarchy accordingly.

To answer your question who qualifies as a "user in my organization"?, everyone can login but by default they cannot access any projects, it's resources or apis unless they are given access to either individually or through a group.

Hope this clarifies things for you a little.