Существует ли поставщик удостоверений OpenID Connect, который может делегировать аутентификацию другим поставщикам удостоверений OpenID Connect?

Я столкнулся со следующим сценарием:

Есть несколько компаний, каждая из которых имеет своего собственного поставщика удостоверений OpenID Connect (IdP), который объединяет пользователей с их соответствующих серверов LDAP. Эти провайдеры используются для выполнения единого входа в контексте каждой компании.

Необходимо создать приложение, предлагающее общий логин для всех пользователей этих компаний.

Идея состоит в том, чтобы предоставить или использовать существующее облачное решение (AWS Cognito, Google Cloud Identity и т. д., ...), которое предлагает общий экран входа в систему, но делегирует/объединяет фактический вход в систему с каждым из IdP компании.

Есть ли решения, позволяющие это сделать? Не могли бы вы указать какую-либо документацию/руководство по ее реализации?

Создание приборной панели для анализа данных на GCP - часть I
Создание приборной панели для анализа данных на GCP - часть I
Недавно я столкнулся с интересной бизнес-задачей - визуализацией сбоев в цепочке поставок лекарств, которую могут просматривать врачи и...
0
0
54
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Существует решение под названием cloudpods, с помощью которого вы можете управлять как локальными, так и публичными облачными ресурсами. Cloudpods поддерживает интеграцию с несколькими облачными провайдерами, такими как aws, GCP, azure, alibaba и т. д.,

Существует ли поставщик удостоверений OpenID Connect, который может делегировать аутентификацию другим поставщикам удостоверений OpenID Connect?

Да. https://github.com/apereo/cas — один из них. Вы можете настроить его как поставщика удостоверений OIDC, а затем делегировать его любому количеству поставщиков удостоверений OIDC.

Ответ принят как подходящий

Это просто стандартное поведение OAuth и OpenID Connect с этими 3 ролями:

  • Приложение использует OIDC для перенаправления на...
  • Сервер авторизации, которым вы владеете и который перенаправляет на...
  • Поставщик удостоверений

Поэтому вам нужен сервер авторизации на основе стандартов и настроить приложение как клиент OAuth. Затем включите область openid, чтобы использовать OpenID Connect. Поставщики удостоверений на основе SAML также могут поддерживаться в этом потоке, даже если ваше приложение использует только OIDC.

Способ управления этим с наилучшим удобством использования заключается в том, чтобы сервер авторизации представил usernane authenticator, который сначала фиксирует идентификатор пользователя, например электронное письмо. Затем он запускает некоторую пользовательскую логику, такую ​​как поиск пользователя, чтобы определить, к какому IDP следует направить пользователя. Затем пользователь аутентифицируется у IDP.

После аутентификации IDP выдает токены серверу авторизации, который проверяет их, а затем выдает собственные токены приложению. В частности, приложение получает токен доступа, области действия и утверждения которого вы можете контролировать. Затем ваше приложение может отправить их вашим API, которые могут правильно авторизовать доступ к бизнес-данным.

Стремитесь к поведению, аналогичному описанному выше, или настройте его в соответствии со своими предпочтениями. Затем попробуйте его, например, с облачным или Docker-сервером авторизации, и убедитесь, что вы выбрали сервер с достаточной расширяемостью для удовлетворения ваших требований.

Также обратите внимание, что ответы Stack Overflow не должны рекомендовать конкретных поставщиков, поэтому я этого не делал.

Другие вопросы по теме