As a Reseller, is it possible for me to leverage Service Account to call Reseller API and Directory API to create new domains and manage user accounts under them without requiring user interaction/login/consent?
The End-to-End tutorial for Reseller API (https://developers.google.com/admin-sdk/reseller/v1/codelab/end-to-end) suggests it is possible. I could create a service account under my Reseller domain. Using this service account, I can impersonate a super user admin under my Reseller domain and can achieve the above.
On the other hand, when I read through the article on Authorizing Requests (https://developers.google.com/admin-sdk/reseller/v1/how-tos/authorizing), it mentioned that "All requests to the Google Apps Reseller API must be authorized by an authenticated user", which seems to suggests that some form of consent is required. Further, it doesn't mention that service account is supported.
I tried to search for similar topics in the forum and I am seeing somewhat conflicting responses. The answers range from "yes, this works" to "service account not supported with Reseller API" or "API access must be manually enabled in each resold domain".
Thanks!
Related
I am attempting to build an integration into our web application which allows user's to link their BIM360 account with our account. The ultimate goal is to call the BIM360 API and pull projects on behalf of the Authenticated user.
I am not seeing a way of obtaining the user's account id so that I can make a request to this api https://developer.api.autodesk.com/hq/v1/accounts/:account_id/projects on the user's behalf.
The https://forge.autodesk.com/en/docs/data/v2/reference/http/hubs-GET/ resource is able to provide me with what I need.
Th company I work for recently switched to using Team Drive and we had multiple applications that would interact with Google Drive using the Google Drive API. The API calls would be authorized using Google Service Accounts and access to specific files would be given to an app by sharing the file with the Service Account email in the same way you would share a file with a normal user. Now that we've switched to Team Drive I'm unable to grant access to the Service Account as the email address associated with it is not considered part of our organization. I've also looked into adding the Service Account as a normal user in our organization through the Google Admin dashboard, but it only allows me to create new users, not include existing ones. The only solution I've found is to enable sharing with external parties which would allow me to share Team Drive files with the Service Account, which would be considered an external party. This solution is risky and incorrect as the applications using the Service Account are part of our organization. We also do not want enable sharing with external parties in general for security reasons.
I've followed the steps described in How to access Team Drive using service account with Google Drive .NET API v3 and they work, but as mentioned above they require sharing with external parties to be enabled which we do not want.
The ideal solution would be for the Service Account to be considered part of our organization, but I cannot find a way to do this.
I've also tried delegating Domain-Wide Authority to the Service Account as described in https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority, but as far as I understand this is not what I want as this will allow the Service Account to impersonate other users, but the reason we have a Service Account is for carrying out processes that happen automatically and which aren't associated with a specific user.
I've also followed the steps outlined here https://developers.google.com/admin-sdk/reports/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account for white-listing a specific API service through the Google Admin Security interface, but this doesn't seem to do anything, and I'm not sure what it is supposed to do as I have already enabled the Drive API for this Service Account in the APIs & Services dashboard where I originally created the Service Account.
We're using R and so I've been using the googledrive package which has functions for working with Team Drives like:
googledrive::drive_find()
googledrive::team_drive_find()
googledrive::team_drive_get(id = "team-drive-id")
I would expect to be able to see the team drive, but I guess this is not possible unless the Service Account email is a member of the Team Drive which is not possible because the Service Account (which is linked to our organization through its owner) is not considered part of our organization.
I had the exact same issue and after trying a lot of approaches, landed on the solution below (++):
Create a group in Google Workspace. You can add any external identity/email to a group, since they can be used for multiple things. So add the role account to this group.
Google has recently come out with "Trust" rules, that allow granular sharing. You can share with a group. So I created a trust rule that allowed sharing of any data source (easier than restricting who can share since file/shared drive ownership affects this rule) to only the group that contains the service account. Now external sharing is permitted, but only to the role account.
Lastly, share the drive with that role account.
++ Note that I also had followed the majority of steps above including the GCP project creation and domain-wide delegation before this portion, but was similarly stuck getting a 403 for access rights.
I was able to create a project to connect an app to google data, for a specific account (followed Google People API)
But now I would like that each customer log in hisself to his account and manage his data.
I can' t create project in the Google API Console for each customer, my app needs to read auth from each user who will use my app and "auto" create auth to read google contact data of the logged user.
Is possible?
Could you suggest me articles about how to do?
It sounds like you are trying to do exactly what OAuth 2.0 (see the page you linked to) gives you: authenticating users. This differs from using an API key, which is only authorizing your project and has nothing to do with a user's credentials.
OAuth 2.0 combines a Client ID (associated with your Google Developers Console project) and a user's login (specific to the user who is accessing your app/site) to give you an authorization token. This token will let your app act on behalf of that user when calling that API. Just make sure to request the necessary scopes as part of the OAuth 2.0 authorization prompt given to the user.
How to give this prompt varies by environment, but many common options are listed on that link.
Note that you always use the same Client ID, so you only need one Google Developers Console project, but you are given a unique token specific to that user's login when they authorize your app, so this lets you act as any user which grants your app access to their account.
I have read all the information and guidance and watched the videos on
Developers Google Drive (sorry, I do not have enough "reputation points" to include all the links that would be relevant here).
as well as Google Privacy Policies.
In the list of Google Drive auth scopes, which ones are covered by the permissions request to users for the app to "view basic account information"?
https://developers.google.com/drive/scopes
I can only find examples, rather than a complete list.
I am also trying to understand how this relates to the Privacy Policy, ie. whether this "basic account information" is "Personal Information" or "Google Account" information.
http://www.google.com/intl/en-GB/policies/privacy/key-terms/#toc-terms-personal-info
Personal information
This is information which you provide to us which personally
identifies you, such as your name, email address or billing
information, or other data which can be reasonably linked to such
information by Google.
Google Account
You may access some of our services by signing up for a Google Account
and providing us with some personal information (typically, your name,
email address and a password). This account information will be used
to authenticate you when you access Google services and protect your
account from unauthorised access by others. You can edit or terminate
your account at any time through your Google Account settings.
I have read elsewhere that the "basic account information" is not actually "viewed", ie. visible to, the app developer but is instead transmitted in encrypted form for use by the app.
(I am not an app developer - this just seems to be the only place where there are Google staff watching and answering these sorts of questions).
User's profile and email is available if you grant access for the following scopes:
profile: https://www.googleapis.com/auth/userinfo.profile
email: https://www.googleapis.com/auth/userinfo.email
Profile stands for a Google Account and contains user's ID, name, photo, URL, country, language, timezone, and birthdate.
I'm looking for a way to impersonate users of a google app domain using a admin user. I could do it easily with google data document list api but I cant find a way to do it with the new Drive API.
Precisely, what I want to do is authenticate my admin user using Oauth2 (i've already done this), retrieve a list of the users of my domain and then impersonate my users, or at least be able to access files and docs from the Drive of those users.
In the administrative panel of google apps, there are Oauth consumer key and Oauth consumer secret, but these are used in Oauth1 2LO, not Oauth2.
Is there a proper way/workaround/hack to implement what I want ?
Best regards,
Jérôme
I've only been looking at the google-api-ruby-client as an example but you should be able to do this with a service account that is permitted access through the admin panel -> Advanced tools -> manage third party oauath clients. Once permitted you can follow the example for a service account here http://code.google.com/p/google-api-ruby-client/source/browse/service_account/analytics.rb?repo=samples but instead of authorizing with
client.authorization = asserter.authorize()
you can use
client.authorization = asserter.authorize("id#domain.com")
I haven't done a lot with this yet but after authenticating in this method I've been able to list all documents owned by a user on my domain.
Thanks to James Woodward, i've been able to impersonate user. I post an answer to provide Java specific details.
Create a service account in the API console. 3 important resources are created :
Client ID : used to authorize the app on the Google Apps domain
Email address : used to authorize the requests of the app
.p12 key file : used to authorize the requests of the app
Authorize the app on the Google Apps Administrative panel, providing it with Service account client ID, and all the scopes the app will need.
Create GoogleCredential this way :
GoogleCredential serviceCred = new GoogleCredential.Builder().setTransport(HTTP_TRANSPORT)
.setJsonFactory(JSON_FACTORY)
.setServiceAccountId(SERVICE_ID)
.setServiceAccountScopes(Arrays.asList(SCOPES))
.setServiceAccountUser("impersonated.user#domain.com")
.setServiceAccountPrivateKeyFromP12File("key.p12")
.build();
Those credentials can now be used to authenticate the requests made by the app on any scope authorized.