Google Admin SDK с сервисным аккаунтом без олицетворения - PullRequest
0 голосов
/ 05 марта 2020

Цель состоит в том, чтобы установить sh Сервисную учетную запись на платформе G-Suite, которую приложение может использовать для выполнения действий без запроса аутентификации пользователей.

У нас возникают проблемы, очень похожие на следующие сообщения , но немного по-другому.

Пока мы следуем потоку «олицетворения», все работает. С олицетворением правила авторизации следуют за олицетворением пользователя. В идеале, мы хотим соответствующим образом ИЗМЕНИТЬ учетную запись службы, а не олицетворять пользователь. Когда мы делаем это, мы постоянно получаем 403.

Мы старались изо всех сил следовать инструкциям здесь:

Наши Фрагмент Java похож на этот:

    final NetHttpTransport HTTP_TRANSPORT = GoogleNetHttpTransport.newTrustedTransport();

    File file = new File(MdmResource.class.getClassLoader().getResource("myproject.p12").getFile());

    GoogleCredential credential = new GoogleCredential.Builder()
        .setTransport(HTTP_TRANSPORT)
        .setJsonFactory(JSON_FACTORY)
        .setServiceAccountId("105601508644514129999")
        .setServiceAccountPrivateKeyFromP12File(file)
        .setServiceAccountScopes(
             Collections.singletonList(DirectoryScopes.ADMIN_DIRECTORY_USER_READONLY))
        .setServiceAccountUser("user@domain.com")  // 403 when this is commented out
        .build();

    Directory dir = new Directory(HTTP_TRANSPORT, JSON_FACTORY, credential);
    Get result = dir.users().get("dude@domain.com");
    User user = result.execute();
    System.out.println(user.get("customerId"));

В GCP мы создали ServiceAccount, в то время как вошли в систему как суперадмин. Мы включили делегирование по всему домену и сгенерировали ключи (в данном примере это тип p12 и использовали соответствующий файл в качестве ввода в приложение Java).

Затем в Библиотеке API мы включили Admin SDK .

В Google Admin в разделе Настройки безопасности / Дополнительные настройки мы настраиваем области действия. Мы использовали 105601508644514129999 и https://www.googleapis.com/auth/admin.directory.device.mobile, https://www.googleapis.com/auth/admin.directory.user.readonly, https://www.googleapis.com/auth/admin.directory.user

Когда мы запускаем код Java, мы видим следующее, когда "setServiceAccountUser" закомментирован (работает нормально при олицетворении, пока у пользователя есть необходимые разрешения):

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Not Authorized to access this resource/api",
    "reason" : "forbidden"
  } ],
  "message" : "Not Authorized to access this resource/api"
}

Итак, похоже, что наш SA неправильно подключен к областям, но у меня нет идей, как это сделать.

Кстати, 105601508644514129999 является уникальным идентификатором SA и идентификатором клиента учетных данных OAuth 2.0, которые были автоматически сгенерированы в процессе создания SA. Мы также использовали электронную почту SA для «setServiceAccountId», как показано в следующем примере, но все равно получали 403. https://developers.google.com/admin-sdk/directory/v1/guides/delegation. На самом деле, я думаю, что в этом примере есть и другая проблема с .setServiceAccountScopes.

Наконец ...

        <dependency>
            <groupId>com.google.auth</groupId>
            <artifactId>google-auth-library-oauth2-http</artifactId>
            <version>0.20.0</version>
        </dependency>

        <!-- Used to navigate Google Directory services, like https://developers.google.com/admin-sdk/directory -->
        <dependency>
            <groupId>com.google.apis</groupId>
            <artifactId>google-api-services-admin-directory</artifactId>
            <version>directory_v1-rev117-1.25.0</version>
        </dependency>

Есть мысли?

1 Ответ

0 голосов
/ 07 марта 2020

Сервисные учетные записи не находятся в домене G Suite (даже если они принадлежат пользователю / проекту в нем) и, следовательно, им не может быть предоставлен административный доступ к домену G Suite. Все, что они могут сделать, - выдать себя за пользователей в домене с помощью делегирования по всему домену.

То, что вы, вероятно, хотите решить, - это предоставление обычного OAuth в качестве пользователя-администратора с использованием идентификатора клиента и секрета, а также уверенности, что вы получите длинный refre sh токен access_type=offline. Это позволит вам обновлять sh токен доступа каждый раз, когда он истекает, и продолжать действовать как отдельный администратор, если он не аннулирует ваш доступ.

...