Выдавать себя за текущего пользователя при вызове API Google с использованием служебной учетной записи и делегирования полномочий

Существует требование Marketplace: если домен Google Apps for Work администратор устанавливает наше приложение для своего домена, после этого администратор и любые пользователи из своего домена не должны видеть экран аутентификации области при доступе к нашему приложению. Действие установки приложения для домена должно неявно делегировать полномочия на уровне домена для служебной учетной записи, связанной с нашим приложением.

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

Фрагмент кода ниже показывает различные попытки заставить это работать. Единственное, что работает, — это передать адрес электронной почты суперпользователя домена в качестве параметра «sub» (AKA prn) при создании JWT. Однако это, по сути, повышает привилегии обычного пользователя домена до уровня суперпользователя, что не является желаемым эффектом.

var client = new googleapis.auth.JWT(
    '<serviceaccount>@developer.gserviceaccount.com',
    'localhost.pem',
    null,
    ["https://www.googleapis.com/auth/admin.directory.user.readonly"],
    //  null - // 403 not auth
    // {'userId' : '[email protected]'} // 403 not auth
    // {'userId' : 'me'} // 403 not auth
    // "[email protected]" // works!
    // "{[email protected]}" // not a valid email error
    // 'me' // invalid impersonation prn email address
  );

Принимает ли Google какой-либо другой идентификатор, кроме адреса электронной почты человека, которого вы хотите выдать за другого, например специальное значение «я»?

Такое ощущение, что мы сталкиваемся здесь с проблемой курицы и яйца. По сути, мы не хотим жестко кодировать адрес электронной почты (особенно адрес электронной почты администратора), поэтому создается впечатление, что мы должны сделать вызов API. Но мы не можем сделать вызов API, не выдавая себя за пользователя.


person Chris Beiter    schedule 22.10.2014    source источник


Ответы (1)


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

Когда администратор устанавливает приложение и утверждает ваши области, он, по сути, автоматически предоставляет вам доступ к этим областям для всех пользователей в домене. И хотя требуется, чтобы пользователи не видели экран утверждения, вам все равно придется пройти с ними через поток OAuth2, чтобы получить токен OAuth2. Если вы запускаете поток OAuth2 для пользователя и не запрашиваете какие-либо области, еще не одобренные администратором домена, и не устанавливаете approval_prompt=force в URL-адресе, то экран утверждения OAuth2 мгновенно перенаправляется на ваш URI перенаправления, делая процесс невидимым для пользователя.

person Eric Koleda    schedule 23.10.2014
comment
Привет Эрик, спасибо за ответ. Это будет работать для новых установок нашего приложения, но для любых существующих установок потребуется, чтобы администратор организации Google вручную добавил эти области. Есть ли у них способ добавить области к доступу существующего клиента API? Пробовал здесь, но при попытке обновить не получается: admin.google.com /AdminHome?chromeless=1#OGX:ManageOauthClients - person Chris Beiter; 24.10.2014
comment
Выполнение делегирования полномочий для домена было единственным способом, который мы могли придумать, чтобы исключить запросы области действия для наших существующих пользователей. - person Chris Beiter; 24.10.2014
comment
Расширение областей, которые использует ваше приложение, сегодня не самое приятное занятие. После того как вы обновите конфигурацию Apps Marketplace с новыми областями, администратор должен увидеть параметр в консоли администратора для повторной авторизации вашего приложения (им не нужно добавлять области вручную). Однако до тех пор, пока они этого не сделают, пользователи увидят запрос авторизации с запросом на новые области. Однако это нормально и не должно влиять на ваш существующий список. Однако обычно рекомендуется либо отправить электронное письмо администраторам, либо показать панель предупреждения в приложении, уведомляющую их о необходимости повторной аутентификации. - person Eric Koleda; 24.10.2014
comment
Еще раз спасибо Эрик. Я думаю, что мы разобрались с большинством прицелов, но теперь вместо экрана прицелов мы видим этот новый (для нас) экран с выбором людей. Это тоже ожидается? Экран одобрен администратором - person Chris Beiter; 24.10.2014
comment
Вы используете мульти-логин? Если это так, это может отображаться в первый раз. - person Eric Koleda; 24.10.2014
comment
Вы имеете в виду множественный вход в Chrome с использованием профилей? Да, но я пробовал это также из Safari, Firefox и в приватных окнах и получаю то же самое приглашение. - person Chris Beiter; 24.10.2014
comment
Странный. Можете ли вы опубликовать обработанную версию URL-адреса авторизации OAuth2, на который вы их перенаправляете? - person Eric Koleda; 25.10.2014
comment
Еще раз привет, Эрик, вот URL-адрес авторизации из наших локальных сред. accounts.google.com/o/oauth2/> - person Chris Beiter; 27.10.2014
comment
Все выглядит нормально. У вас появляется этот экран при каждом входе в систему или только при первом? - person Eric Koleda; 28.10.2014
comment
Мы получаем этот экран только при первом входе в систему при аутентификации с помощью нашего кода приложения. Однако после того, как пользователь нажимает на средство выбора людей и Google отправляет его обратно в наше приложение с необходимыми токенами, мы перенаправляем пользователя в нашу частную службу аутентификации, которая должна получить токен аутентификации, который мы уже получили от Google. Но по какой-то причине он не находит его, поэтому выполняет другое перенаправление обратно в Google. Именно это второе перенаправление приводит к тому, что экран выбора людей продолжает отображаться. Так что я думаю, на данный момент это моя проблема, чтобы выяснить. - person Chris Beiter; 29.10.2014