Я столкнулся со следующим сценарием:
Есть несколько компаний, каждая из которых имеет своего собственного поставщика удостоверений OpenID Connect (IdP), который объединяет пользователей с их соответствующих серверов LDAP. Эти провайдеры используются для выполнения единого входа в контексте каждой компании.
Необходимо создать приложение, предлагающее общий логин для всех пользователей этих компаний.
Идея состоит в том, чтобы предоставить или использовать существующее облачное решение (AWS Cognito, Google Cloud Identity и т. д., ...), которое предлагает общий экран входа в систему, но делегирует/объединяет фактический вход в систему с каждым из IdP компании.
Есть ли решения, позволяющие это сделать? Не могли бы вы указать какую-либо документацию/руководство по ее реализации?
Существует решение под названием cloudpods, с помощью которого вы можете управлять как локальными, так и публичными облачными ресурсами. Cloudpods поддерживает интеграцию с несколькими облачными провайдерами, такими как aws, GCP, azure, alibaba и т. д.,
Существует ли поставщик удостоверений OpenID Connect, который может делегировать аутентификацию другим поставщикам удостоверений OpenID Connect?
Да. https://github.com/apereo/cas — один из них. Вы можете настроить его как поставщика удостоверений OIDC, а затем делегировать его любому количеству поставщиков удостоверений OIDC.
Это просто стандартное поведение OAuth и OpenID Connect с этими 3 ролями:
Поэтому вам нужен сервер авторизации на основе стандартов и настроить приложение как клиент OAuth. Затем включите область openid
, чтобы использовать OpenID Connect. Поставщики удостоверений на основе SAML также могут поддерживаться в этом потоке, даже если ваше приложение использует только OIDC.
Способ управления этим с наилучшим удобством использования заключается в том, чтобы сервер авторизации представил usernane authenticator
, который сначала фиксирует идентификатор пользователя, например электронное письмо. Затем он запускает некоторую пользовательскую логику, такую как поиск пользователя, чтобы определить, к какому IDP следует направить пользователя. Затем пользователь аутентифицируется у IDP.
После аутентификации IDP выдает токены серверу авторизации, который проверяет их, а затем выдает собственные токены приложению. В частности, приложение получает токен доступа, области действия и утверждения которого вы можете контролировать. Затем ваше приложение может отправить их вашим API, которые могут правильно авторизовать доступ к бизнес-данным.
Стремитесь к поведению, аналогичному описанному выше, или настройте его в соответствии со своими предпочтениями. Затем попробуйте его, например, с облачным или Docker-сервером авторизации, и убедитесь, что вы выбрали сервер с достаточной расширяемостью для удовлетворения ваших требований.
Также обратите внимание, что ответы Stack Overflow не должны рекомендовать конкретных поставщиков, поэтому я этого не делал.