During the process of creating a service account to access Gmail API, I found that Domain wide delegation to the service account is required. But, this will allow the service account to access all the mailboxes in the domain. Is it possible to put some restriction on the service account so that it can access only certain mailbox/mailboxes.
I couldn't find any workaround to put some restriction on the service account. I am expecting a way to put some mailbox reading restrictions on the service account.
When you configure domain wide deligation you will need to also configure the user on the domain that the service account will be allowed to impersonate.
Then in your code you will need to supply the email address of that user in the domain.
The service account will then be able to run as that user sending emails from that users account and reading emails from it.
it can only access accounts it has been configured to access
Related
I want to create ticket in our system when somebody sends email to support#mydomain.com. I'm using GmailAPI to read new messages from that gmail account.
Currently I'm using service account and domain wide delegation (DWD) for authentication.
The problem is that with DWD I can access all user accounts from my organization and this is what I want to avoid.
Is it possible configure service account this way, so that it has access to only one user account? Or can I generate and use private key for single user account instead of service account with DWD?
I have a client email that ends with .gserviceaccount.com. I was told I have to share this email with my google sheets. I cant however. It says that it cannot share sheets to emails outside of the organization. Is there another way to connect to my Google sheets besides sharing with the client email?
You could change your sheet's sharing settings, and share it to anyone with the link. Then give the link to the user with a service account that's not in your organization.
However, your organization's admin might have your sharing settings restricted to only users within your org.
Note that: A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
Further reading:
What are service accounts ?
Differences between a service account and a user account
I want to aggregate my clients' ad account into my business account automatically.
The client is already logged in via oauth2 process in my website and grant the permissions, ["ads_read", "ads_management", "manage_pages"].
I'm succeeded to request access for the client using the endpoint POST /<business_id>/client_ad_accounts.
Request image in the client Ad account setting page:
And, There is a problem.
I want to accept this request programmatically using the client's ACCESS_TOKEN.
POST /act_<client_ad_account_id>/agencies
-d "business=<my_business_id>&access_token=<client_access_token>"
But, I have a error message (#10) Ad account <client_ad_account_id> must be managed by a business account to approve agency access.
Is it possible to accept this request programmatically? If that's possible, what should I do?
self answer: Connect client page to the client's business account and add permission business_management. Then, everything works fine.
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.
I am trying out Office 365 Rest APIs.
I have registered application with Azure AD.
It has following permission set: Exchange: Access All User's Mailbox, Full Control on User's Calendar, Full Control on User's Contacts, Full Control on User's Mailbox
I have generated access token with admin grant which has global admin privileges.
Sent following request 'https://outlook.office365.com/api/users/me/messages' which resulted in correct results giving me all messages in current admin's mailbox
Sent following request 'https://outlook.office365.com/api/users/{another user's email}/messages'. This resulted in following error
"u'error': {u'message': u'Access is denied. Check credentials and try again.', u'code': u'ErrorAccessDenied'}}"
Please let me know if above steps are wrong ?
If they are wrong, is there a way to fetch emails from another user's mailbox as I have admin credentials ?
Thanks.
You need to use a service account as described in this blog, for your scenario and the app will be able to make calls to interact with any mailboxes in that tenant. The reason your request to use another user's mailbox is failing is because the request will be approved only if the app and user have permissions to access the other user's mailbox. In your case, the admin has permissions to the other user's mailbox. But the app, assuming you used OAuth code flow, to get the OAuth token, only has permissions to the authenticated user's mailbox.
Also, you don't need "Access All User's Mailbox" permissions for REST APIs, as they are meant for using Exchange Web Services (EWS) SOAP APIs.
If someone is looking for the solution, it was a problem of service principal.
We were pointing to the wrong Service Principal and that was the cause of the issues with permissions.