I have an application that can manage Google Calendar within the Google Workspace of the company. The application contains more than one company.
I want to use domain-wide delegation. As described here or here admin of the workspace needs to add service account id and scope manually.
Is the way to do this programmatically?
After some research and also looking into Google Workspace's Admin SDK documentation here and here this does not seem to be an available option at the moment.
You may want to submit a feature request here for that.
For service or local applications, the admin has to manually generate the service account and grant this service account with domain-wide authorization. There is no way to do this programmatically (unless for pure SaaS applications).
Related
I am using a Google Cloud Project to automate the creation of some users inside of our organization. I have been using some API's that are hosted using the Google Cloud and have had no problem authenticating and using the API's, however I am not sure if I should be using a service account for this. I am currently using the Google Drive API, the Google Admin SDK(Directory API), the Sheets API, and the Docs API to create some accounts and manage an error log.
What I am asking is, should I be creating a service account to use the API's or is my own personal Google Workspace account okay for creating these? Is there a site/video/something that can guide me in the right direction if I do need to create a service account. I personally would rather have all of the automation using a service account for authentication, but the only videos and tutorials I found on using the service accounts are trying to use resources pertaining to Cloud Computing and service accounts that are impersonating other service accounts.
Using a Service Account is the best course of action for security reasons when you are the one giving authorization and authentication to your organization.
It is identical to granting access to any other identity to allow a service account access to a resource. For instance, suppose you only want an application that runs on Compute Engine to be able to generate items in Cloud Storage.
As a result, instead of managing each and every one of your users, you may limit and manage service accounts, assign certain roles to specific users or groups, and keep track of them because several service accounts can be created in a project.
Since you use Google Workspaces, I also advise you to read the shared documentation posted in the comments by #John Hanley.
I am trying to publish my Android app to our company's Play Store.
On Google API access page
I am trying to create new service account. It does not work.
You are missing at least one of the following required permissions:
Project
orgpolicy.policy.get resourcemanager.projects.get Check that the
folder, organization, and project IDs are valid and you have
permissions to access them
My GCP shows myname#github.com google account.
On the other side,Google API(Google Play Console) shows MYCOMPNAY Team account.
How to solve this IAM problem?
I'll do my best to answer but the question lacks some detail.
As the error describes, service accounts are a distinct type of credential used by Google that are intended to be used by software (rather than humans) for interacting with Google services. It makes some sense (though I'm unfamiliar with the Play process) that you'd need to use service accounts rather than human accounts with this service.
Unlike, regular (human) accounts (e.g. yourname#github.com), service accounts are owned by Google projects. When you create a service account, you'll need to scope the account to an existing Google project.
Google provides various Consoles for different services. I'm most familiar with Google Cloud Platform (GCP) and so I would create projects and service accounts using GCP's CLI (Cloud SDK aka gcloud) or https://console.cloud.google.com. Are you using something similar?
Unfortunately, I think, Google's tools scope projects (even though these are universal Google resources) to specific platforms (Cloud, Firebase, Apps etc.) and so you may not be able to see all your projects via the e.g. Cloud Console.
So....
If you have a Play (!?) Console, there should be a mechanism to list|create projects. If you haven't already, created a project to own your service account. Then the tool should provide a mechanism to create a service account. Do so under that projects. Lastly, you'll need to grant the service account permissions so that it can do what you need it to do (e.g. publish your app).
If you add more details to your question, I may be able to help.
NOTE One distinction between human (e.g. yourname#github.com as a Google account) and a service account is that human accounts using 3-legged OAuth while service accounts use 2-legged OAuth. This is because the service account is not able to interact with OAuth prompts as a human user would and it is often a good "tell" when you need to use a human vs. a service account.
See:
Google Play: (API) Projects and Service Accounts
Understanding Service Accounts
Using OAuth for Server-to-Server apps
I have a SaaS application with a bunch of users, and I want to provide the ability for my users to work with their data in google bigquery. The thing is, I want my users to be able to use any random application out there (like say, tableau or powerbi) using their standard built-in bigquery connectors. BigQuery connectors generally show the google login page to retrieve google credentials to call bigquery with...but my users are not google users, they don't have google credentials. So my question is: how can I sign my users into google using my application's sign-in credentials, from the google login page?
The options I know about are:
G-Suite - I provision a new google user account for each of my users on a custom domain, and setup my application as their identity provider (SAML or whatever). This is a good option, but at $6 per user per month it's extremely steep.
Gmail - I could provision each user their own gmail account, which would be free...but afaik I could not set my application to be their identity provider, so I'd have to provide them another password and manage rotating it etc...it would be hacky/fragile and sounds like a support nightmare.
BYO google account - Require the user to provide their own google account...they configure it in my app and I grant that account access to their data in bigquery. I personally like this option, but I'm told it is not acceptable from a business/product design/user experience POV (we can not require the user to manually go create an account in a different system to use a feature of our application)
Google identity platform - This almost seems like exactly what I want, except from what I can tell there's no way to actually create a real google identity that you can use to login on the real google login page - you can only create identities that can authenticate on your own custom login page...which won't work (cuz 3rd party app bigquery connectors will always display the real google login page)
GCP service accounts - Included for the sake of completeness, but these accounts also can not login via the standard google login page, so they also will not work.
From what I can tell G-suite is my only real option....but it's disproportionately pricey - I will be paying more for my users simply to be able to authenticate than I will be for all the GBs of bigquery data transfer/querying...which seems odd.
I'm hoping I'm missing an option, or misunderstanding something. Can someone shed some additional light on this for me?...or confirm that these are, indeed, the only google user account options available?
how can I sign my users into google using my application's sign-in
credentials, from the google login page?
You cannot. Your users will need a Google Account or supported account such as G Suite or Identity Platform.
From what I can tell G-suite is my only real option....but it's
disproportionately pricey - I will be paying more for my users simply
to be able to authenticate than I will be for all the GBs of bigquery
data transfer/querying...which seems odd.
Your assumption is incorrect. You can have G Suite + Identity Platform together. This means you only need to license users that need to receive email or Google apps, other users are free. This does mean that you need to create users in G Suite / Identity Platform.
BYO google account
I strongly recommend not using BYO Google accounts. You have no control over these accounts.
Gmail
This is the same thing (usually) as a BYO Google Account. Again, I strongly recommend not using Gmail accounts either.
My recommendation is to create a G Suite Account, make yourself the Super Admin and license yourself. This does require a domain name*. Then add Identity Platform and create all the users you need.
*I have not personally verified this but I am confident that you can create a subdomain from your top level domain for G Suite. Example accounts.example.com.
I want to create a user account for contacting developers using their own email addresses, not a new Gmail user in my account. Google Cloud Platform seems to let me create the users, but they never receive an email and hence can't complete the account creation.
As it happens, they are Google Docs users with their own Google accounts, but naturally they'd rather not have yet another email address. Is this even possible or does Google tie Google Cloud Platform into Google Docs? It seems a major limitation of Google Cloud Platform if they do.
Google Cloud Platform, G Suite (formerly "Google Docs") and all other Google services share an identity system. The identity system requires humans to have user accounts while software|machines have service accounts. One Google user account equals one user.
There are 2 flavors of (Google) user accounts: [your-name]#gmail.com and those created by an organization for its users someone#acme.com. For example, Google uses Google identity internally and so Googlers have emails [their-name]#google.com.
When you create a Google Cloud Platform project, anyone with a Google account may be added to it. Whether their Google account is something#gmail.com or an account created by their employer for them.
The only time your users will receive an email from you when you add them to a Google Cloud Platform project is if you make them project owners. This is because, ownership requires acceptance of Google's Terms of Service. Other types of users will be added without receiving an email (from Google about it) but will be able to access your project's resources.
I suspect your users have been added correctly and you're ready to go!
the most simple is to share a directory with those off-domain email addresses
this is possible, because Google Docs is backed by Google Drive as storage.
setting them up with IAM would only add complexity, which is not required
(at least, unless you won't have to grant them access to GCP resources).
For local development (including other team members) should we be using application default credentials for our apps, or service accounts when authenticating and using Google Cloud Platform services?
I was thinking that being able to control the individual user permissions instead of a random service account would be better, as it also prevents us from having to revoke the whole service account key if someone leaves the team. Whereas if we used ADC, it would just work as we'd disable their account and remove its permissions. However, the documentation in the Authentication overview contains this note:
Important: For almost all cases, whether you are developing locally or
in a production application, you should use service accounts, rather
than user accounts or API keys.
What is the correct authentication method to use for local development?
From the same page:
All GCP APIs support service accounts. For most server applications that need to communicate with GCP APIs, we recommend using service accounts, as they are the most widely-supported and flexible way to authenticate.
In this sense, the randomness of the service account is determined only on your way of managing it.
For your scenario, when someone leaves the team, it would indeed be easier to revoke the user account('s permissions), instead of revoking the key, affecting all using it. In my opinion, both ways are correct and the best way would be the one that best suits your context. The documentation pushes for service accounts as it is a Google account, as opposed to a specific user, and it can be used for authentication regardless of where your code runs.