Как управлять или отменять области в процессе OID C? Пользователь не должен разрешать соответствующий доступ; Это должно быть установлено ИТ-администраторами организации, которые создали пользователя
Разрешения для членов IAM (пользователей, групп, учетных записей служб и т. д. c) управляются в Google Cloud IAM. Области используются с OAuth для ограничения разрешений, уже назначенных IAM. Лучшие практики означают назначение необходимых разрешений (и не более) и не расчесывание IAM с областями действия.
Могут ли ИТ-администраторы G Suite применять параметры для пользователей (настраиваемые и / или нет), которые автоматически выделяют предопределенные "Google Группы / роли политики Identity / IAM?
G Suite и Google Cloud являются отдельными службами. Google Cloud поддерживает G Suite в качестве поставщика удостоверений (IDP). Разрешения контролируются в Google Cloud IAM, а не в G Suite. Вы можете объединить G Suite с группами Google, чтобы объединить членов IAM в группы для более удобного управления IAM.
Будут ли пользователи G Suite, подписавшие JWT / Google ID, напрямую совместимы с конечными точками + IAP (не требуя обработки) / перекодировка)?
Учетные записи Google (G Suite) не предоставляют закрытые ключи для своих учетных записей. Поэтому вы не можете использовать подписанные JWT. Подписанный JWT является более старым механизмом авторизации и используется с учетными записями служб. Правильный метод для учетных данных пользователя - это токены доступа и идентификации OAuth 2.0. Для администраторов могут использоваться учетные записи служб с делегированием по всему домену.
Будет ли этот подход охватывать внешних пользователей с помощью подхода федеративной идентификации в будущем без существенных рефакторингов для существующего процесса (например, аутентификации Firebase)?
Это сложный вопрос. Google Cloud поддерживает внешних провайдеров идентификации, но я обнаружил, что это в лучшем случае проблематично c. Вы также можете использовать идентификацию синхронизации, но это также не очень хорошо реализовано. Если вы едете по маршруту Google Cloud, используйте G Suite в качестве поставщика удостоверений и Google Cloud IAM для авторизации.
Важным моментом, который, по моему мнению, не хватает в вашем вопросе, является понимание того, как работает авторизация в Google Cloud и API Google. Эти сервисы в основном используют OAuth 2 Access Tokens и Identity Tokens. Это зависит от услуги и типа требуемого доступа. Это означает, что ваше приложение должно понимать, к каким сервисам оно обращается, и как предоставлять авторизацию. У меня такое ощущение, что вы ожидаете, что Firebase / конечные точки сделают это за вас.
Еще один момент заключается в том, что Firebase является частью Google Cloud и является лишь подмножеством Google Cloud. Firebase - это отличный продукт / услуга, но если вы планируете использовать функции Google Cloud вне Firebase, оставайтесь с G Suite и Cloud IAM для идентификации и авторизации.
Angular SPA будет один GUI для приложения, размещенного в том же домене, который зарегистрирован для организации в GCP / G Suite
Я предполагаю, что под доменом подразумевается зона DNS (DNS-имена веб-сайтов). Это облегчит управление CORS и Cook ie, но это не является обязательным требованием.
SPA будет использовать API-шлюз GCP (конечные точки) для выполнения запросов к микро-сервисам GKE (вероятно, все в пределах одного VP). C) и другие сервисы G Suite (Drive, et c)
ОК - я не вижу проблем с использованием конечных точек. Тем не менее, хороший ответ требует подробностей о том, как на самом деле все реализовано. Другое дело, что вы упоминаете конечные точки и сервисы G Suite. Это очень разные предметы. Конечные точки защищают ваши конечные точки HTTP, а не другие службы Google, где это будет мешать.
Администраторы Org IT G Suite могут создавать пользователей и назначать различные (предопределенные) группы / области политики IAM через G Suite Пользовательский интерфейс для предоставления пользователям наименьших привилегий доступа к ресурсам организации (службы G Suite и пользовательские API / приложения, размещенные на GCP)
Авторизация Google Cloud IAM и G Suite - это отдельные системы авторизации. Чтобы участники G Suite могли управлять Google Cloud IAM, им потребуются роли, назначенные в Google Cloud IAM через их идентификатор участника или членство в группе. Нет общих разрешений для авторизации.
Пользователи имеют возможность ТОЛЬКО "войти в систему с помощью Google" в SPA, используя свою учетную запись org G Suite
Если вы не настроите SSO Только пользователи аккаунта Google могут проходить аутентификацию. Авторизацией управляет Google Cloud IAM.
Если пользователь уже вошел в свою учетную запись org google, ему не нужно повторно входить в SPA
. зависит от кода вашего приложения, чтобы обеспечить правильный заголовок авторизации в запросах.
При входе в SPA, учетные данные пользователей должны отправляться с каждым запросом, который микро-сервисы будут использовать для авторизации пользовательских бизнес-логики c, а также передачу этих учетных данных сервисам G Suite, таким как Google Drive (использование авторизации API-областей в качестве дополнительного уровня безопасности при сбое пользовательских бизнес-логик c)
Я не являюсь уверен, что вы подразумеваете под "учетными данными пользователя". Вы никогда не должны иметь доступ к учетным данным пользователя (имя пользователя / пароль). Вместо этого ваше приложение должно управлять OAuth-доступом и токенами идентификации и отправлять их на сервер для авторизации.
В отдаленном будущем есть возможность разрешить внешним пользователям, входящим в организацию, использовать различных федеративных провайдеров идентификации (Facebook, Twitter и др. c) для доступа к SPA и ресурсам, размещенным в организации (это не является текущим требованием, но это долгосрочная стратегическая цель)
Я уже говорил об этом ранее в своем ответе. Тем не менее, позвольте мне предложить четко подумать о том, что должно быть разрешено. Авторизация для вашего приложения отличается от авторизации для вашего приложения, которое также авторизует службы Google Cloud. Например, вы можете использовать Twitter для аутентификации и одну учетную запись службы для авторизации в Google Cloud. Это зависит только от того, что вам нужно выполнить sh и как вы хотите управлять авторизацией.
[ОБНОВЛЕНИЕ]
Один термин, который вы используете в своем вопросе, это СПА. В традиционном случае вся обработка выполняется вашим приложением в браузере. Это кошмар безопасности. Браузер будет иметь доступ к токенам OAuth, используемым для авторизации и идентификации, которые не являются безопасными. Это также ограничивает способность вашего приложения генерировать токены Refre sh, что означает, что пользователю необходимо будет повторно пройти аутентификацию после истечения срока действия существующих токенов (каждые 3600 секунд). Для решения этого вопроса я рекомендую переосмыслить ваше приложение в более традиционный дизайн клиент / сервер. Аутентификация выполняется вашими серверами, а не напрямую (внутри) клиентского приложения. В разделах, где я упоминаю учетные записи служб, я предполагаю, что бэкэнд-системы установлены, так что клиент имеет только зашифрованный сеанс cook ie.