4

I have been working on a server to server google calendar integration, where by it connects, reads and writes to a user's calendar.

This is working perfectly fine, however I have a question regarding permission scope. Using a service account with domain wide delegation, it means that this account has access to calendars for every single users in the organisation from the CEO to me...

Is there a way of limiting this scope from Google's side, so that the service account can only access specific accounts, similarly to how EWS allows delegation rules.

One idea I had was to create a separate organisational unit and create the project under that (not tested this theory, but it also doesn't feel very scaleable).

Any ideas?

Thanks

Vade
  • 2,009
  • 6
  • 24
  • 32

2 Answers2

0

The service account only has access to whatever is shared with the account, as per Delegating domain-wide authority to the service account:

an administrator of the G Suite domain can authorize an application to access user data on behalf of users in the G Suite domain

This means that the service account only has access to data from the account the application is impersonating.

In your case, using Org Units would not fulfill your requirements.

These controls have to be implemented on the application level. AKA by you.

One of the ways you could do this is, before impersonating any account, use the service account to query which Org Unit that account belongs to, and then based on that allow or deny the impersonation.

Of course, you can also do this type of filtering in multiple ways. You could simply check if the account you wish to impersonate is on a blacklist and abort the impersonation if that's the case, or you could use other criteria.

Hope this helps!

ZektorH
  • 2,680
  • 1
  • 7
  • 20
Kessy
  • 1,894
  • 1
  • 8
  • 15
  • 4
    I think the problem is: You generate a service account with some sort of credentials to use this service account. If your server-side app uses this key to specify which user it wants to impersonate, you have a problem if the server is hacked as the code can be changed to impersonate any other domain-wide user, too. – hb0 Feb 14 '22 at 10:12
0

First and foremost: A service account is technically a superadministrator once DWD (domain wide delegation) is enabled and the client ID authorized by any admin in the Admin Console.

That translates to: a service account can impersonate any user including any administrator and performing any action allowed by the declared scopes.

In this case: A service account with allowed scope https://www.googleapis.com/auth/calendar.readonly can read any domains calendar.

Now there's a somewhat nasty workaround: A service account is basically a gmail account without access to the web UI. So you can indeed share a calendar with a service account if and only if external calendar sharing is enabled. Then you do not use DWD. In this case the service account can only act as the sharing permissions dictate. However this is not how a service account is supposed to be used.

Gilfoyle
  • 1
  • 2