Можно ли аутентифицироваться как пользователь Google внутри приложения, размещенного на gcloud, с использованием IAM?
Предположим, у меня есть приложение, размещенное в облаке Google: Frontend и Backend. Требование заключается в том, что приложение может использоваться только пользователями в определенной группе или с определенной ролью и т. Д. В рамках определенной организации Google (к которой принадлежит проект, содержащий приложение).
Я думал о реализации этого так:
1) Веб-интерфейс потребует от пользователя входа в свою учетную запись Google (которую я предполагаю привязать к организации Google Cloud), используя Google в качестве стороннего аутентификатора. Поскольку приложение построено с использованием узла /javascript, это легко сделать с некоторыми npm пакет, такой как passport, После того, как пользователь войдет в браузер и произойдут определенные перенаправления, Google должен предоставить бэкэнду информацию о пользователе, включая уникальный идентификатор.
2) Бэкэнд (работающий на движке приложений, вычислительном движке и т. Д. Не должен иметь значения) должен обращаться к специфическому API Google Cloud, который должен идентифицировать пользователя и принадлежать ли пользователю группе или организации, в основном всему, что помог бы. Предполагается, что у машины будет служебная учетная запись со всеми необходимыми ролями для доступа к указанным API-интерфейсам и определения, в порядке ли пользователь.
3) Если пользователь в порядке, то для пользователя будет создан сеанс в бэкэнде, и пока этот сеанс живет, бэкэнд будет знать идентичность запросов, поэтому все должно быть в порядке.
Проблема, с которой я столкнулся, лежит на шаге 2: просматривая весь Google IAM, API, видео с документацией и т. Д. Я не смог найти никакого способа а) идентифицировать пользователя на основе уникального идентификатора и б) проверить, что либо Пользователь является частью группы (через отдельный ресурс членства или иным образом) или, если ему назначена определенная роль, что было бы эквивалентно моему варианту использования.
Любая идея, если:
1) мой подход имеет смысл, и это даже возможно?
2) если да, то какие ресурсы или методы мне следует использовать, чтобы это произошло?
3) если нет, то какой подход подходит для моего варианта использования?
1 ответ
Ключевой вопрос: кто будет вашим провайдером идентификации?
Следующий ключевой вопрос заключается в том, как сопоставить личность пользователя из Identity Provider с вашей собственной базой данных пользователей / привилегий.
Следующий ключевой вопрос для вас - какой тип OAuth 2.0 использовать. Неявный OAuth или 3-х сторонний OAuth. Неявный OAuth выполняется в браузере и включает только идентификатор клиента. Трехсторонний протокол OAuth включает веб-сервер для получения токенов и считается более безопасным.
1) Веб-интерфейс потребует от пользователя входа в свою учетную запись Google (которую я предполагаю привязать к организации Google Cloud), используя Google в качестве стороннего аутентификатора. Поскольку приложение построено с использованием узла /javascript, это легко сделать с помощью некоторого пакета npm, например, паспорта. После того, как пользователь войдет в браузер и произойдут определенные перенаправления, Google должен предоставить бэкэнду информацию о пользователе, включая уникальный идентификатор.
Вы можете использовать любой провайдер идентификации (Google, Facebook, Auth0, Okta и т. Д.). (Примечание: см. Мой комментарий ниже о Google IAM). Реализация OAuth в браузере настолько проста, что вам действительно не нужна библиотека. Однако, если вы хотите использовать библиотеку, есть из чего выбирать. Однако выберите библиотеку, которая является собственным JavaScript, а не пакетом узлов. Пакеты узлов обычно создают огромные файлы, которые пользователи должны загружать.
После завершения потока OAuth у вас будет два токена. Токен доступа и идентификационный токен. Идентификационный токен - это то, что ваш клиентский интерфейс JavaScript будет включать в запросы. Я игнорирую токен доступа в этом ответе, но его можно использовать для прямого доступа к сервисам GCP, таким как Google Storage, если он правильно настроен на этапе аутентификации. Для этого ответа я предполагаю, что вы хотите личность пользователя.
2) Бэкэнд (работающий на движке приложений, вычислительном движке и т. Д. Не должен иметь значения) должен обращаться к специфическому API Google Cloud, который должен идентифицировать пользователя и принадлежать ли пользователю группе или организации, в основном всему, что помог бы. Предполагается, что у машины будет служебная учетная запись со всеми необходимыми ролями для доступа к указанным API-интерфейсам и определения, в порядке ли пользователь.
Браузер на стороне клиента будет включать маркер идентификатора в заголовок HTTP, скрытое поле формы, состояние сеанса и т. Д. При взаимодействии с вашими службами. Для проверки идентификационного токена вы вызываете конечную точку, относящуюся к провайдеру идентификации. Для Google конечная точка: https://www.googleapis.com/oauth2/v3/tokeninfoдля Auth0 это: https://<replace_with_your_account_name>.auth0.com/userinfo, Обе эти конечные точки проверяют целостность идентификатора токена. Идентификационный токен содержит сведения о пользователе, которого пользователь разрешил вам просматривать. Идентификационный токен, который является JWT, выглядит следующим образом при декодировании для Google:
iss: https://accounts.google.com
azp: <removed_for_security>.apps.googleusercontent.com
aud: <removed_for_security>.apps.googleusercontent.com
sub: <removed_for_security>
hd: example.com
email: username@example.com.com
email_verified: true
at_hash: 63I_abcdefabcdefbi5NSw
nonce: e8TP-uLoEoeXpbk5
name: User Name
picture: https://lh3.googleusercontent.com/-9PtQwhKbOPc/AAAAAAAAAAI/AAAAAAAAAAA/<removed_for_security>/s96-c/photo.jpg
given_name: User
family_name: Name
locale: en
iat: 1548357229
exp: 1548360829
jti: <removed_for_security>
Ваш бэкэнд будет обязан сопоставлять личность пользователя с любыми привилегиями, которые вы хотите. Вы можете использовать базу данных и т. Д. Для хранения этой информации. Если пользователь также является пользователем Google IAM, вы можете создавать учетные данные с коротким сроком действия на основе привилегий IAM, хранящихся в Google IAM. Однако я рекомендую это только в тех случаях, когда у вас всего несколько пользователей. Для сотен или тысяч пользователей не используйте Google IAM, вместо этого управляйте этим с помощью своего поставщика удостоверений через настраиваемые утверждения или в собственной настраиваемой базе данных.
3) Если пользователь в порядке, то для пользователя будет создан сеанс в бэкэнде, и пока этот сеанс живет, бэкэнд будет знать идентичность запросов, поэтому все должно быть в порядке.
Я не уверен, что вы пытаетесь сказать здесь. Для Google Cloud ваш бэкэнд будет либо делать запросы от имени клиента, используя свою учетную запись службы, либо бэкэнд создаст токен недолгого доступа, который предоставляет доступ.
1) мой подход имеет смысл, и это даже возможно?
Ваш подход очень близок к тому, как это должно быть сделано. Есть некоторые тонкие детали, которые вы еще не поняли, и я надеюсь, что мои ответы укажут вам правильное направление для дальнейших исследований.
2) если да, то какие ресурсы или методы мне следует использовать, чтобы это произошло?
- Определите тип OAuth, который вы будете реализовывать (неявный или трехсторонний).
- Выберите поставщика удостоверений. Google, Facebook, Auth0 и т. Д.
- Определился с типом кода, который вы будете вставлять в браузер (простой JavaScript или библиотека).
- Решите, как вы будете передавать токены через HTTP-заголовки, скрытые поля формы и т. Д.
- Решите, как вы будете авторизовать запросы. Ваша собственная учетная запись службы или краткосрочные токены доступа, созданные для каждого пользователя.
- Решите, как вы будете переводить удостоверение личности токена в ваш набор разрешений.
3) если нет, то какой подход подходит для моего варианта использования?
Ваш подход хорош и типичен для того, что мы делаем в реальном мире.