Ограничить делегирование всего домена указанными почтовыми ящиками c

Question

Я работал над интеграцией календаря Google между серверами, где он подключается, читает и записывает в календарь пользователя.

Это работает отлично, однако у меня есть вопрос, касающийся области разрешений. Использование служебной учетной записи с делегированием по всему домену означает, что эта учетная запись имеет доступ к календарям для каждого отдельного пользователя в организации от генерального директора до меня ...

Есть ли способ ограничения этой области со стороны Google , так что учетная запись службы может получать доступ только к указанным c учетным записям, аналогично тому, как EWS разрешает правила делегирования.

У меня была одна идея - создать отдельную организационную единицу и создать проект под этим (не проверял это теория, но она также не выглядит масштабируемой).

Есть идеи?

Спасибо

Answer 1

Прежде всего: служебная учетная запись технически становится суперадминистратором после включения DWD (делегирование по всему домену) и идентификатора клиента, авторизованного любым администратором в консоли администратора.

Это означает: учетная запись службы может выдавать себя за любого пользователя, включая любого администратора, и выполняет любые действия, разрешенные объявленными областями.

В этом случае: учетная запись службы с допустимой областью действия https://www.googleapis.com/auth/calendar.readonly может читать календарь любого домена.

Теперь есть несколько неприятных решений: сервисная учетная запись - это, в основном, учетная запись gmail без доступа к веб-интерфейсу. Таким образом, вы действительно можете совместно использовать календарь с учетной записью службы, если и только если включен внешний общий доступ к календарю. Тогда вы не используете DWD. В этом случае служебная учетная запись может действовать только как разрешение на совместное использование. Однако это не то, как сервисная учетная запись должна использоваться.

Answer 2

Учетная запись службы имеет доступ только к тому, что используется совместно с учетной записью, в соответствии с Передача полномочий на уровне домена для учетной записи службы :

администратору G Suite. домен может авторизовать приложение для доступа к пользовательским данным от имени пользователей в домене G Suite

. Это означает, что учетная запись службы только имеет доступ к данным из учетной записи приложения. олицетворение.

В вашем случае использование Org Units не будет соответствовать вашим требованиям.

Эти элементы управления должны быть реализованы на уровне приложения. AKA вами.

Один из способов, которым вы могли бы сделать это, перед тем, как выдавать себя за любую учетную запись, использовать служебную учетную запись для запроса, к какому подразделению организации принадлежит эта учетная запись, а затем на основе этого разрешить или запретить олицетворение.

Конечно, вы можете выполнять этот тип фильтрации несколькими способами. Вы можете просто проверить, есть ли учетная запись, которую вы олицетворяете, в черном списке, и отменить олицетворение, если это так, или использовать другие критерии.

Надеюсь, это поможет!