I have a desktop application which I want to create a new service account for each user of my application.
Is there any API for creating the service account users on the fly?
Scenario: For each user, I want to give service account, and give this service account the data that this user needs.
The point is that I want to give every user some specific data from Google Cloud, but I want the user to get it directly from Google. I cannot use the user account, because I am not sure he have google account.
You can use the Google Identity and Access Management (IAM) API to programatically create service accounts.
However, creating a service account for each of your application's users is expensive and not scalable. Perhaps your service can have a single service account and then the service can control which of the resources that the user may access.
There is no Google Api that allows you to control projects on Google Developer console. The only thing that comes close is the Google Cloud Resource Manager API which is extremely limited in what it supports. You cant use it to create a service account.
Answer: The only way to create a new service account is to log in and do it though the Google Developers console.
Related
I am currently developing a client-side app where users login using e-mail/password against MongoDB Atlas. The backend runs completely serverless.
All logged in users should be able to upload and retrieve images from GCP - Storage bucket without a visible login, which means the application should authenticate for every user on the background.
I was thinking about using Google Service Accounts in combination with auth0, but I don't know where to start...
If someone could help me tell where to start, that would be great :)
The question is difficult to answer. However, here some insights.
The prefered way is to have a serverless backend, AppEngine standard, Cloud Run or Cloud Function for doing this. The user performs its authentication and then exchange security token between the frontend and the backend. When the user want to reach a GCP resource, it asks the backend, which request the request thanks to its own service account.
By the way, it's easy to trace the user request and to serve him only the resources related to it. And you have only 1 service account, for the backend
If you grant access to a bucket to a user, it could download all the files (But maybe there is one bucket per user?). If you chose to limit object access with ACL, the management is complex.
You don't need to have a service account per user (and in any case, you have a quota to 100 service accounts per project), you can use Cloud Identity Platform (CIP) instead of your MongoDB database for authentication (CIP don't perform authorization, you should use MongoDB for authorization and other stuffs related to authenticated user). CIP is Firebase Auth rebranded
Is a Service Account intended to be created in an application’s domain? Or in a clients G Suite Domain, on behalf of the application?
Background:
My company has a product (hereafter “The App”) which has several thousand organizations as clients, each potentially having their own Google domains. (hereafter “Organization Domain”)
We are looking to set up a sync between The App and the Organization Domain, for data that is common between The App and the Organization Domain, and want to use an OAuth2 connection, with a domain admin granting The App ‘domain-wide authority’ on behalf of their users, for offline syncing.
From the Service Account page:
... an account that belongs to your application instead of to an
individual end user. Your application calls Google APIs on behalf of
the service account, so users aren't directly involved.
and
G Suite domain administrators can also grant service accounts
domain-wide authority to access user data on behalf of users in the
domain.
Referencing the Cloud Platform Console Help Faq:
You can access data from your users' Google Cloud Platform projects by
creating a service account to represent your service, and then having
your customers grant that service account appropriate access to their
cloud data using IAM policies. Note that you might want to create a
service account per customer... (emphasis added)
It sounds like The App should be able to create a single Service Account, which all of our clients authenticate into for their Organization Domain.
The part that’s unclear:
In the Service Account page, the instructions for delegating domain wide authority seems to shift concerning where the Service Account is.
Before the instructions, it reads:
... first enable domain-wide delegation for an existing service
account in the Service accounts page ... with domain-wide delegation
enabled. Then, an administrator of the G Suite domain must complete
the following steps:
Afterwards, it reads
Your application now has the authority to make API calls as users in
your domain (to "impersonate" users). (emphasis added)
From what I’m reading, the first part reads "one Service Account for The App", while the later reads as "the service account is only able to access as a person on The App domain, rather than the Organization Domain."
Is a service account intended to be created in The App's domain? Or in the Organization Domain, on behalf of The App?
I have seen examples that have the Organization Domain admin create a service account, and then pass over the clientID/secret to the owners of The App… but I’m not sure that’s the correct approach for our scenario.
Related - Scope management:
The delegation steps have the Organization Domain admin manually add scopes.
We’d prefer to use the OAuth consent screen, which shows the scopes, and has our pages/policies linked.
Unfortunately, as far as my research has uncovered, it doesn’t look like that page is used in the Service Account authorization flow; just for other application types, which authenticate a single user, as opposed to an entire Organization Domain.
Is there a page I’ve missed in Google’s sea of documentation?
I think you are miss understanding the use of Service accounts.
Service accounts are dummy user accounts. They have their own drive account, calendar account and probably a few more. Service accounts are designed for use with back end applications server to server communication where there is no user interaction. Service accounts are preauthorized. You grant the service account access to the user data in your case by using domain wide dedication to the gsuite account. This way the service account would be able to for example send control all the users google calendar accounts.
This is why you dont need a consent screen. Another point with service accounts is you must control the data in order to set this up. If you dont control the data then you cant grant the service account access to that data.
You should be using Oauth2 if you want to access private user data owned by your customers.
As for the rest of your question is very broad and i am not really user where to start with it you might want to break it up into several questions. Take them one at a time. I am not sure i understand what it is you are trying to do so i dont think i can try to answer that part.
We currently have an account with our company that we use to collect some information from the GA account of our customers.
This account is an #ourdomain account.
We intend to automate these queries by performing them via the GA API.
When creating an authentication key, an account is automatically created # query-domain-domains.iam.gserviceaccount.com.
I ask, is it possible to create an authentication key (JSON) for the account that is already readable in our client accounts, or will we have to ask the more than 1000 domains to add permission to our new user?
Thank you for any help.
Eduardo
To give permissions to a new user account you have to have permissions in the first place, so you cannot create a new service account that already has them.
However if your already have a user account with user management permissions you can use that to insert the service account programmatically via the Management API.
I have a site that I have tagged using Google Analytics. I can see that the stats are being created and I can analyse them using Google Analytics web tool.
I want to extract my tagging data using the Google Analytics API but all the instructions seem to point me towards the developers console to create my OAuth2 token. My site does not appear in the list of apps that is presented, so I can't do the next step of generating my OAuth2 token.
I feel like I must be missing something obvious, but I am hitting brick wall at the moment. How do I get the site to appear so I can see it in the developers console?
The Google Developer console is for registering your application, this way google knows who is using there APIs. Your Google analytics account wont show up here because well that's not how it works.
Create a new project you will get a client_id and client secrete that are used to identify your application. Then you use a programming language to access the API using the client id and client secret.
I am not a java programmer so i cant help you with that. You mentioned that you want to access your own data. I recommend you look in to using a service account. A service account can be used to grant authentication without having to prompt a user for access. This only works when it is your own account you are accessing and the data doesn't belong to another user. Take the service account email address and add it as a user in google analytics at the ACCOUNT level it must be the Account level. then when you use the service account in your code you will have access.
https://developers.google.com/analytics/devguides/reporting/core/v3/quickstart/service-java
Referring to the document https://developers.google.com/accounts/docs/OAuth2ServiceAccount, was able to obtain an access-token.The above mentioned document doesn't provide any details regarding the API's that can be accessed using Service Account.Can anyone list the API's which can be accessed using access-token obtained from Google service account?
Unfortunately, we don't have an exhaustive list of the support in this area. In general, you should be able to access a Google API if that API does not require the user to do something in a web interface to configure their account before doing API access. Service Accounts can't log in. So if the service needs some interactive input from a user on a Google wesite, often their APIs will not work with Service Accounts. Hope this helps.