I have set up an integration using GSuite Domain wide delegation + service account which allows us to act as any user within our domain.
Currently this method isn't a very "user friendly" option for our customers at rulerr.com and I'm seeking to run through the Oauth2 consent process for other domains outside of our Organization.
Ideally they would be able to consent as an admin (known as admin consent) and then we can access all user data (calendars/mail/drive) by simply retrieving a token or two.
This is possible via Microsoft Graph with application and delegated permissions (see https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/)
Can anyone tell me if this is possible in GSuite? I cannot find any information other than for service accounts for a single Organization.
For anyone looking for an answer to this question with more detail than what is available in the Google API documentation, this page helped me a lot: http://youdontneedacrm.tumblr.com/post/81479000201/tutorial-create-your-application-in-google-marketplace
"Admin consent" is given when the admin of rulerr.com authorizes the client_id of your API Service Account in their G Suite domain. This can be done two ways:
Admin of rulerr.com adds your client_id to the Security-->Manage API Client Access section of the G Suite admin site. This grants your API client access to all accounts in their domain instance for the scopes authorized.
If you enable the Marketplace SDK in your API project and create/deploy a marketplace app, their admins can install that app to their domain which grants consent for all users, except they can OU limit it so that it is only granted for users in the OUs they choose.
Related
I am working on GCP projects that use OAuth2.0 Client IDs set up using GCP APIs & Services > Credentials > OAuth 2.0 Client IDs.
Anyone with an email address that belongs to these project's parent organization can log-in via our OAuth2.0 OpenID Connect login pages.
Is it possible to restrict which individuals can login? It would be very convenient, for example, to define a Google Group (let's call it "Group 1") and then add specific users to that group. We could then have a specific project (call it "Project 1") require that users be in "Group 1" in order to login to "Project 1". If a user doesn't belong to any groups or belongs to "Group 2", instead, they would not be able to log-in to "Project 1".
If the users do not have IAM roles/permissions, they can authenticate to your application and be able to do nothing with Google Cloud. Are you confusing authentication with authorization? You can control access to Google Cloud on a per-user basis. Turn Google Cloud Platform on or off for users
Yes, Google Cloud supports groups. You can add identities to a group for group role management. Managing groups in the Cloud Console
Users do not log in to groups. They can be members of groups and assume those permissions.
[Update after question modification]
Google Cloud does not provide application-level authorization. You must implement access control within your application or framework.
From the OIDC or OAuth perspective.
Is it possible to restrict which individuals can login?
OAuth 2.0 is about delegation to limit what an app can do on behalf of a user;
Although OIDC, which is built on OAuth 2.0 has authentication as part of the flow, it is only to the flow it is ONLY for the user to delegate permissions (Scope in OAuth 2.0) to an app.
You certainly could have separate scopes (for Project 1 and Project 2) that would grant scopes for the delegated access to the two different applications.
Also, generally you should grant only positive scopes for access and all others are refused. (i.e. " user doesn't belong...") would be if you do not have scope "Project 1", you can not access the resource.
IAP allows you to protect apps on AppEngine by defining which principal has access using roles/iap.httpsResourceAccessor. If I have a group in IAM called participants and I add external people (personal gmail accounts & contractors) to that group, will these people have access to my application?
Or do I have to submit the application for verification even though I want to limit the access to our employees and a few dozen customers taking part in a workshop?
So in other words, does IAP define "people in your organisation" as people who have a #myorg.com email address only or as people who are part of a group that has IAM permission?
"People in your organization" are users who have been granted permission in your Google Cloud Project or Organization. This includes #gmail.com accounts, which can have roles granted and can be added to groups.
For an internal application you do not need to verify the app, but you will need an internal OAuth page.
You can find more information in this documentation.
Consider this scenario:
I have two domains: domain1.net and domain2.net.
I have GCP enabled on domain1.net and created a Service Account here that has Domain-Wide Delegation Enabled.
The CLIENT ID from this Service Account is configured on domain1.net GSuite Admin Console as domain wide delegation and has the following OAuth2 scopes enabled:
SCOPES = [
'https://www.googleapis.com/auth/admin.directory.group',
'https://www.googleapis.com/auth/admin.directory.group.readonly',
'https://www.googleapis.com/auth/admin.directory.group.member',
'https://www.googleapis.com/auth/admin.directory.group.member.readonly',
]
I have a Cloud Function that uses the Service Account's rights to create a OAuth2 JWT, to be able to access GSuite domain1.net APIs. Code Sample Here.
The user to impersonate in GSuite has Group Admin Roles to be able to create GSuite Groups.
All this configuration works perfectly, I am able to create Groups in domain1.net using a Cloud Funtion in domain1.net GCP env.
But if I use the same Service Account CLIENT ID in domain2.net give the same OAuth2 Scopes, create an user with Group Admin Roles and use this user to create new groups, it doesn't work.
Error:
error got with oauth2client==4.1.3
oauth2client.client.HttpAccessTokenRefreshError: unauthorized_client: Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.
error got with google.oauth2:
googleapiclient.errors.HttpError: unauthorized_client: Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested.
Now the above error code: unauthorized_client found in this documentation specifies that the CLIENT ID is incorrect and I've might have used the Service Account's email, which I did not.
Is Domain-Wide Delegation cross GSuite organization(different domain) capable?
I know that it works in any sub-domain of domain1.net but not in any other GSuite organization(different domain like domain2.net).
I have good news for you (This won't answer your question but will solve your problem)!
You won't need to impersonate an admin anymore to create groups. Google just last week announced that the Cloud Identity Groups API will now allow for Group Management via API w/o impersonating an admin.
Take a look at these update blogs:
https://gsuiteupdates.googleblog.com/2020/08/use-service-accounts-google-groups-without-domain-wide-delegation.html
https://gsuiteupdates.googleblog.com/2020/08/service-accounts-in-google-groups-beta.html
https://gsuiteupdates.googleblog.com/2020/08/new-api-cloud-identity-groups-google.html
I can't help you with the actual question, tho; that's just not my territory.
A service account belongs to the application for which you created it. If this application belongs to domain1.net, the service account will be able to impersonate accounts from domain1.net, not from any other domain.
If you want a service account to impersonate users from domain2.net, create another service account on a GCP project that belongs to domain2.net.
Reference:
Using OAuth 2.0 for Server to Server Applications
I'm currently investigating the most appropriate authentication/authorization approach for a greenfield project, to be entirely hosted on Google Cloud Platform. I'm writing this summary to do a sanity check of my preferred approach & seek feedback on whether there are any considerations or inaccuracies I'm unaware of. I would appreciate input from anyone with relevant experience in implementing the associated strategies.
The main queries/concerns I have are:
How to manage or negate scopes in the OIDC process? It should not be up to the user to authorize appropriate access; this should be set by the org IT admins that created the user
Can G Suite IT admins apply params to users (custom &/or not) which automatically allocate predefined "Google Identity/IAM" policy groups/roles?
Will the G Suite users signed JWT's/Google ID be directly compatible with Endpoints + IAP (not requiring any processing/re-encoding)?
Will this approach accomodate external users via a federated identity approach, in future, without major refactors to the existing process (e.g. Firebase auth)?
Requirements:
Angular SPA will be the single GUI for the application, hosted on the same domain registered for the organisation on GCP/G Suite
SPA will use GCP's api gateway (Endpoints) to make requests to GKE micro-services (likely all within the one VPC) & other G Suite services (Drive, etc)
Org IT G Suite admin's can create users & assign various (predefined) IAM policy groups/scopes via the G Suite UI, to give users least privilege access to org resources (G Suite services & GCP hosted custom api's/apps)
Users are ONLY able to "sign in with Google" to the SPA, using their orgs G Suite account
If the User is already signed into their org google account, they should not need to sign in again to the SPA
While logged into the SPA, the users credentials should be sent with each request, which micro-services will use for authorization of custom business logic, as well as passing those credentials to G Suite services like Google Drive (leverage api scopes authorization as additional layer of security if custom business logic fails)
In the distant future, there is potential to allow customers/users, external to the org, to utilize various federated identity providers (Facebook, Twitter, etc) to access a SPA & resources hosted by the org (this is not a current requirement, but it is a long term strategic goal)
The two approaches I've determined best fit for purpose are:
1) Endpoints
Google Sign-In with IT Apps to obtain the users org Google ID &, as we are using OpenAPI, the GCP Endpoints with an Identity-Aware Proxy (IAP), to manage authentication of the JWT token.
Pros:
Establishes a clear demarcation between internal users of the UI portal, & potential future external users
No custom code for IT admins to manage users
No custom code to sync Firebase & G Suite users, roles, permissions, etc, or access the mirrored G Suite user for credentials
OR, 2) Firebase
Firebase authentication, & write code to generate users in G Suite with the Firebase Admin SDK, restricting access to resources based on the org domain.
Pros/Cons are the opposite to Endpoints above, plus no need for 2 separate auth approaches if external users are ever required.
I'm leaning towards the Endpoints approach...
How to manage or negate scopes in the OIDC process? It should not be
up to the user to authorize appropriate access; this should be set by
the org IT admins that created the user
Permissions for IAM members (users, groups, service accounts, etc) are managed in Google Cloud IAM. Scopes are used with OAuth to limit permissions already assigned by IAM. Best practices mean assigning the required permissions (and no more) and not combing IAM with scopes.
Can G Suite IT admins apply params to users (custom &/or not) which
automatically allocate predefined "Google Identity/IAM" policy
groups/roles?
G Suite and Google Cloud are separate services. Google Cloud supports G Suite as an Identity provider (IDP). Permissions are controlled in Google Cloud IAM and not in G Suite. You can combine G Suite with Google Groups to put IAM members into groups for easier IAM management.
Will the G Suite users signed JWT's/Google ID be directly compatible
with Endpoints + IAP (not requiring any processing/re-encoding)?
Google Accounts (G Suite) do not provide private keys to its member accounts. Therefore you cannot use Signed JWTs. Signed JWT is an older authorization mechanism and is used with service accounts. The correct method for user credentials is OAuth 2.0 Access and Identity tokens. For administrators, service accounts with Domain Wide Delegation can be used.
Will this approach accomodate external users via a federated identity
approach, in future, without major refactors to the existing process
(e.g. Firebase auth)?
This is a difficult question to answer. Google Cloud does support external identity providers but I have found this to be problematic at best. You can also use identity synchronization but this is also not well implemented. If you are going the Google Cloud route use G Suite as your identity provider and Google Cloud IAM for authorization.
An important point that I think your question lacks is understanding how authorization works in Google Cloud and Google APIs. These services primarily use OAuth 2 Access Tokens and Identity Tokens. This varies by service and with the type of access required. This means that your application will need to understand the services that it is accessing and how to provide authorization. I have a feeling that you are expecting Firebase/Endpoints to do this for you.
Another item is that Firebase is part of Google Cloud and is only a subset of Google Cloud. Firebase is a great product/service but if you are planning to use Google Cloud features outside of Firebase, then stay with G Suite and Cloud IAM for identity and authorization.
Angular SPA will be the single GUI for the application, hosted on the
same domain registered for the organisation on GCP/G Suite
I am assuming by domain you mean DNS Zone (website DNS names). This will make CORS and cookie management easier but is not a requirement.
SPA will use GCP's api gateway (Endpoints) to make requests to GKE
micro-services (likely all within the one VPC) & other G Suite
services (Drive, etc)
OK - I don't see any problems using Endpoints. However, a good answer requires details on how everything is actually implemented. Another item is that you are mentioning Endpoints and G Suite services. These are very different items. Endpoints protect your HTTP endpoints not other Google services where it would just get in the way.
Org IT G Suite admin's can create users & assign various (predefined)
IAM policy groups/scopes via the G Suite UI, to give users least
privilege access to org resources (G Suite services & GCP hosted
custom api's/apps)
Google Cloud IAM and G Suite authorization are separate authorization systems. In order for G Suite members to manage Google Cloud IAM, they will need roles assigned in Google Cloud IAM via either their member ID or group membership. There is no shared authorization permissions.
Users are ONLY able to "sign in with Google" to the SPA, using their
orgs G Suite account
Unless you configure SSO, Google Account members are the only ones that can authenticate. Authorization is managed by Google Cloud IAM.
If the User is already signed into their org google account, they
should not need to sign in again to the SPA
That is up to your application code to provide the correct Authorization header in requests.
While logged into the SPA, the users credentials should be sent with
each request, which micro-services will use for authorization of
custom business logic, as well as passing those credentials to G Suite
services like Google Drive (leverage api scopes authorization as
additional layer of security if custom business logic fails)
I am not sure what you mean by "User Credentials". You should never have access to a user's credentials (username/password). Instead, your application should be managing OAuth Access and Identity Tokens and sending them to the backend for authorization.
In the distant future, there is potential to allow customers/users,
external to the org, to utilize various federated identity providers
(Facebook, Twitter, etc) to access a SPA & resources hosted by the org
(this is not a current requirement, but it is a long term strategic
goal)
I covered this previously in my answer. However, let me suggest clearly thinking about what needs to be authorized. Authorization to your app is different that authorization to your app that also authorizes Google Cloud services. For example, you could use Twitter for authentication and a single service account for Google Cloud authorization. It just depends on what you need to accomplish and how you want to manage authorization.
[UPDATE]
One term that you use in your question is SPA. In the traditional use case, all processing is being done by your application in the browser. This is a security nightmare. The browser will have access to the OAuth tokens used for authorization and identity which is not secure. This also limits your application's ability to generate Refresh Tokens which means the user will need to reauthenticate once the existing tokens expire (every 3,600 seconds). For the scope of this question, I recommend rethinking your app into a more traditional client/server design. Authentication is handled by your servers and not directly by (inside) the client application. In the sections where I mention service accounts, I am assuming that backend systems are in place so that the client only have an encrypted session cookie.
As per my experience,
G-Suite as Identity provide + Cloud IAP will work to authn and authz to do user level access checks on the frontend. refer this
However for backend application to application communication, I will recommend service accounts in GCP, refer this. You can also use Cloud IAP to do the same, refer this. However the choice depends on your use case and your companies security guidelines and policies.
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.
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.
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 (someone#example.com).
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.
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.