3

Applications in GSuite can have domain-wide delegation (DWD) enabled, allowing the application to access user data (and other domain data) without any interaction on the part of the users.

According to a Google Support article, it is implied that the application is limited by the scopes set on the application.

However, reading various responses on Stack Exchange regarding "user impersonation" makes me wonder about the validity of this. See:

  • Breno's response "The domain-wide delegation model allows a service account to impersonate a user and thus obtain the same privileges in the domain that the user identity + set of scopes granted to the application imply."
  • Kessy's and Gilfoyle's responses "...This means that the service account only has access to data from the account the application is impersonating...." and "...First and foremost: A service account is technically a superadministrator once DWD ..."
  • Edited question ("Solution")

There is nothing concrete, but it appears (possibly incorrectly) that once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed. I've trawled through the Google Support documentation, but there is very little about scopes with regards to impersonating users that I could find. I haven't the experience building such an application to know what to look for.

My questions:

(Q) Can applications with DWD enabled do more than the scopes allow by impersonating a superadmin? If not, if one of those scopes includes the authority to change the user password (e.g. https://www.googleapis.com/auth/admin.directory.user), doesn't that mean an application can bootstrap itself and add any other, needed scopes?

Alternatively, are applications with DWD limited by their scopes, even when impersonating a super admin?

I'm not a developer; I'm a system admin with very some light/informal dev experience, so I would be greatly appreciative if you could pitch your answers accordingly.

ziganotschka
  • 25,866
  • 2
  • 16
  • 33
Paul
  • 887
  • 6
  • 22

1 Answers1

2

The privelleges that an impersonated account has are limited in two ways

  1. The impersonation can only perform requests on user's behalf within the range of the scopes authorized in the Admin consoles under Security -> API controls
  2. A certain application can only use the scopes that were given to the service account when creating a credentials object

In other words:

  • If you enable in the admin console e.g. the scope https://www.googleapis.com/auth/admin.directory.user.readonly for a specific service account, this service account - when impersonated - will only be able to VIEW users, not to perform any request what goes beyond the limits of https://www.googleapis.com/auth/admin.directory.user.readonly
  • Even if you enable the full https://www.googleapis.com/auth/admin.directory.user scope in the admin console, but when creating the service account credentials object, you pass it only https://www.googleapis.com/auth/admin.directory.user.readonly as a scope - within the frame of the specific application, the service account equally will not be able to perform requests going beyond the scope https://www.googleapis.com/auth/admin.directory.user.readonly

The assumption once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed is confusing.

It would be more correct to say once an application impersonates the "right" user with sufficient admin privileges, any required data can be accessed - IF THE RESPECTIVE SCOPES HAVE BEEN ENABLED IN THE ADMIN CONSOLE AND GRANTED TO THE SERVICE ACCOUNT CREDENTIALS OBJECT OF THE SPECIFIC APPLICATION.

  • As a general rule of thumb, you should avoid providing (both when working with and without service account) to generous scopes, it is better to provide several specific scopes, rather than one broad scope.
ziganotschka
  • 25,866
  • 2
  • 16
  • 33
  • Thank you for the clear and comprehensive answer. I'm unsure about the last part about using the API to change passwords, however: We have had at least two integrations against our Google domain that do exactly that i.e. push new passwords for Google users as part of some other service. If we can clarify that, then I'll accept the answer as complete. – Paul Oct 19 '20 at 13:47
  • Are you refering to adding new users with predefined passwords, prompting existing users to change their password or changing programmatically the password of already existing users? – ziganotschka Oct 19 '20 at 13:50
  • Programmatically changing the passwords of existing users (which can be configured to prompt them if desired) – Paul Oct 19 '20 at 14:00
  • See https://developers.google.com/admin-sdk/directory/v1/reference/users/update and the "password" field which I believe is writable. – Paul Oct 19 '20 at 14:02
  • 1
    I doublechecked and must say you are right, I believe in the past it was not possible to change a user's password via API, this is why I provided you this erroneous information. I will remove it from my answer. However, as for the rest - that is the apllication only being able to perform only requests for which the scopes have been granted - this is correct. – ziganotschka Oct 19 '20 at 14:10
  • 1
    Great, thanks. I can see the answer is updated and, as far as I can tell, complete, so I've marked it as such. Just a last question: Do you have a reference that could be added to the answer, such as a Google support page etc.? – Paul Oct 19 '20 at 14:30
  • 1
    It might not be very clear, but the information can be drawn from https://developers.google.com/admin-sdk/directory/v1/guides/delegation and https://developers.google.com/admin-sdk/directory/v1/guides/authorizing. – ziganotschka Oct 19 '20 at 21:23